v2.3.0 to v3.2.0

- version: "2.3.0"

- # Synthesis Autopilot — Autonomous Execution Mode

-

- ## The Problem

-

- Users who delegate whole tasks to an agent end up retyping the same paragraph of standing instructions every time: complete all the phases, don't check in constantly, use my decision framework, keep a plan file, don't lose state when the context compacts, build the real solution rather than a workaround. Retyped instructions have three failure modes. They drift — each retelling drops a clause, and the dropped clause (usually verification, or the decision protocol) silently doesn't happen. They decay — a long autonomous run outlives its own instructions when the context window compacts, and the agent reverts to conservative defaults mid-task. And they don't compose — the instruction block names disciplines that live in separate skills, and a paraphrase of a skill is weaker than the skill.

-

- This skill encodes the delegation contract once. One explicit phrase from the user engages the mode; the mode sequences the skills that already exist rather than restating them.

-

- ## What This Is — and Is Not

-

- **A mode.** Activation changes the agent's check-in cadence and self-management for the current delegated task: fewer questions, batched questions, a plan file that survives compaction, verification before "done." It does not change the quality bar — the anti-shortcut and integrity disciplines apply to all work, supervised or not.

-

- **A thin composition layer.** Every discipline this mode invokes is defined in its own skill, listed in `depends_on`. This file sequences them and states the protocol that is unique to autonomous runs (trigger discipline, the plan file, batched decisions, alerts). When this file and a dependency appear to disagree, the dependency is authoritative for its own domain.

-

- **Not an authority expansion.** Autonomy governs how the agent sequences work and how often it interrupts — never what it is permitted to do. See "Standing Gates Survive Autonomy" below.

-

- ## Activation — Trigger Discipline

-

- Users supervise some work by choice. This mode must never self-select onto work the user intended to watch.

-

- **Activate when the user explicitly delegates a whole task:**

-

- - "Take care of this for me" / "handle this end to end"

- - "Autopilot this" / "run with it — minimal check-ins"

- - "Complete all the phases without checking in" / "work through the whole plan on your own"

- - "I trust you to finish this autonomously"

- - Explicit invocation of this skill by name or slash command

-

- **Do not activate on:**

-

- - "Go ahead" / "yes, do it" on a single step — that approves a step, it does not delegate the task

- - General feedback like "you could be more autonomous" — a preference to note, not a mode to engage

- - Conversation *about* autonomy, autopilot, or this skill

- - Keyword coincidence in the task's subject matter

- - Ambiguous phrasing. When genuinely unsure, proceed normally without the mode. Under-firing costs a few extra check-ins; over-firing removes supervision the user chose to keep.

-

- **Never ask "should I use autopilot?"** If the phrasing is explicit, asking is false consultation (see synthesis-anti-shortcuts); if it is not explicit, the answer is already no.

-

- **On activation, acknowledge in one line** — mode plus plan-file path, e.g. "Autopilot engaged — plan file: `resources/artifacts/2026-07-08-migration-autopilot-plan.md`." Then start the first phase. Do not recite the mission back, list the phases in chat, or ask for confirmation; the plan file holds all of that.

-

- ## The Delegation Contract

-

- Engaging the mode means the user is taken to have said all of the following, once, for the duration of the task:

-

- 1. **Complete the work end to end** — all phases or waves, sequenced by the agent, with the minimum check-ins the decision protocol below allows.

- 2. **Best solutions, not workarounds** — the constraint-first protocol and costume-vocabulary scan from synthesis-anti-shortcuts apply to every draft, plan, and sub-agent brief.

- 3. **Important decisions go through the thinking framework** — synthesis-thinking-framework's modes, with the decision recorded in the plan file.

- 4. **State survives compaction** — plan file maintained per the protocol below; synthesis-context-lifecycle checkpoints at natural boundaries; synthesis-checkpoint whenever drift is suspected.

- 5. **Verification before "done"** — synthesis-implementation-integrity (or the domain's analog: fact-checking and quality gates for content work) runs before any completion claim.

- 6. **Standing rules remain in force** — nothing in this contract grants permissions the user's standing configuration withholds.

-

- ## Run Profiles — the Contract as Data

-

- The delegation contract above is prose, and prose drifts: a principal

- who retypes standing instructions for every run drops a clause each

- time, and the dropped clause silently doesn't happen. The run profile

- is the same contract as data. `scripts/run_profile.py` resolves the

- effective standing checklist at engagement from four layers, weakest

- first: the shipped default, the user profile

- (`~/.synthesis/autopilot/profile.json`, synced across the fleet),

- the project overlay (`<project>/resources/autopilot-profile.json`),

- and spoken deltas from the delegation message ("skip blog seeds

- tonight", "no deploys", "add: ..."). Every item carries its

- provenance; items disabled by config stay visible in the resolution

- instead of vanishing.

-

- The resolved checklist freezes into the plan file's

- `## Standing checklist (frozen ...)` section, and the engagement

- registers with `autopilot_gate.py register --profile <effective.json>`.

- Before close, `run_profile.py verify --plan` requires every frozen item

- to be checked with evidence or unchecked with `WAIVED:` and a reason,

- plus the deploy-authority line matching the frozen grant; `close

- --goals-met` refuses without a fresh verifier receipt. An incomplete

- close stays honest through its reason. `run_profile.py init` writes a

- first user profile from the shipped default and never overwrites one.

-

- Authority rule: profiles may narrow authority, never grant it. A

- deploy grant stored in any file layer is forced to `none` with a

- warning — only the run's own delegation message can grant deployment

- authority, and the grant's provenance is recorded. Standing gates

- survive profiles exactly as they survive autonomy.

-

- ## Continuation — Unattended Time Is a Scheduled Property

-

- The costliest way this mode fails is silently, at a turn boundary. The real

- incident that forced this section: a principal delegated an overnight run and

- went to sleep; the agent engaged the mode correctly, wrote the plan file, ran

- two phases, and then its turn ended. **Agent harnesses do not run between

- turns.** The session sat idle all night — the machine rebooted mid-night

- without interrupting anything, because nothing was executing — and the phase

- that was the entire point never started. Every discipline in this file held;

- the work still did not happen, because the contract said "complete the work

- end to end" and nothing caused the next turn to exist.

-

- **The rule: an engagement whose horizon extends beyond the current turn MUST

- establish a verified continuation mechanism before its first turn ends — or

- must say plainly, at engagement, that it cannot run unattended in this

- environment and negotiate what happens instead.** Claiming overnight autonomy

- without a continuation mechanism is a false capability claim, and the silence

- it produces is indistinguishable from progress until the principal wakes up.

-

- **Continuation mechanisms, by what they survive.** Verify what the current

- harness actually provides — do not assume from memory (see the capability

- probe rule below). The common classes:

-

- | Mechanism | Survives turn end | Survives session death | Survives reboot |

- |---|---|---|---|

- | In-flight background work whose completion re-invokes the session (dispatched agents, detached exec with a completion waiter, workflows) | yes | no | no |

- | Self-scheduled wakeup / dynamic loop (the harness re-invokes the session with a prompt on a cadence it sets) | yes | no | no |

- | Scheduled task / cron re-entry (a scheduler starts a fresh run that resumes from the plan file) | yes | yes | usually |

- | Principal-side relaunch instruction (documented command the principal or their machine runs) | yes | yes | yes |

-

- **Match the mechanism to the horizon, and layer for long ones.** A run

- measured in hours inside one sitting can ride background work and wakeups. A

- run measured across sleep, reboots, or days needs a scheduler-class re-entry

- as the dead-man's switch underneath whatever finer mechanism drives the

- inner loop — the plan file is the state that makes any fresh re-entry able

- to resume. When no mechanism exists at all, the honest engagement response

- is: "I can only make progress while turns are running; here is the relaunch

- command / loop invocation that would change that."

-

- **Re-entry protocol.** Every wake — wakeup, completion notification,

- scheduled re-entry, or a fresh session resuming — starts the same way: read

- the plan file first (it is the loop variable), read the coordination board,

- verify the plan's claimed state against ground truth (git, artifacts on

- disk — not memory), then continue the next unmet goal. Record every wake in

- the plan's cycle ledger.

-

- **Budget and runaway control.** The twin fear of the silent stop is the

- loop that burns the principal's usage limits without value. The plan file

- declares the budget up front: horizon, maximum cycles or wall-clock, and

- the per-cycle value test. Each cycle records what it advanced; a cycle that

- advanced nothing must name the external event it is waiting on, and waits

- use coarse cadences (do not poll for what a completion notification will

- deliver). Stop conditions are exactly: goals met · blocker recorded and

- principal alerted · budget exhausted and principal alerted. "Still running"

- is never itself evidence of value.

-

- **Capability probe before asserting absence.** An agent that wrongly

- believes it is blocked stops. In the motivating incident's aftermath, a

- session confidently reported that the counterpart CLI could not be reached

- unattended — stale knowledge stated as fact; the CLI had a working headless

- mode the same session had already used. Before any blocker or plan step

- claims a capability is absent ("X cannot run autonomously", "no way to

- reach Y"), run the probe — locate the binary, invoke the minimal command,

- read the tool schema — and record the probe's evidence with the claim.

- Zero results from memory are not evidence of absence.

-

- **Volatile state dies at reboots.** Scratchpad and temp directories are

- cleared by reboots and session ends — and long-horizon runs are exactly the

- runs that meet reboots. Anything a later phase, another agent, or a durable

- record depends on moves into the project (resources/) **at every phase

- boundary**, not only at close. Losing derived findings to a reboot mid-run

- means regenerating them on the next wake — paid for twice.

-

- **The mechanical backstop.** Doctrine that depends on the agent remembering

- it is the failure shape this section documents, so the gate is enforced:

- engagement registers with `scripts/autopilot_gate.py register --plan <plan>

- --mission "<done means>"`, and the plugin's Stop hook refuses to let a

- session stop while a registered engagement is active, unfinished, and has

- neither a recorded continuation (`autopilot_gate.py continuation`) nor an

- alerted blocker (`autopilot_gate.py blocker ... --alerted`) nor an honest

- close (`autopilot_gate.py close --goals-met | --incomplete <reason>`). The

- cycle ledger is mechanical too: `autopilot_gate.py cycle` refuses to record

- a wake that advanced nothing and names no external wait — there is no way

- to log a bare spin. Registration binds the engagement to the active

- coordination-session UUID, project, exact claim, and native client-session

- reference. The Stop gate blocks only the owning session. It probes the board

- before reporting a foreign engagement's claim state, but foreign work—live,

- inactive, or unknown—never globally blocks an unrelated project or forces that

- session to adjudicate somebody else's completion.

-

- ## The Plan File

-

- The plan file is the mode's survival mechanism. Chat context compacts; the plan file does not.

-

- **Location.** If the work belongs to a synthesis project (see synthesis-project-management), create it at `resources/artifacts/<date>-<task-slug>-autopilot-plan.md` inside that project. Otherwise use the working directory, or the platform's scratchpad if the working directory should stay untouched.

-

- **Contents:**

-

- ```markdown

- # Autopilot Plan — <mission title>

- Engaged: <date> · Requested by: <user> · Status: <phase N of M>

-

- ## Mission

- What "done" means, in the user's terms.

-

- ## Principal outcome

- The artifact or system outcome the principal asked to ship. Reviewer

- satisfaction and control construction are not substitutes.

-

- ## Standing instructions

- The delegation contract above, restated — so a post-compaction

- re-read restores the mode, not just the task.

-

- ## Standing checklist (frozen <timestamp>; profile <layers>)

- The resolved run profile, one line per item — `- [x] <id> — <evidence>`

- or `- [ ] <id> — WAIVED: <reason>` — plus the `Deploy authority this

- run:` line. Frozen at engagement; verified before close.

-

- ## Constraints and decisions already made

- Everything the user has decided; never re-litigate these.

-

- ## Coordination claims

- Session id, active source-area globs, overlaps checked, and messages pending.

-

- ## Proportionality

- Consequence being prevented, bounded review universe, justified control

- depth, and why the planned review effort is proportionate.

-

- ## Cross-agent orchestration and round-trip budget

- Counterpart sessions, direct dispatch path, provider-boundary exception if

- one exists, allowed principal courier crossings, current count, and the

- blocked-state alert threshold.

-

- ## Continuation

- Mechanism causing the next turn, what it survives (turn end / session

- death / reboot), the next-wake condition or cadence, the dead-man's

- switch for long horizons, the backstop cron id (scheduled at

- engagement, deleted at close), and how the mechanism was VERIFIED in

- this harness (probe evidence, not memory).

-

- ## Budget

- Horizon; maximum cycles or wall-clock; the per-cycle value test; counters

- updated each cycle. Stop conditions: goals met · blocker + alert ·

- budget exhausted + alert.

-

- ## Cycle ledger

- One line per wake: what advanced, or the named external wait. Appended

- mechanically via autopilot_gate.py cycle.

-

- ## Phases

- - [x] Phase 1 — ...

- - [ ] Phase 2 — ...

-

- ## Decisions log

- Dated entries: decision, thinking-framework mode used, rationale.

-

- ## Batched questions for the user

- Only questions the user alone can answer. Presented at checkpoints —

- simple batches as chat prompts, complex batches as a decision packet

- (synthesis-decision-packet). Packet paths and paste-back summaries

- recorded here.

-

- ## Sufficiency checkpoint

- Established, open, risk of shipping now, and the principal's ruling.

-

- ## Completion criteria and verification plan

- ```

-

- **Cadence.** Re-read the plan file after any suspected compaction (it is the recovery seed — read it before anything else) and before every phase transition. Update it at every phase boundary: checklist state, decisions log, new batched questions. The standing-instructions section makes the file self-carrying: an agent that has lost the conversation can resume the mode from the file alone.

-

- ## Decision Protocol

-

- Every decision in an autonomous run falls into one of three classes:

-

- 1. **Constraint-determined → execute.** If the user's stated constraints — in the conversation, the plan file, project context, or standing instruction files — determine the answer, do not ask. Execute and record it in the decisions log. "Recommendation: X. Your call?" on a constraint-determined question is the asking-as-shortcut costume (synthesis-anti-shortcuts).

- 2. **Open and important → thinking framework.** Run synthesis-thinking-framework, choose, record the decision and rationale in the decisions log, and proceed. Autonomy means making these calls, not deferring them.

- 3. **User-only → batch.** Facts only the user knows, genuine value trade-offs between goals the user holds, scope changes beyond the delegation. Add to the plan file's batched-questions section and continue with every piece of work that does not depend on the answer. Present the batch at a natural checkpoint — a phase boundary or the completion report.

-

- **Batch delivery has two forms, chosen by the batch, not by habit.** A simple batch — a few questions answerable in a sentence each, no evidence to weigh — goes as plain chat prompts (or the platform's structured-question facility). A complex batch — many rows, or rows that need a recommendation, reasoning, evidence links, or a notes field — is delivered as a **decision packet built by calling `synthesis-decision-packet`'s `build_packet.py`**, never reimplemented inline. The packet's integrity rules travel with it: recommendations marked but never pre-selected, bulk acceptance recorded as bulk, and the pasted-back summary logged in the decisions log with the bulk/individual distinction intact. One packet counts as one round-trip against the plan's budget — that is what makes the budget compatible with keeping every decision the principal's: the cost scales with sittings, not items. Rebuild a packet's rows against any corrections the principal has issued since the rows were drafted; a row that a correction erased must be dropped, not carried through a rebuild.

- **Never block the whole run on one question.** Re-sequence around it. Halt early only when *every* remaining path depends on an unanswered user-only question — that is a blocked state, reported per the alerts section.

- ## Cross-Agent Orchestration

- When an autonomous plan calls for adversarial or independent review, autopilot owns the

- transport. Use direct session-to-session dispatch where the runtime provides it. Give the

- counterpart the bounded evidence package, production entry point, enforcing boundary,

- receipt consumer, principal outcome, and terminal return contract. Apply the sub-agent

- acceptance audit to its return before adopting any finding.

- When both agents share the project repository, the default transport is the handoff queue

- (`synthesis-project-management/scripts/handoff.py`): the writer stores the counterpart's

- prompt as a durable, hash-pinned file under `resources/handoffs/`, announces it on the

- coordination board, and the counterpart claims it with `handoff.py read` — no chat

- transcript crossing, no principal courier. The queue and the decision packet are the two

- directions that remove the principal as transport: work moves between agents through the

- queue; decisions move between agent and principal through the packet. The queue never

- self-triggers — a counterpart acts on it only when the principal's protocol says the other

- side is done.

- If a provider boundary genuinely has no direct transport, declare that before round one.

- Batch the payload, identify who must paste it, and count it as one of the plan's principal

- courier crossings. Never hide a manual crossing inside “send this to the reviewer.” The

- round-trip budget is a tracked delivery cost; exceeding it triggers the blocked-state alert

- rather than silently recruiting the principal as orchestration middleware.

- **Dispatch the counterpart at scope-definition time, not only at review time,

- for discovery-shaped phases.** An adversary auditing the scope inventory while

- it is being built catches classifier drops and universe errors when they cost a

- correction, not a re-run — proven in the motivating overnight engagement, where

- a scope audit dispatched during Phase 0 found complete artifacts the primary

- classifier had silently dropped. Review-time dispatch remains for judging

- finished work; scope-time dispatch protects the universe the work runs over.

- Write the proportionality section before the first review round: principal outcome,

- closed artifact universe, consequence being prevented, justified control depth, and stop

- rule. Fewer rounds come from complete per-artifact coverage and stronger fixtures, never

- from reducing quality.

- At each named checkpoint, record a sufficiency ruling with exactly three evidence fields:

- established, open, and risk of shipping now. Put the ship-now choice in front of the

- principal when the plan names that gate; the principal's ruling terminates the review loop.

- Completion remains the principal's outcome, never reviewer satisfaction.

- Control depth is bounded. Verifying a requested verifier once is legitimate. A finding in

- generation N+1 of a control the principal did not request does not start generation N+2.

- If a round's findings are entirely self-inflicted by the new control, record the findings

- and stop control growth until the principal explicitly decides otherwise. Use

- synthesis-adversarial-review for the complete round and ledger protocol.

- ## Multi-Session Coordination

- An autonomous run is rarely the only session on the machine. Peer

- sessions — same principal, other harnesses, other projects — share the

- checkouts, the install trees, and the principal's review bandwidth. A

- run that ignores them collides on landing, blocks peers on stale

- claims, and misses findings routed to it. This section teaches the

- loop; the mechanics (board commands, seat fields, claim verbs) live in

- synthesis-project-management and are authoritative there.

- **Poll the board at every checkpoint, and own triage.** Engagement,

- every phase boundary, every wake or re-entry, and close: read the

- shared board and this seat's inbox. Triage is the seat's own job, not

- a principal question — acknowledge the sender on their lane, file

- findings as intake, act on requests (narrow, pause, hand off) in the

- same cycle. An inbox that only grows is a run that stopped listening.

- **Claim before writing; narrow before peer landings.** Every writable

- area is claimed before the first write, and claims stay as narrow as

- the work: named files over directories wherever the work allows. When

- a peer requests a narrowing for their landing, release the overlap the

- same cycle — verify none of the peer's paths are paths this run still

- needs, narrow, and confirm on the lane. Never write through an

- overlapping active claim; never hold a directory claim past the moment

- named files would do.

- **Register a cross-harness handle.** The seat registers the handle

- peers in other harnesses use to route to it (board seat id plus the

- native client-session reference), so a session that cannot dispatch

- directly can still reach this run through the board. A seat with no

- registered handle is unreachable, and unreachable seats get routed

- around — or collided with.

- **Shared mutations drain first.** Changes to state every session

- reads — board schema, install trees, the release train, shared

- inventories — need a clean check (no peer mid-flight on the same

- state) plus propose-and-wait: announce the mutation on the board,

- wait for objections or a clear window, then execute. Unannounced

- shared mutation is the multi-session form of the shortcut.

- **Long runs schedule a backstop cron.** Any engagement whose horizon

- extends beyond the current sitting registers a scheduler-class

- backstop at engagement — a cron or scheduled task that re-invokes the

- run from the plan file if the inner continuation ever goes silent —

- and deletes it at close. The backstop is the dead-man's switch under

- whatever finer mechanism drives the loop; a run that ends with its

- backstop still scheduled pages a principal who already got the report.

- ## Standing Gates Survive Autonomy

- Autopilot never overrides the user's standing rules. The user's global and project instruction files (CLAUDE.md, AGENTS.md, house rules) remain fully in force during autonomous runs — delegation of a task is not delegation of authority the user has reserved. Illustrative examples of gates that survive:

- - Production deployments requiring explicit per-instance permission

- - Never sending messages or email as the user — draft for their review instead (an agent-labeled channel, where one exists, is the only exception)

- - Outward-facing or irreversible actions requiring confirmation first

- - Commit-message hygiene and sanitization rules

- - Never bypassing verification hooks (`--no-verify` and equivalents)

- When a phase reaches a gated action, prepare everything up to the gate (the draft, the staged change, the deploy-ready artifact), add the approval to the batched questions, and continue with other phases. A run that ends with "everything is staged; these three actions await your approval" is a *successful* autonomous run.

- ## The Execution Loop

- 1. **Engage** — one-line acknowledgment with the plan-file path; register the

- engagement with the continuation gate (`autopilot_gate.py register`).

- 2. **Anchor** — run synthesis-checkpoint: verified date, project state from disk, history from git.

- 3. **Coordinate** — read the shared active-sessions board and inbox,

- register this seat's cross-harness handle, triage what is already

- waiting, and claim every source area this run may write before

- editing — named files over directories wherever the work allows.

- 4. **Register** — attach to or create the synthesis project (synthesis-project-management); create the plan file, including its Continuation and Budget sections; resolve the run profile (`run_profile.py resolve`, spoken deltas from the delegation message), freeze the standing checklist into the plan, and register with `--profile`. **If the horizon exceeds this turn, establish and verify the continuation mechanism NOW** — record it in the plan and via `autopilot_gate.py continuation` before any phase work makes the first turn long enough to forget.

- 5. **Phase loop** — for each phase: re-read the plan file and coordination board, triage the inbox (narrow requests release the overlap the same cycle); execute with anti-shortcut discipline; classify each decision per the protocol above; dispatch sub-agents per the hygiene rules below; directly orchestrate any adversarial counterpart and count principal courier crossings; record the sufficiency checkpoint; then update the plan file (cycle ledger included), **sweep the scratchpad — anything a later phase, another agent, or a durable record depends on moves into resources/ at THIS boundary, because volatile state dies at reboots** — and at natural checkpoints run the synthesis-context-lifecycle session protocol so CONTEXT.md and the session log stay current.

- 6. **Verify** — before declaring the mission complete, run synthesis-implementation-integrity (or the domain analog). Fix what it finds; verification that only reports is not verification.

- 7. **Close** — session-end per synthesis-context-lifecycle (context files updated, work committed where applicable); disposition every frozen checklist item in the plan, then `run_profile.py verify --plan`; release the coordination claims; delete the backstop cron; close the engagement (`autopilot_gate.py close --goals-met`, or `--incomplete <reason>` for an honest partial close); completion report in plain language: what shipped, what was decided and why, the batched questions; then the completion alert.

- The close step repeats the scratchpad sweep one final time: **What executable

- state or required input data still exists only in this session's scratchpad?**

- If a durable record cites its output, preserve the script and required inputs

- under resources/scripts/ before the checkpoint can close.

- ## Sub-Agent Fan-Out Hygiene

- Autonomous runs fan work out to sub-agents more than supervised ones, so dispatch discipline matters more, not less. Four rules (full rationale in synthesis-anti-shortcuts):

- 1. **At most five deliverables per dispatch.** Larger briefs stall or return partial work; split them into focused dispatches.

- 2. **No minimizing vocabulary in briefs.** "Keep changes minimal," "light touch," "conservative pass" license half-done work. Name the job at full size with explicit acceptance criteria.

- 3. **Acceptance audit on every non-clean-success return.** Partial completion, timeout, "stalled with substantial progress" — inspect what actually landed, diff it against the brief, and either re-dispatch or finish the gap directly. Accepting the partial state and moving on is forbidden.

- 4. **Allocate shared budgets in the brief.** Metered tools with a session-wide budget (web search is the proven one: parallel research agents share a single pool and exhaust it silently) get an explicit per-agent allocation in each brief, plus the fallback when the pool runs dry. A fan-out of N research agents against one undivided budget is a plan to get N partial reports.

- ## Completion and Blocked-State Alerts

- When the run completes, or halts blocked on user-only questions, notify the user through whatever alert channel their environment defines (sound, notification, message) — an autonomous run the user has stopped watching needs an interrupt, not a chat message they will find later. Two rules govern every alert surface:

- - **Confidentiality:** audio and notification banners can be overheard on calls and seen on shared screens. Alerts carry a generic task description and a pointer only — never client, repository, workspace, or person names. Detail belongs in screen-private channels: the completion report, the plan file.

- - **Mute flags:** honor the environment's do-not-disturb convention (in the synthesis ecosystem, the presence of `~/.synthesis/quiet-audio` mutes all audio alerts). A muted alert still gets its full written report.

- A blocked-state alert accompanies a report of what was completed, what remains, and the batched questions — never a bare "I'm stuck."

- ## Domain Neutrality

- Nothing above is specific to software. The mode runs the same for engineering, research, writing, analysis, and operations work; only the verification analog changes — test suites and integrity checks for code, fact-checking and quality gates for prose, source verification for research. "Phases" may be a migration's waves, a report's sections, or an archive's batches. The plan file, decision protocol, gates, and alerts are identical.

- ## Composed Skills

- | Skill | Role in the mode | When it runs |

- |---|---|---|

- | synthesis-checkpoint | Ground truth: date, disk state, git history | Engagement; any suspected drift or compaction |

- | synthesis-project-management | Project registration; plan-file home | Engagement |

- | synthesis-context-lifecycle | Durable memory: CONTEXT.md, sessions/, archival | Natural checkpoints; session end |

- | synthesis-thinking-framework | Decision quality on open, important calls | Decision protocol, class 2 |

- | synthesis-anti-shortcuts | Solution quality; dispatch and acceptance hygiene | Every draft, plan, brief, and sub-agent return |

- | synthesis-grounding-discipline | Claim quality: provenance, cache re-verification, absence proof | Every recorded fact and status claim; before any write or deletion |

- | synthesis-implementation-integrity | Verification before completion claims | Before "done"; per-phase for high-stakes phases |

- | synthesis-adversarial-review | Bounded cross-agent attack, findings, sufficiency, and acceptance | When a plan calls for adversarial or independent review |

- | synthesis-decision-packet | Complex user-only batches as one honest, reviewable page | Decision protocol, class 3, complex batches |

- Each dependency works standalone. This mode is the sequencing that makes them one behavior: delegate once, and the stack runs itself.