|
| 1 | +# Git Mind Feature Profiles |
| 2 | + |
| 3 | +Status: draft planning set for issue #322 |
| 4 | + |
| 5 | +This directory breaks the Git Mind product surface into feature profiles. Each |
| 6 | +profile uses the same IBM Design Thinking frame: |
| 7 | + |
| 8 | +- sponsor user |
| 9 | +- job to be done |
| 10 | +- relevant Hill or supporting lane |
| 11 | +- user stories |
| 12 | +- requirements |
| 13 | +- graph data model usage |
| 14 | +- playback evidence |
| 15 | +- test plan |
| 16 | + |
| 17 | +The intent is to keep future implementation work from starting as an |
| 18 | +architecture exercise. A feature is ready to implement only when the profile can |
| 19 | +explain who it helps, what repository-understanding job it improves, and which |
| 20 | +tests prove the claim. |
| 21 | + |
| 22 | +## Sponsor User |
| 23 | + |
| 24 | +The shared sponsor user for this profile set is a technical lead, staff |
| 25 | +engineer, architect, or autonomous coding agent entering an unfamiliar |
| 26 | +repository and needing a trustworthy semantic map quickly. |
| 27 | + |
| 28 | +## Product Hills |
| 29 | + |
| 30 | +- Hill 1: Zero-input semantic bootstrap |
| 31 | +- Hill 2: Queryable answers with receipts |
| 32 | +- Hill 3: Living map with low manual upkeep |
| 33 | + |
| 34 | +Supporting lanes exist to strengthen those Hills. They are not product centers |
| 35 | +by themselves. |
| 36 | + |
| 37 | +## Profile Catalog |
| 38 | + |
| 39 | +### Hill 1: Semantic Bootstrap |
| 40 | + |
| 41 | +- [Bootstrap Command](./bootstrap-command.md) |
| 42 | +- [Repo Fixture Builder](./repo-fixture-builder.md) |
| 43 | +- [Artifact Inventory](./artifact-inventory.md) |
| 44 | +- [Entity Extraction](./entity-extraction.md) |
| 45 | +- [Relationship Inference](./relationship-inference.md) |
| 46 | +- [Provenance And Confidence](./provenance-confidence.md) |
| 47 | +- [Review Refinement](./review-refinement.md) |
| 48 | + |
| 49 | +### Hill 2: Queryable Answers With Receipts |
| 50 | + |
| 51 | +- [Query Receipts](./query-receipts.md) |
| 52 | +- [Views And Lenses](./views-lenses.md) |
| 53 | +- [Time Travel And Semantic Diff](./time-travel-diff.md) |
| 54 | +- [Import Export Interchange](./import-export-interchange.md) |
| 55 | +- [Agent Contracts](./agent-contracts.md) |
| 56 | + |
| 57 | +### Hill 3: Living Map With Low Manual Upkeep |
| 58 | + |
| 59 | +- [Living Map Updates](./living-map-updates.md) |
| 60 | +- [Doctor And Integrity](./doctor-integrity.md) |
| 61 | +- [Trust And Observer Contexts](./trust-observers.md) |
| 62 | + |
| 63 | +### Supporting Lanes |
| 64 | + |
| 65 | +- [Graph Substrate](./graph-substrate.md) |
| 66 | +- [Content On Node](./content-on-node.md) |
| 67 | +- [Extensions Runtime](./extensions-runtime.md) |
| 68 | +- [Packaging And Adoption](./packaging-adoption.md) |
| 69 | + |
| 70 | +## Common Test Plan Taxonomy |
| 71 | + |
| 72 | +Each profile should name tests in these buckets. |
| 73 | + |
| 74 | +- Fixtures: repository or graph shapes needed to test the feature. |
| 75 | +- Golden path: expected behavior on representative clean inputs. |
| 76 | +- Edge cases: valid but tricky inputs. |
| 77 | +- Known failures: invalid inputs, ambiguity, missing dependencies, or blocked |
| 78 | + features that must fail predictably. |
| 79 | +- Regression cases: bugs or review findings that must not return. |
| 80 | +- Fuzz cases: generated or randomized inputs that probe parser, scanner, or |
| 81 | + graph assumptions. |
| 82 | +- Stress cases: large or deep scenarios that protect performance and memory |
| 83 | + behavior. |
| 84 | +- Golden artifacts: stable snapshots, schema samples, or CLI output contracts |
| 85 | + that can be compared over time. |
| 86 | +- Playback evidence: the human or agent demonstration that proves the Hill |
| 87 | + moved, not just that code ran. |
| 88 | + |
| 89 | +## Shared Graph Model |
| 90 | + |
| 91 | +All feature profiles use the canonical vocabulary in |
| 92 | +[Graph Data Model](../graph-data-model.md). Feature-specific graph sections |
| 93 | +should show: |
| 94 | + |
| 95 | +- which node prefixes the feature reads or writes |
| 96 | +- which edge types the feature creates, updates, filters, or cites |
| 97 | +- where confidence, provenance, review, or observer metadata enters the model |
| 98 | +- a Mermaid example that a reviewer can compare against the feature's test |
| 99 | + fixtures and golden artifacts |
| 100 | + |
| 101 | +## Fixture Strategy |
| 102 | + |
| 103 | +Repository-shaped behavior should use the canonical fixture strategy: |
| 104 | + |
| 105 | +1. fluent repo builder first |
| 106 | +2. reusable base repos second |
| 107 | +3. scenario overlays for history, ambiguity, and references |
| 108 | +4. archived snapshots only when exact Git object state is the subject |
| 109 | + |
| 110 | +Feature profiles may request new base repos or overlays. They should not |
| 111 | +invent one-off setup patterns unless the risk is truly local to the test. |
| 112 | + |
| 113 | +## Implementation Sequencing |
| 114 | + |
| 115 | +The recommended next implementation sequence remains: |
| 116 | + |
| 117 | +1. Bootstrap command contract and JSON output |
| 118 | +2. Fixture builder support needed by bootstrap tests |
| 119 | +3. Artifact inventory |
| 120 | +4. Entity extraction |
| 121 | +5. Relationship inference |
| 122 | +6. Provenance and confidence surfacing |
| 123 | +7. Review refinement and query receipts |
| 124 | + |
| 125 | +That sequence keeps Hill 1 executable before expanding into richer query and |
| 126 | +living-map work. |
| 127 | + |
| 128 | +## Review Rule |
| 129 | + |
| 130 | +When a feature profile and implementation disagree, update the profile or stop |
| 131 | +the implementation. Silent divergence is product debt. |
0 commit comments