wayfinder: "Zoom as needed" lets a session re-float decisions it has already read — propose a constraint-inventory compile pass in "Work through the m

### Before filing - [x] I've read `SCOPE.md` and checked `.out-of-scope/`, and this isn't covered by either. ### Skill wayfinder ### What went wrong A wayfinder "Work through the map" session, resolving a **grilling** ticket, fourth in a chain of four (`01 → 02 → 03 → 04`), on a mid-flight map. [HARNESS/MODEL — fill in before sending.] The session did the reading right: it opened tickets 02 and 03 in full before starting — retrieval worked — and then treated them as context to skim rather than constraints to hold. Four concrete misses, each a settled fact restated in text the session had loaded: 1. Sketched a domain object using an ASCII-sketching technique taken from ticket 02 while skipping the step ticket 02's own resolution mandated (reading the glossary first) — producing a wrong-shaped sketch the human had to correct. 2. Re-floated two placements as open that ticket 02 had pinned to a named component slot. 3. Drew only a variant ticket 03 had explicitly ruled out. 4. Proposed a label inside chrome whose ownership ticket 02 had assigned elsewhere — the one miss that, when the human caught it, productively amended two earlier tickets. Why that was a problem: a late-chain ticket has very little left to decide — the session acted as if it had more, and the human spent the session re-stating decisions the agent had already read. The skill's step 3 says **"Zoom as needed"**: reachability with relevance-judgment delegated to the session, and that judgment calibrated by the ticket's Question, not by what the chain had pinned. "Zoom as needed" answers *how much to read*, and the answer is fine — the reading happened. It does not answer *what the reading is for*. Resolutions read as background stay re-decidable. The map guarantees that prior decisions are *reachable*; nothing in the skill makes them *held*. ### Proposed change In `wayfinder/SKILL.md`, "Work through the map" step 3: replace the sentence our port carried verbatim from the snapshot we track — > Zoom as needed; use whichever skills the `## Notes` block names. If in doubt, use `/grilling` > and `/domain-modeling`. — with a mandatory compile pass first (this is the wording we now run locally, reviewed against our writing-for-agents levers): > 3. Resolve it. **Compile the chain's constraints first**: open the full body of every closed > ticket in the whole `Blocked by` chain and distil each resolution into a one-line > **constraint inventory** of what it pins — facts, placements, vocabulary; read what the > `## Notes` block names up front, the glossary before any label or sketch that speaks domain > vocabulary. The map keeps decisions *reachable*; the inventory makes them *held*. The chain > outranks the Question as written: where a prior resolution has settled, reframed, or > dissolved part of it, say so to the human before working, and work what remains. Check every > question, sketch, and option against the inventory before putting it to the human; a check > that fails is put to the human as a conflict — the option against the pin — for the human to > call. Zoom beyond the chain as needed; use whichever skills the `## Notes` block names. If in > doubt, use `/grilling` and `/domain-modeling`. The choices behind the wording, so each can be reviewed on its merits: - **Completion criterion, checkable and exhaustive.** "Every closed ticket in the whole `Blocked by` chain" is enumerable; "a one-line constraint inventory" is a countable artifact per ticket; "every question, sketch, and option" binds the output side. The demand is legwork, not a vague "understand the prior decisions". - **Leading word: pins.** One token anchoring facts, placements, and vocabulary. The name "constraint inventory" carries the exhaustiveness (an inventory is complete by definition) and the recasting (a constraint is satisfied, not skimmed — "decision inventory" names where the lines come from, not what they do, and invites the re-decidable reading that failed). - **The chain outranks the Question as written.** Chart-time tickets carry a rough picture; each resolution can teach the map something a later ticket's written Question did not know — so a downstream Question can be stale through no one's forgetfulness. The session says so to the human *before working* and works what remains, rather than silently grilling a stale question. - **A failed check is surfaced, never decided.** A check that fails is put to the human as a conflict — the option against the pin — for the human to call. The agent surfaces the clash; it never decides the pin. This is not hypothetical: the fourth miss above became the session's one genuine decision exactly because the human caught the clash and called it, amending two earlier tickets. The clause moves that catch from the human to the agent's own check — the human's effort goes to judging conflicts, never to re-stating what the agent already held. (In our copy, step 5 already records the consequence: a decision that invalidates other tickets updates or deletes them.) - **Positive phrasing.** The step states compile/check/surface behavior; the failure modes are never spoken as prohibitions. - **Co-location.** The pass lives inside the resolve step, where the work happens — not a separate section read at map-load and forgotten by ticket time. - **Scope choices.** "Chart the map" gets nothing (no closed chain exists at chart time); the inventory stays in-context rather than a file artifact (each session distils fresh; no stale file to maintain); on-demand zoom survives *beyond* the chain. One wording choice left open for you: the clause "read what the `## Notes` block names up front, the glossary before any label or sketch that speaks domain vocabulary" is written from our maps, whose `## Notes` name a glossary. If that is too specific for the skill as you intend it, the repo-neutral shape would be: "read what the `## Notes` block names up front, before any artifact that speaks its vocabulary." Our incident's first miss was exactly this ordering (technique imported, glossary skipped), so we'd want *some* clause that fixes required-reading before domain-speaking output — the exact wording is yours to call. Happy to open a PR with the wording if you'd rather react to a diff.