Assumptions and reroutes

Trails write down what they assume; when an assumption breaks, an agent proposes a new plan, and nothing changes until you approve it.

#Assumptions

Assumptions live in the trail's map.md under ## Assumptions, each with an id (S-1, S-2, …), a status and the tickets that depend on it:

Status	Meaning
`holding`	Nobody has shown it's wrong.
`challenged`	An agent showed evidence against it.
`invalidated`	An approved reroute confirmed it was wrong.
`confirmed`	You confirmed it.

They come from the accepted discovery brief, from start_trail (assumptions), from update_trail (addAssumptions) or from the New trail dialog. Decisions can name the assumptions they rely on (assumes). Confirm assumptions on the Plan tab.

#Challenge and propose

When an agent finds that an assumption is wrong, it calls challenge_assumption with the evidence, then propose_reroute with typed changes:

Change	Does
`add_ticket`	Adds a ticket (`ref`, `title`, `type`, `blockedBy` can name other new refs).
`cancel_ticket`	Cancels a ticket, with a reason.
`edit_ticket`	Replaces a ticket's title and/or body, and leaves an audit comment.
`rewire`	Adds and/or removes blockers (`addBlockedBy`, `removeBlockedBy`).
`supersede_decision`	Replaces a decision with a new answer and rationale.
`update_destination`	Changes what done looks like.
`add_unspecified`, `add_out_of_scope`	Adds a line to those sections.
`reopen`	Puts a done or cancelled ticket back in the queue (ready), as the trail lead.

Teamtrail validates the proposal (unknown refs, cycles after every added and removed edge, removing an edge that isn't there, edits to done or cancelled tickets, duplicate refs; each error names the change), computes a before/after diff, and freezes the tickets it touches: agents can't claim them until you decide. A new proposal from the same agent replaces its earlier pending one. Agents keep working on other tickets and check reroute_status.

#Challenge the destination

A proposal with kind: "challenge-destination" says the trail itself should change, with a destinationReason:

already-exists: the work is already done somewhere;
wrong-problem: the trail targets the wrong problem;
rescope: it should be rescoped.

It comes with evidence and a suggested destination (an update_destination change).

#Review and apply

The map shows a banner and previews the diff: new tickets as outlines, cancelled ones struck through, new edges dashed, frozen tickets marked. Review opens the proposal with its reason, evidence and every change. Approve and apply runs the changes through the normal operations, safely resumable if the process stops midway; Reject needs a note for the agent. Invalidated assumptions become suggested knowledge (dead-end or fact). Every step is journaled (proposed, approved, rejected, applied, superseded).

#Reroute suggestions

Deterministic triggers raise reroute-suggested items in Waiting on you, but never change the plan themselves:

a ticket blocked after its last allowed attempt;
a superseded decision whose dependent tickets are already done;
a cancelled ticket with open dependents;
a pull request closed without merging.

Proposals are stored in .teamtrail/.reroutes/<trail>/R-<n>.json. See File formats.