Skip to content

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

Description

@jvskriubakken

Before filing

  • 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):

  1. 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.

Activity

  1. added and removed
    needs-triageMaintainer needs to evaluate
    on Oct 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions