|
1 | | -# Roadmap Rules |
2 | | - |
3 | | -## Purpose |
4 | | -Prevent roadmap drift by separating implementation work from roadmap truth updates. |
5 | | - |
6 | | -## Ownership |
7 | | -- Implementation PRs build or refactor code. |
8 | | -- Validation PRs verify repo reality against roadmap criteria. |
9 | | -- Roadmap status changes happen only in a dedicated validation or planning PR. |
10 | | - |
11 | | -## Status Definitions |
12 | | -- `[x]` Complete: every acceptance criterion is satisfied and evidenced. |
13 | | -- `[.]` In Progress: meaningful partial completion exists, but at least one acceptance criterion is still unmet. |
14 | | -- `[ ]` Not Complete: no sufficient evidence exists to claim progress or completion. |
15 | | - |
16 | | -## Evidence Standard |
17 | | -Before changing any roadmap line, collect all of the following: |
18 | | -1. scoped acceptance criteria |
19 | | -2. repo evidence for each criterion |
20 | | -3. a pass/fail checklist |
21 | | -4. missing-items summary |
22 | | -5. recommendation with justification |
23 | | - |
24 | | -## Forbidden Shortcuts |
25 | | -Do not move a roadmap line to `[x]` because of: |
26 | | -- folder placeholders |
27 | | -- naming conventions alone |
28 | | -- one-off samples when the line is repo-wide |
29 | | -- inferred intent |
30 | | -- partial migration without runtime boundary proof |
31 | | - |
32 | | -## Validator Behavior |
33 | | -Validators must report facts only: |
34 | | -- what files exist |
35 | | -- what boundaries are present |
36 | | -- what criteria pass |
37 | | -- what criteria fail |
38 | | - |
39 | | -Validators must not: |
40 | | -- decide roadmap status without explicit acceptance criteria |
41 | | -- broaden scope |
42 | | -- merge multiple roadmap lines into one conclusion |
43 | | - |
44 | | -## Review Rule |
45 | | -When there is uncertainty, preserve the stricter status. |
46 | | - |
47 | | -## Phase-Based Rule |
48 | | -A line that names multiple games, systems, or structures stays below `[x]` until all named targets are validated. |
| 1 | +# ROADMAP RULES |
| 2 | + |
| 3 | +## Status authority |
| 4 | +Roadmap status must be evidence-backed and scoped. |
| 5 | + |
| 6 | +## Required distinction |
| 7 | +A line may be marked complete for: |
| 8 | +- a named game |
| 9 | +- a defined subset (for example, core games) |
| 10 | +- the full repo |
| 11 | + |
| 12 | +These scopes must not be collapsed into one another. |
| 13 | + |
| 14 | +## Placeholder rule |
| 15 | +`.gitkeep` folders and placeholder-only directories do not count as completion. |
| 16 | + |
| 17 | +## Repo-wide completion rule |
| 18 | +Repo-wide boundary completion requires all in-scope game folders to pass the active contract. |
| 19 | +If a contract is intended only for target/core games, the roadmap must say so explicitly. |
| 20 | + |
| 21 | +## Games-layer scope rule |
| 22 | +Section 8 lines must explicitly state scope: |
| 23 | +- core/target-game completion |
| 24 | +- or repo-wide adoption |
| 25 | +Do not mark repo-wide lines complete from core-game evidence alone. |
| 26 | + |
| 27 | +## Validation rule |
| 28 | +Validation reports may provide facts and recommendations. |
| 29 | +Roadmap status changes require an explicit docs update aligned to the real scope. |
| 30 | + |
| 31 | +## Boundary scan interpretation rule |
| 32 | +Boundary scan facts must be recorded line-by-line: |
| 33 | +- games with no violations may support game-specific `[x]` lines |
| 34 | +- remaining violations in other game folders keep repo-wide lines below `[x]` |
0 commit comments