After M1: nothing tells a cold session it HAS a knowledge graph (or when to use it) — re-scope at M1

[StarshipSuperjam]

The engine opened this item itself — you didn't create it.

What this is. A cold-booting engine session is told that the engine's knowledge graph exists and how to query it, but not when or why to reach for it during real work — so each session re-derives that understanding by hand, which is exactly the relearning the engine exists to remove. (This item was triggered by a session doing precisely that.)

• What it is: an item about the engine's own machinery — its knowledge faculty — not your project.
• Why it's here: to keep the gap visible until the M1 work that would close it exists.
• Already handled: the four query tools appear in every session automatically (.mcp.json), and what they do is written down in a committed contract (interface:knowledge-retrieval).
• What's missing: nothing points a session at the graph in the flow of a task (for example, "for an impact check, ask what depends on this"). No operation file mentions it (grep -ri knowledge .engine/operations/ finds nothing), and the session-start card lists state, stance, attention and findings but not the engine's available faculties.

What happens next. Nothing right now — this is deferred until the M1 Engine is finished, then re-scoped. Please don't pick it up early.

• The two things that would carry the fix — boot-time orientation and the memory substrate — don't exist before M1, so the right shape of the fix can't be judged yet.
• At M1, re-scope it: the fix might be a one-line addition to the session-start card, might be mostly absorbed by the memory substrate (distilled cross-session lessons), or might become a broader "advertise the engine's faculties and when to use each" design item on a real-sized repo.
• If you want it handled sooner, you can ask for it to be prioritised once M1 lands.

More detail.

• Related — operator-directed issues bypass the issue-authoring helper (#74)
• The knowledge-graph capability contract (interface:knowledge-retrieval)

[StarshipSuperjam]

Design-workspace disposition (engine-planning)

Re-scoped now that M1 has landed. Verdict: no design decision and no new grammar needed — this is closeable within the existing locked grammar. No locked doc changes.

Why it's build work, not design

The gap splits into two halves, both with homes in the existing design:

a) "Point a session at the graph in the flow of a task" — this is the per-prompt scent's job, already designed (boot, "The per-prompt scent"): it pushes attributed knowledge relations — "X relates to Y, Z — query and verify before asserting" — which is literally the design's own answer to this issue's complaint ("the substrate's worst failure is being pull-only"). And once the work-record reader lands (see #37), cold-start structural neighbors push the relevant graph neighborhood automatically too. So the in-flow half is covered by mechanisms the design already owns.

b) The standing "here's the faculty, and when to reach for it" (e.g. impact checks) — this is operations-surface content (locked, D-055). This issue's own evidence — grep .engine/operations/ finds nothing — shows the home is empty, not missing: authoring a knowledge operation file ("for an impact check, ask what depends on this") is build-side content within the grammar, exactly like authoring a check instance. The operator/AI orientation doc is a second home. A thin boot-card faculty line, if wanted, sits within boot's build-spec leaves.

The broader item is correctly deferred

The "systematically advertise all the engine's faculties + when to use each" framework is a legitimate future design item — but this issue already defers it correctly ("on a real-sized repo," evidence-driven). It's not v1-blocking, and the knowledge-specific gap is covered by (a)+(b) above. Not an MVP-punt: the capability is delivered; only the generalized framework waits for real-repo evidence.

Relationship to #37

Complementary, not the same: #37 makes the engine push the knowledge result (structural neighbors at orientation — engine does the read, no session initiative); this issue makes the engine advertise the faculty so the session reaches for it. Both serve "knowledge in the flow," via different mechanisms.

---

Net: re-scope to build work — author the knowledge operations content (+ optional boot-card line); the in-flow case is already served by the scent (and, post-work-record-reader, by #37's structural neighbors). No return to design.