chore(meta): file T-1245 — a roadmap that carries intent, not just work order
The cascade owns order, the ticket tree owns decomposition, the DQR tree owns individual rulings; none answer what the game is going to be. Evidence it is a real gap: three roadmap-level facts surfaced in one conversation on 2026-08-20 that exist in no artefact, and two of them were written up as suspected defects by an agent reading carefully, because nothing recorded them as intent. Pickup instructions make epics an OUTPUT of a harvest/interview/investigate-form/propose pass, explicitly not an input. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude Opus 5
@@ -770,3 +770,102 @@ lattice quantising the hillshade into dotted rings), and MIN_WL_BANDS_M itself,
|
||||
which remains stale for the legacy layer_proxy district-window consumer. Neither
|
||||
blocks the ladder.', NULL, '2026-08-18 18:48:58', '2026-08-18 18:48:58.820', '2026-08-18 18:48:58.820', NULL, '3652f53a400647d1a1e07722c3c80134', 2) ON CONFLICT(hash) DO NOTHING;
|
||||
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06FXRSY7QWD8J5X6G1N86WMKEC', 'status', 'in_progress', 'done', NULL, '2026-08-18 18:49:07', '2026-08-18 18:49:07.177', '2026-08-18 18:49:07.177', NULL, 'd6123093737518a1816712cc77e11bf0', 2) ON CONFLICT(hash) DO NOTHING;
|
||||
INSERT INTO ticket_history (ticket_record_id, field, old_value, new_value, changed_by, changed_at, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06G1RB7GSJA4379EAQDZPQQDN8', 'description', 'The project has a work breakdown and calls it a roadmap. The cascade owns ORDER, the ticket tree owns DECOMPOSITION, the DQR tree owns individual RULINGS — and none of them answer what the game is going to be, what the big unsolved problems are, or what is deliberately deferred. Pick-up instructions are in the appended body: the first pass is harvest/interview/investigate-form/propose-with-options, and EPICS ARE AN OUTPUT of that pass, not an input. Do not open this by inventing an epic list.', 'The project has a work breakdown and calls it a roadmap. The cascade owns ORDER, the ticket tree owns DECOMPOSITION, the DQR tree owns individual RULINGS — and none of them answer what the game is going to be, what the big unsolved problems are, or what is deliberately deferred. Pick-up instructions are in the appended body: the first pass is harvest/interview/investigate-form/propose-with-options, and EPICS ARE AN OUTPUT of that pass, not an input. Do not open this by inventing an epic list.
|
||||
|
||||
---
|
||||
WHY THIS EXISTS
|
||||
|
||||
The project has a work breakdown and calls it a roadmap. It is not one.
|
||||
|
||||
What exists today, and what each is good at:
|
||||
|
||||
- The Development Cascade (T-745 -> six phase epics, D-166): strict ORDER. It
|
||||
says what must be finished before what, and it is enforced. It does not say
|
||||
what the thing being built is, or why a phase is worth its cost.
|
||||
- The ticket tree (initiative/epic/story/task): decomposition of work already
|
||||
decided on. It answers "what is left in this batch", never "is this batch the
|
||||
right thing".
|
||||
- The DQR tree (governance/decisions|questions|rejected): individual rulings with
|
||||
rationale, each excellent in isolation. 260+ D-records do not compose into a
|
||||
direction; a reader can know every decision and still not know where the game
|
||||
is going.
|
||||
- Briefings, workshops, discussions: rich, but point-in-time and per-agent.
|
||||
|
||||
None of these answer the questions someone actually asks about a roadmap: what is
|
||||
this game going to BE, what are the big unsolved problems between here and that,
|
||||
in what order do they unlock each other, what does "done" look like for each, and
|
||||
what is deliberately not being solved yet.
|
||||
|
||||
THE EVIDENCE THAT THIS IS A REAL GAP, not a tidiness urge:
|
||||
|
||||
On 2026-08-20, in one conversation, three roadmap-level facts surfaced that exist
|
||||
in NO artefact in this repo:
|
||||
|
||||
1. The economics tree is not just trade-sim data — once geology and nature
|
||||
spawn to the 1x1 m pixel, the economics information GENERATES WORLD CONTENT.
|
||||
Production chains decide what is physically on the ground.
|
||||
2. `chemosynthetic: false` on every body is a namespace RESERVATION for
|
||||
dextro-DNA-style biochemistry at that same future tier — not a dead field.
|
||||
3. `enabled: false` on ~65% of bodies is staged rollout: learn the clean planet
|
||||
types first, then add generator scripts for the other types and the playable
|
||||
count rises.
|
||||
|
||||
Two of those three were written up as suspected DEFECTS by an agent reading the
|
||||
repo carefully, because nothing recorded them as intent. That is the cost, and it
|
||||
recurs: the roadmap lives in one person''s head and leaks out only when someone
|
||||
happens to ask the right question.
|
||||
|
||||
WHAT THIS INITIATIVE IS FOR
|
||||
|
||||
Produce a roadmap artefact that carries INTENT and SHAPE, in a form that survives
|
||||
being read by someone (or something) with no memory of the conversations that
|
||||
produced it — and that stays honest as the project moves.
|
||||
|
||||
Explicitly NOT: another ticket hierarchy, a Gantt chart, dates, or a restatement
|
||||
of the cascade. The cascade already owns order; this owns meaning.
|
||||
|
||||
HOW TO PICK THIS UP — READ THIS BEFORE CREATING ANY EPICS
|
||||
|
||||
The first work is INVESTIGATION AND PLANNING, not implementation, and not
|
||||
epic-cutting. Do not open this initiative by inventing a list of epics; the epic
|
||||
list is an OUTPUT of the first pass, not an input to it. Sequence:
|
||||
|
||||
1. HARVEST. Mine what already exists for roadmap-shaped content that was never
|
||||
collected: docs/workshops/, docs/discussions/, docs/design/, the briefings,
|
||||
the D-records'' "why" sections, the phase-epic descriptions, and the
|
||||
conversational hints that only appear in commit messages and ticket notes.
|
||||
Expect the good material to exist and be scattered — this project documents
|
||||
heavily. The gap is composition, not absence.
|
||||
2. INTERVIEW. Whatever the harvest cannot answer, ask Jeroen — directly and in
|
||||
batches. The three facts above emerged from ordinary questions; assume more
|
||||
are waiting behind questions nobody has asked. Record the answers as they
|
||||
are given, before interpreting them.
|
||||
3. INVESTIGATE FORM. Do not assume markdown-in-docs/ is right. Options worth
|
||||
weighing: a single narrative document; a per-phase "what this buys and why"
|
||||
layer attached to the existing phase epics; a D-record class for direction
|
||||
rather than decisions; something queryable through pql alongside the DQR
|
||||
tree; a visual map. Judge each against the failure mode this exists to
|
||||
prevent — a reader who knows every decision and still cannot state the
|
||||
direction — and against staying current without ceremony.
|
||||
4. PROPOSE, WITH OPTIONS. Bring 2-3 concrete shapes with trade-offs and a
|
||||
recommendation. This is a design decision about the project''s own memory;
|
||||
it deserves a D-record and Jeroen''s ruling, not an agent''s unilateral pick.
|
||||
5. ONLY THEN CUT EPICS, against the chosen shape and what the harvest showed is
|
||||
missing. Epics come last because the work is unknown until steps 1-4 have
|
||||
run.
|
||||
|
||||
ACCEPTANCE — the artefact earns its keep if:
|
||||
|
||||
- A fresh session can read it and state, without asking, what the game is
|
||||
trying to be and what the next three big problems are.
|
||||
- Facts of the kind listed above (forward reservations, staged gates, "this
|
||||
system is really for that future thing") have an obvious home, so the next
|
||||
one gets written down instead of surfacing years later in a chat.
|
||||
- It is cheap enough to keep current that it actually gets updated. A roadmap
|
||||
that rots is worse than none, because it lies with authority.
|
||||
- It does not duplicate the cascade, the ticket tree, or the DQR records. If a
|
||||
section restates any of those, it belongs there instead.
|
||||
|
||||
RELATED: D-166 (cascade order), T-745 (the cascade initiative), and this
|
||||
session''s docs/wiki-structure-findings.md, whose root-cause finding was the same
|
||||
shape — the information existed and nothing pointed at it.', NULL, '2026-08-19 22:38:30', '2026-08-19 22:38:30.455', '2026-08-19 22:38:30.455', NULL, '7df91010f7424dc9077d495186872d27', 2) ON CONFLICT(hash) DO NOTHING;
|
||||
|
||||
@@ -4,3 +4,4 @@ INSERT INTO ticket_idmap (record_id, ticket_id, created_at, updated_at, deleted_
|
||||
INSERT INTO ticket_idmap (record_id, ticket_id, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06G04975H3S7GRVQXHKYCR7BKR', 'T-1242', '2026-08-14 21:19:27.624', '2026-08-14 21:19:27.624', NULL, '410d294a5da4ba7435bc3fd4d1e08c95', 2) ON CONFLICT(record_id) DO UPDATE SET ticket_id=excluded.ticket_id, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at >= ticket_idmap.updated_at;
|
||||
INSERT INTO ticket_idmap (record_id, ticket_id, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06G0P0F9C3RKKK23ZHHTANCPZW', 'T-1243', '2026-08-16 14:37:49.794', '2026-08-16 14:37:49.794', NULL, '0dbba61f1c75851f6e0cca78402da745', 2) ON CONFLICT(record_id) DO UPDATE SET ticket_id=excluded.ticket_id, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at >= ticket_idmap.updated_at;
|
||||
INSERT INTO ticket_idmap (record_id, ticket_id, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06G1R8WZ987YCP1ARANSA70R0W', 'T-1244', '2026-08-19 22:28:11.726', '2026-08-19 22:28:11.726', NULL, 'fd1f9d38036692125ba7c7de0198bfc8', 2) ON CONFLICT(record_id) DO UPDATE SET ticket_id=excluded.ticket_id, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at >= ticket_idmap.updated_at;
|
||||
INSERT INTO ticket_idmap (record_id, ticket_id, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06G1RB7GSJA4379EAQDZPQQDN8', 'T-1245', '2026-08-19 22:38:22.413', '2026-08-19 22:38:22.413', NULL, '34a0757e14a868c4d9227c372c013e90', 2) ON CONFLICT(record_id) DO UPDATE SET ticket_id=excluded.ticket_id, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at >= ticket_idmap.updated_at;
|
||||
|
||||
@@ -853,3 +853,103 @@ lattice quantising the hillshade into dotted rings), and MIN_WL_BANDS_M itself,
|
||||
which remains stale for the legacy layer_proxy district-window consumer. Neither
|
||||
blocks the ladder.', 'done', 'medium', NULL, 'server', 'D-255', '2026-08-07 13:26:56.703', '2026-08-18 18:49:07.176', NULL, 'b79d8865e3da7d586bf8c724de2d34b2', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at >= tickets.updated_at;
|
||||
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06G1R8WZ987YCP1ARANSA70R0W', 'story', '06FB0TNSRZXCHGS16BFHSSGSV4', 'Seed variance: 68% of bodies are tectonics:low — is the categorical monoculture intended?', 'Measured 2026-08-20 over all 2,625 body definitions in wiki/star-systems/*/bodies/*/index.md. The seed''s CONTINUOUS axes vary richly: seed is unique per body, distance_au 716 distinct values, polar_ice_lat 691, axial_tilt_deg 578, land_fraction 460. The CATEGORICAL axes do not: tectonics 4 values with 67.8% ''low'', atmosphere 4 with 66.3% ''none'', planet_class 13 with 51.1% ''frozen'', substrate 3 with 51.1% ''ice'', geothermal_flux 3 with 91.2% ''low''. Those categoricals are what gate the morphology and biome branches, so a mostly-low-tectonics world is mostly FLAT BY THE SEED, before any rendering question. This matters because a full session (2026-08-16..18) went into making the Atlas render terrain legibly at the deep rungs, and composition.rs already states the honest position: ''where the terrain is flat, flat is the honest answer, and the morphology variety visible at Global comes from places that actually have slope''. If two thirds of bodies genuinely have no slope, there is a ceiling on what renderer work can deliver and it is set in the seed. QUESTION TO ANSWER FIRST, before any change: is the distribution intended? A galaxy where most worlds are dull and the interesting ones stand out is a legitimate and probably good design; an authoring pass that defaulted tectonics to ''low'' and moved on is not. Check how the values were produced (scaffold_bodies.py / the authoring pass) before touching them. NOT a defect report -- two things that looked like defects in the same measurement turned out deliberate (chemosynthetic:false is a namespace reservation for dextro-DNA biochemistry once geology and nature spawn to the 1x1m pixel; enabled:false on ~65% is staged rollout, clean planet types first then generator scripts for the others). Method caveat: the aggregator reads scalar frontmatter only, so list-valued fields are unreliable -- atmosphere_color first read as ''100% null'' and that was a parser artefact. Full measurement and method: docs/wiki-structure-findings.md.', 'backlog', 'medium', NULL, 'server', NULL, '2026-08-19 22:28:11.722', '2026-08-19 22:28:11.722', NULL, 'd5f89318c9d9845ae46aa165a731821f', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at >= tickets.updated_at;
|
||||
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06G1RB7GSJA4379EAQDZPQQDN8', 'initiative', NULL, 'Roadmap that carries intent — where the game is going, not just what order the work runs in', 'The project has a work breakdown and calls it a roadmap. The cascade owns ORDER, the ticket tree owns DECOMPOSITION, the DQR tree owns individual RULINGS — and none of them answer what the game is going to be, what the big unsolved problems are, or what is deliberately deferred. Pick-up instructions are in the appended body: the first pass is harvest/interview/investigate-form/propose-with-options, and EPICS ARE AN OUTPUT of that pass, not an input. Do not open this by inventing an epic list.', 'backlog', 'high', NULL, 'meta', NULL, '2026-08-19 22:38:22.412', '2026-08-19 22:38:22.412', NULL, 'ec77d9e27fa2cad2c124a8ae196e11d4', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at >= tickets.updated_at;
|
||||
INSERT INTO tickets (record_id, type, parent_record_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('06G1RB7GSJA4379EAQDZPQQDN8', 'initiative', NULL, 'Roadmap that carries intent — where the game is going, not just what order the work runs in', 'The project has a work breakdown and calls it a roadmap. The cascade owns ORDER, the ticket tree owns DECOMPOSITION, the DQR tree owns individual RULINGS — and none of them answer what the game is going to be, what the big unsolved problems are, or what is deliberately deferred. Pick-up instructions are in the appended body: the first pass is harvest/interview/investigate-form/propose-with-options, and EPICS ARE AN OUTPUT of that pass, not an input. Do not open this by inventing an epic list.
|
||||
|
||||
---
|
||||
WHY THIS EXISTS
|
||||
|
||||
The project has a work breakdown and calls it a roadmap. It is not one.
|
||||
|
||||
What exists today, and what each is good at:
|
||||
|
||||
- The Development Cascade (T-745 -> six phase epics, D-166): strict ORDER. It
|
||||
says what must be finished before what, and it is enforced. It does not say
|
||||
what the thing being built is, or why a phase is worth its cost.
|
||||
- The ticket tree (initiative/epic/story/task): decomposition of work already
|
||||
decided on. It answers "what is left in this batch", never "is this batch the
|
||||
right thing".
|
||||
- The DQR tree (governance/decisions|questions|rejected): individual rulings with
|
||||
rationale, each excellent in isolation. 260+ D-records do not compose into a
|
||||
direction; a reader can know every decision and still not know where the game
|
||||
is going.
|
||||
- Briefings, workshops, discussions: rich, but point-in-time and per-agent.
|
||||
|
||||
None of these answer the questions someone actually asks about a roadmap: what is
|
||||
this game going to BE, what are the big unsolved problems between here and that,
|
||||
in what order do they unlock each other, what does "done" look like for each, and
|
||||
what is deliberately not being solved yet.
|
||||
|
||||
THE EVIDENCE THAT THIS IS A REAL GAP, not a tidiness urge:
|
||||
|
||||
On 2026-08-20, in one conversation, three roadmap-level facts surfaced that exist
|
||||
in NO artefact in this repo:
|
||||
|
||||
1. The economics tree is not just trade-sim data — once geology and nature
|
||||
spawn to the 1x1 m pixel, the economics information GENERATES WORLD CONTENT.
|
||||
Production chains decide what is physically on the ground.
|
||||
2. `chemosynthetic: false` on every body is a namespace RESERVATION for
|
||||
dextro-DNA-style biochemistry at that same future tier — not a dead field.
|
||||
3. `enabled: false` on ~65% of bodies is staged rollout: learn the clean planet
|
||||
types first, then add generator scripts for the other types and the playable
|
||||
count rises.
|
||||
|
||||
Two of those three were written up as suspected DEFECTS by an agent reading the
|
||||
repo carefully, because nothing recorded them as intent. That is the cost, and it
|
||||
recurs: the roadmap lives in one person''s head and leaks out only when someone
|
||||
happens to ask the right question.
|
||||
|
||||
WHAT THIS INITIATIVE IS FOR
|
||||
|
||||
Produce a roadmap artefact that carries INTENT and SHAPE, in a form that survives
|
||||
being read by someone (or something) with no memory of the conversations that
|
||||
produced it — and that stays honest as the project moves.
|
||||
|
||||
Explicitly NOT: another ticket hierarchy, a Gantt chart, dates, or a restatement
|
||||
of the cascade. The cascade already owns order; this owns meaning.
|
||||
|
||||
HOW TO PICK THIS UP — READ THIS BEFORE CREATING ANY EPICS
|
||||
|
||||
The first work is INVESTIGATION AND PLANNING, not implementation, and not
|
||||
epic-cutting. Do not open this initiative by inventing a list of epics; the epic
|
||||
list is an OUTPUT of the first pass, not an input to it. Sequence:
|
||||
|
||||
1. HARVEST. Mine what already exists for roadmap-shaped content that was never
|
||||
collected: docs/workshops/, docs/discussions/, docs/design/, the briefings,
|
||||
the D-records'' "why" sections, the phase-epic descriptions, and the
|
||||
conversational hints that only appear in commit messages and ticket notes.
|
||||
Expect the good material to exist and be scattered — this project documents
|
||||
heavily. The gap is composition, not absence.
|
||||
2. INTERVIEW. Whatever the harvest cannot answer, ask Jeroen — directly and in
|
||||
batches. The three facts above emerged from ordinary questions; assume more
|
||||
are waiting behind questions nobody has asked. Record the answers as they
|
||||
are given, before interpreting them.
|
||||
3. INVESTIGATE FORM. Do not assume markdown-in-docs/ is right. Options worth
|
||||
weighing: a single narrative document; a per-phase "what this buys and why"
|
||||
layer attached to the existing phase epics; a D-record class for direction
|
||||
rather than decisions; something queryable through pql alongside the DQR
|
||||
tree; a visual map. Judge each against the failure mode this exists to
|
||||
prevent — a reader who knows every decision and still cannot state the
|
||||
direction — and against staying current without ceremony.
|
||||
4. PROPOSE, WITH OPTIONS. Bring 2-3 concrete shapes with trade-offs and a
|
||||
recommendation. This is a design decision about the project''s own memory;
|
||||
it deserves a D-record and Jeroen''s ruling, not an agent''s unilateral pick.
|
||||
5. ONLY THEN CUT EPICS, against the chosen shape and what the harvest showed is
|
||||
missing. Epics come last because the work is unknown until steps 1-4 have
|
||||
run.
|
||||
|
||||
ACCEPTANCE — the artefact earns its keep if:
|
||||
|
||||
- A fresh session can read it and state, without asking, what the game is
|
||||
trying to be and what the next three big problems are.
|
||||
- Facts of the kind listed above (forward reservations, staged gates, "this
|
||||
system is really for that future thing") have an obvious home, so the next
|
||||
one gets written down instead of surfacing years later in a chat.
|
||||
- It is cheap enough to keep current that it actually gets updated. A roadmap
|
||||
that rots is worse than none, because it lies with authority.
|
||||
- It does not duplicate the cascade, the ticket tree, or the DQR records. If a
|
||||
section restates any of those, it belongs there instead.
|
||||
|
||||
RELATED: D-166 (cascade order), T-745 (the cascade initiative), and this
|
||||
session''s docs/wiki-structure-findings.md, whose root-cause finding was the same
|
||||
shape — the information existed and nothing pointed at it.', 'backlog', 'high', NULL, 'meta', NULL, '2026-08-19 22:38:22.412', '2026-08-19 22:38:30.454', NULL, 'f787c3a0250b47f88079efda1b22bb97', 2) ON CONFLICT(record_id) DO UPDATE SET type=excluded.type, parent_record_id=excluded.parent_record_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at >= tickets.updated_at;
|
||||
|
||||
Reference in New Issue
Block a user