vinculum-map

Mission Map — durable state for a multi-session build

A mission larger than one context window cannot live in the conversation. It lives on the Mission Map: one item on the project's tracker that indexes every decision made and points at the tickets holding the detail.

The map is an index, not a store. A decision lives in exactly one place — its own ticket. The map gists it in one line and links. This is what makes resume cheap: a cold session reads the map (small), then zooms only into what it needs.

Ported from the wayfinding pattern in mattpocock/skills, adapted to the Dark Factory stage pipeline and a pluggable tracker.

The tracker is chosen per mission

Declare it when the loop is invoked — "run the loop on X, tracker: jira, project ABC". Record the choice in the map's Tracker field so every later session inherits it.

Board ids, data sources, frontier queries, dispatch scripts and deploy gates are organisation bindings — they live in that organisation's Tier-2 repo, never here. Do not re-derive them.

Rate limits are part of the tracker contract. Notion's query_data_sources is available_with_limit on some plans: read the frontier once per dispatch batch, never once per worker. A tracker that throttles under a fleet is a tracker that will silently starve the frontier.

Verify the blocking write. Monday's dependency column with dependencyNewInfra: true silently discards writes made through change_item_column_values — the mutation returns success and the column reads back null. Always read the column back after setting it. If it did not take, carry blocking in the status field instead and record the edges on the map.