symphony

name	symphony
description	LinX Symphony control-plane skill for system evolution: maintain control records, judge whether input changes existing design/work, coordinate Secretary/workers, and feed evidence back into system state.

Symphony

Use this when LinX Symphony mode is enabled, when the user says $symphony, when the Codex project prompt /symphony is invoked, or when a coding agent is designing, implementing, or reviewing Symphony behavior.

This skill is the single Symphony skill. It covers portable control-plane semantics and Codex control-lane behavior. It does not require LinX Pod/xpod and does not implement product /symphony, Pod persistence, backend projection, or storage templates.

/symphony is only a control switch. In product runtime, the objective comes from a normal user chat message.

Core Loop

Run this loop before creating work or dispatching workers:

System Situation
  -> Evolution Judgment
  -> Execution Control
  -> Evidence Feedback
  -> updated System Situation

Recording Trigger

Do not wait for the user to say "record" or "summarize." Every conversation produces signals—Idea, Design Decision, Research Finding, Meta-Rule, Product Direction, or Project Context. The Secretary must decide when these signals should become durable control records.

Judgment rules:

• A clear design conclusion has been reached ("放弃长链条归因 → 版本记录"). → Create or update the relevant control record. Ask for the user only when authority, target, or type classification is ambiguous.
• The user has corrected the Secretary's behavior ("你应该自己判断什么时候记录"). → This is a Meta-Rule. Record it as one.
• A research finding with external evidence has been cited ("GraphGPO 困于单任务轨迹"). → Record it with provenance.
• A new candidate work item or architectural direction has been identified. → Record it as an Idea first. Promote to Issue only when acceptance, scope, and compatibility impact are clear.
• The user explicitly asks to record ("记录一下"). → This is the fallback, not the primary trigger. The Secretary should have already proposed recording before the user asks.

Do not create a control record for:

• Ordinary back-and-forth that doesn't change system state.
• Transient task instructions ("帮我查一下").
• Social chatter or off-topic remarks.

When in doubt, propose: "这个要落到控制记录里吗？" and show the classification (Idea / Decision / Finding / Meta-Rule). The user confirms or corrects—once. Do not ask again for the same kind of signal in the same session unless the user's intent genuinely changed.

Runtime Boundary

Portable runtimes such as Codex or Claude Code use local Markdown/JSON control records plus available tools. LinX runtime must store shared control-plane facts in its modeled Pod/RDF resources. In LinX product runtime, local files are only runtime-private logs, no-Pod recovery material, or RDF/JSON-LD mirrors pulled from Pod; they are not an independent Symphony business schema. Do not put Pod paths, RDF predicates, URI templates, or LinX-specific synchronization mechanics in this skill; they belong in LinX models/adapters, not as the core Symphony skill contract.

LinX runtime writes its own control records to modeled Pod/RDF resources as the authoritative product state for shared recovery and cross-client visibility. Do not describe those writes as sync or projection. Reserve sync/projection language for external/backend/runtime facts that are being translated into the LinX control plane, or for local mirrors materialized from Pod.

The portable Symphony runtime contract is storage-agnostic. It may produce control records, work splits, prompts, and reports, but it does not own Pod IO. LinX product runtime persists through shared models/repositories. When the writer is an AI operating through terminal/tools rather than in-process LinX code, xpod CLI is the preferred direct Pod tool surface. Use model-backed xpod obj operations for Symphony resources when available; do not invent a parallel Symphony-specific AI tool API and do not hand-patch modeled TTL paths.

In LinX Agent Runtime, Pod authority belongs to the runtime session and should be inherited by tools launched inside that session. If a Secretary or worker has Pod access, xpod commands it runs should use the runtime-provided authority bridge. Outside that bridge, all Solid apps share the same local auth source $SOLID_HOME/auth/credentials.json; old ~/.xpod/config.json and ~/.xpod/secrets.json files are not Solid auth sources, and their presence alone must be treated as unauthenticated. If xpod auth status --json reports a different WebID or Pod root than the shared Solid auth file, treat it as an auth-store mismatch and stop before writing. Never ask the model to handle raw tokens, refresh tokens, client secrets, cookies, or DPoP material directly.

Agent Config And Skill Resources

Do not treat an agent's backend, model, credentials, tools, or skills as hidden prompt blobs. They are managed resources with runtime snapshots.

In LinX runtime, an Agent is a resource/container. Its default runtime config is metadata on that Agent container; skills are file or folder resources bound by lightweight metadata. A Solid-backed implementation may use a container .meta document to describe the Agent container itself, but Symphony code and prompts must not hardcode those paths or predicates. Use shared models, repositories, or xpod/adapters for the concrete storage shape.

Treat an Agent root as a context folder with multiple authority surfaces, not as one merged config object. System-managed surfaces and user-managed surfaces live under the same Agent folder. This is analogous to platform/system instructions plus a repository AGENTS.md: both are loaded into runtime context, but they remain separate sources of truth. Do not describe this as a field-level overlay that rewrites the system package or user personalization into one blob.

The default Secretary Agent key is the system-reserved __secretary__. The default Secretary Chat may use the same reserved key under the Chat resource base, for example /.data/chat/__secretary__/index.ttl#this; this does not make the Chat resource an Agent identity. Durable Agent, Skill, maker/actor, grant-recipient, and runtime snapshot identity should use the /agents/__secretary__/ container resource. Do not treat .meta as the Agent identity, and do not introduce non-reserved Secretary slugs.

Agent root and Agent identity are separate:

• The Agent root is the configuration/resource container.
• An Agent WebID is needed only when the AI acts as an auditable actor, requester, maker, grant recipient, credential holder, or authorization subject.
• Ordinary Skills, Issues, Tasks, Runs, Evidence, Reports, and files use their own resource URIs; they do not become WebIDs.

Skill content is file-backed. Skill metadata may record enabled state, version, source, checksum, load policy, dependencies, and relations, but it must not duplicate the full skill text in RDF or runtime config. Agent-scoped skill resources are bindings/installations; external or reusable skills are referenced through source/version/checksum/root and may be materialized locally per Agent. Secretary and workers should refer to configured skill resources and loaded skill versions rather than assuming a skill is just an invisible system-prompt section.

For the default Secretary, system-managed surfaces include the installed Secretary package, built-in skill bindings, migration records, capability envelope, and default policy pointers. User-managed surfaces include AGENTS.md, preferences, user-installed skills, grants, memory policy, and forked skill bindings. Upgrades may mutate system-managed surfaces only. User-managed surfaces survive upgrades unless the user explicitly accepts a migration or edits them. If a system skill is customized, represent it as a user-managed fork or override binding with its own source/version/checksum.

Runtime startup resolves the Agent default config plus launch/session overrides, projects the Agent folder in authority order, then freezes the effective backend, model, credential source, skill set, loaded system package version, user surface revisions, skill checksums, and authority/tool policy into Session/Run metadata. Resume should use that snapshot by default. A different backend/model/credential source means a new runtime session or an explicit override record, not silent mutation of an old run's meaning.

Control Lane

When Symphony is active in Codex:

• The main thread discusses requirements, system situation, design, steering, acceptance, and final reports with the user.
• The main thread updates the relevant control record before non-trivial implementation delegation.
• The main thread owns integration, review, closure, and evidence feedback.
• Implementation and test-writing should be delegated to bounded workers when a suitable worker surface is available.
• If no worker surface is available, simulate the mode locally and say that full delegation is unavailable.

Control Records

Treat Symphony docs as control records, not essays. Keep them readable for humans and stable enough for agents to bind work, compare state, and append evidence without reconstructing truth from chat.

Useful headings:

• Status
• Scope
• Current Truth
• Active Work
• Release Boundary
• Compatibility Impact
• Evidence
• Open Questions
• Next Step
• Related Docs

Keep current truth separate from history. Put rejected alternatives, stale notes, and superseded decisions under explicit headings.

Do not keep parallel truth copies. A repository document may summarize or link to a control state, but the authoritative state field must live in exactly one control record. If a local summary is needed for readability, label it as a projection and include the source record and revision or timestamp.

Steering does not bypass the control record. When a new message changes active work, update the relevant control record first, then deliver the resulting delta to workers as a bounded steer, restart, cancellation, or follow-up. Do not push raw chat into a worker as hidden scope change.

Steering deltas are navigation, not authority. Include the updated record path, revision or timestamp when available, changed sections, superseded assumptions, and required action. If scope, acceptance, release boundary, compatibility, privacy, authority, or blocker rules changed, tell the worker to reread the affected authoritative sections before continuing.

State And Ownership

Distinguish these axes instead of collapsing everything into one status:

• system state: existing, partial, verified, known-broken, deprecated, stale, or superseded;
• work state: drafting, ready, running, blocked, reviewing, completed, failed, or cancelled;
• roadmap state: candidate, planned, deferred, rejected, or superseded;
• compatibility impact: compatible, behavior_change, breaking, or migration_required.

Every mutable state field needs a primary writer:

• User owns intent, authority, and final acceptance input.
• Secretary or main control lane owns System Situation, Evolution Judgment, Spec state, Work split/assignment, acceptance, compatibility impact, release boundary, and closure.
• Worker owns progress, observed implementation facts, feasibility findings, blockers, Implementation Change Requests, and evidence for assigned Work.
• Runtime/controller owns Run lifecycle and tool/runtime events.
• Reviewer/verifier owns findings and verification evidence.

Resource boundaries:

• Message is an immutable utterance or event, not automatically an Issue.
• Idea is a lightweight candidate extracted from one or more Messages. It is not a requirement, decision, Issue, or Task until promoted.
• Spec holds desired system change, rationale, non-goals, acceptance, and compatibility impact.
• Work/Task is a bounded execution slice.
• Run is one execution attempt.
• Delivery is a proposed result package, not accepted truth.
• Evidence is append-only proof or finding.
• ReleasePlan is a rolling publish boundary: what is safe to ship now, what remains open after release, and what evidence/status must be updated before publishing.

Chat, Run state, and Delivery have different jobs:

• Chat is the low-latency interaction channel between Secretary and a worker. It is for clarification, steering, small decisions, and work-in-progress coordination.
• Run state is the scheduler truth. When a worker asks for input, that Run is waiting_input; if Secretary cannot resolve it, the owning Task/Issue may become blocked. The system may continue other work instead of pretending the worker is still running.
• Delivery is the stage boundary. It packages proposed results, patches, artifacts, verification, risks, and final reports. It is not ordinary chat and not accepted truth by itself.
• Chat must not replace state. Any chat exchange that changes scope, acceptance, compatibility, release boundary, authority, or lifecycle state must be reflected in the control record.
• Delivery must not replace chat. Do not force every small clarification into a delivery packet when an interactive worker session is available.

If a role needs to change state it does not own, it writes a proposal, finding, or Implementation Change Request instead of mutating the authoritative field.

Prevent split-brain documentation with field-level ownership:

• One mutable fact has one authoritative field and one primary writer.
• Workers may append execution facts, evidence, delivery notes, and scoped implementation documentation, but they do not close work or redefine acceptance by writing another document.
• Secretary/control lane merges worker facts into Issue/Spec/Task status only after checking evidence, current revision, and acceptance.
• Repo docs may explain implementation state, but they must not become a second task tracker. Link to the control record instead of duplicating lifecycle truth.

In LinX runtime, the MVP default is that workers do not directly access Pod. Secretary/control lane gives workers a task brief or control-record snapshot, and workers return progress, blockers, Evidence, Delivery reports, and Implementation Change Requests for Secretary/control lane to persist. Direct worker Pod read or restricted write is an explicit granted capability; when granted, the write surface is still limited to execution facts such as Run/RunStep, progress, blockers, Evidence, Delivery reports, and Implementation Change Requests. Workers do not directly close Issues, change acceptance, rewrite Spec truth, change roadmap/release boundaries, or create grants. Structured Pod data must be read/written via shared models/ORM; do not invent raw TTL patches or Pod paths inside the skill. LinX product Pod records should expose this worker access policy on assigned Task/Delivery/Run/session metadata so UI, Secretary, and runtime adapters enforce the same boundary instead of relying on prompt text alone.

Pod and repository docs have different authority. In LinX runtime, Pod Issue/Spec/Task records are the control authority for state, scope, acceptance, split, ownership, closure, and cross-client coordination. Repository docs are the implementation authority for code-adjacent design, behavior, tests, examples, migration details, and file-level evidence. Repo work briefs or implementation docs may link to Pod Issue/Spec/Task URIs, but they must not become a second Issue truth. If implementation evidence contradicts the Pod control record, workers write an Implementation Change Request and the control lane updates Pod plus repo docs.

Idea Capture

Use Idea as the buffer between fragmented conversation and committed system work.

When Symphony is active, capture meaningful but uncommitted fragments as Ideas when they describe a possible system direction, concern, product capability, modeling principle, or improvement area. Do not capture ordinary chat, games, or one-off explanations.

An Idea record should stay small and explicit:

• summary;
• source messages or source event references;
• affected area;
• status: captured, exploring, candidate, promoted, deferred, rejected, or superseded;
• commitment: thought, direction, tentative_decision, or committed;
• current understanding;
• open questions;
• related records;
• conflicts;
• next step.

Promotion gates:

• Promote Idea to Requirement Candidate only after the problem, area, value, current understanding, and open questions are explicit.
• Promote to Spec only after expected behavior, scope, compatibility impact, acceptance, and commitment are explicit.
• Promote to Work/Task only after implementation boundary, evidence plan, and blocker rules are explicit.

Symphony may automatically capture and merge Ideas, but it must not automatically treat an Idea as committed product semantics or dispatchable work. If commitment is unclear, keep it as thought or candidate and continue discussion.

Sufficiency And Escalation

Default to AI judgment inside the current control boundary. It is sufficient to proceed without asking when the input binds to one active object, the acting role owns the state being changed, acceptance/evidence can be derived from current records, and the action is reversible or non-destructive.

Escalation is necessary only when missing information belongs to another owner and cannot be safely inferred. Workers escalate to Secretary/control lane first. The control lane asks the user only for user-owned intent, authority, privacy, credentials, destructive permission, or final acceptance.

Do not ask the user to decide ordinary implementation details, routine evidence choices, obvious duplicate binding, or release bookkeeping.

Control Gates

Control gates are internal decision points. Users do not need to name them. Secretary and workers must recognize them when normal execution cannot safely continue on the current path.

Use the smallest sufficient gate set:

• binding: decide whether input is ordinary chat, an Idea, a new Issue, a bug, or a change to existing work.
• change: decide whether active scope, acceptance, compatibility, release boundary, or base revision has changed enough to rebase, steer, restart, cancel, split, or supersede work.
• feasibility: decide whether the assigned plan still can be implemented under current constraints. Workers may trigger this gate; Secretary/control lane resolves it.
• authority: decide whether user-owned authority, credentials, privacy, approval, grant, destructive permission, or external production access is required.
• quality: decide whether evidence is sufficient or the work needs fixes, review, retry, or more tests.
• acceptance: decide whether a Delivery can be accepted, rejected, partially accepted, reopened, or turned into follow-up work.

A gate is not a chat message, Delivery, or mode. Record it only when it changes the control path: a control-record update, Run/Task status transition, Implementation Change Request, Approval/InputRequest, Evidence, Report, or Delivery decision. If it does not change execution or authority, keep it as ordinary discussion or evidence.

Default ownership:

• Secretary/control lane resolves binding, change, feasibility, quality, and acceptance gates when current records and evidence are sufficient.
• Workers report feasibility, quality, blocker, and change signals; they do not resolve gates that alter scope, acceptance, authority, release boundary, or closure.
• The human user is asked only for gates that require user-owned intent, authority, privacy, credentials, destructive permission, or final acceptance.

Evolution Judgment

For each meaningful user message or system event, bind it before turning it into work:

• ordinary_message: conversation, explanation, game play, or casual chat. Keep it as Message; do not create an Issue.
• new_concern: new system concern or capability direction.
• update_existing: change to an existing capability, Spec, Issue, Task, or active execution.
• steering: correction while work is in progress.
• bug_or_regression: observed behavior conflicts with expected system state.
• conflict: request would break current product/system semantics.
• duplicate: already covered by open concern or active work.
• defer: should wait until active branch/spec lands.
• ask: binding, authority, target, visibility, or acceptance is ambiguous.

If a new requirement arrives while work is active, diff it against the active record first:

• same intended outcome with narrower detail: update acceptance/context;
• changed intended outcome: steer or restart work when it changes the intended outcome;
• incompatible with current semantics: mark conflict or breaking impact;
• unrelated future direction: capture as roadmap candidate/deferred work;
• duplicate of existing work: link it and avoid dispatching a second task.

Then consider whether the ReleasePlan is still coherent. Symphony does not manage AI work by human-style time boxes or work-hour estimates. AI can keep working and release continuously, but each release checkpoint needs a clear publish boundary, explicit evidence, and status feedback.

The release tradeoff is whether to keep working or close and publish the verified part now. Consider how much more work remains, whether remaining work is uncertain or risky, and whether completed work already satisfies an urgent coherent need. Prefer closing a verified release and leaving the rest open when the completed part is independently valuable.

Execution Control

Create Issue/Task/Delivery/Session/Run objects only when they help control work.

Before dispatching workers for non-trivial work, ensure this chain exists or can be represented:

Spec -> Work -> Status -> Evidence

Workers should receive a stable control record or task brief to follow, not raw conversation as scope. Each worker task needs one owner, one objective, concrete acceptance, source context, workspace/resource boundaries, dependencies, blocker conditions, and instructions to report blockers to Secretary/control lane rather than asking the human user directly.

Every worker handoff must identify the source record and base revision. A worker result based on an old revision is still useful evidence, but it must not be merged directly into current control state until Secretary/control lane rebases it against the latest record.

Symphony separates three spaces, but it does not force every space to split the same way:

• Control space is shared. Secretary, workers, UI, and runtime adapters refer to the same Issue, Spec, Task, Delivery, Session, Run, and Evidence records.
• Runtime session topology is explicit. A worker may collaborate in the same conversation/work room as Secretary, or may run in a separate backend session reached by runtime input projection or control events. Do not assume one topology from the other.
• Workspace belongs to a Thread, not to an Agent. One independent Thread may have one worker and its own worktree. If three AIs are collaborating in the same Thread, they should normally share the same workspace so their edits, tests, and evidence are coherent. Different Threads may use separate worktrees when isolation or conflict control requires it.

Worker workspaces are environment-scoped. A worker's workspace is wherever that worker runtime is executing: local shell, remote container, Codex, Claude Code, CodeBuddy, cloud runner, or another runtime. Workers assigned to the same Thread in the same environment should share the same workspace unless isolation is explicitly required. The boundary is portability, not exclusivity: do not assume Secretary, the user, or sibling workers in other environments can see the same absolute path. Align cross-environment file work through control object URIs, environment identity, workspace identity, repo-relative paths plus base revision, checksums/etags, patch/artifact URIs, and evidence. Workers write in their assigned workspace and report patches, artifacts, changed files, base revision, and verification; the control lane decides how to apply or replay results elsewhere.

Do not require fixed worker roles at the start. Use one bounded owner for one coherent Work item by default. Role-based worker dispatch is a future LinX runtime capability; when implemented, roles should be execution profiles selected from contacts or created as AI contacts, and they bind to Work rather than splitting Spec by themselves.

Dispatch targets are Contact-first. A Contact is the durable App-visible participant and may point to an Agent; a worker instance is only a Run/Session role. Chat participants must use Contact URIs, while backend/model/runtime facts stay on Agent/Run/Session. Default coding contacts should use backend keys such as codex unless a deliberate persona is introduced.

Interactive worker sessions do not need a Delivery tool for every blocker. When Secretary launches or manages the worker session, the worker-facing user input is a Secretary-controlled projection. If the worker lacks information, authority, or a decision, it may ask in that conversation directly; Secretary answers from the control record, updates the control record, steers the worker, or escalates to the human user when the missing decision belongs to the user. Delivery remains the channel for proposed result packages, async handoff, artifacts, and final reports, not the required path for ordinary interactive clarification.

Thread messages and LLM inputs are different layers. A Message records who said what in a Thread. Backend system/user/assistant/tool inputs are runtime projections derived from Thread facts and control records. If Secretary speaks on behalf of the user, record Secretary as the maker/source in the Thread and let the runtime adapter project that intent into the backend-required role. Do not ask workers to fabricate user-authored chat messages just because the backend protocol needs a user input.

Group coordination goes through Thread reconciliation, not direct member wakeups:

• Chat is the long-lived groupable collaboration surface. Thread is the concrete observable work site under a Chat.
• Messages, control events, Delivery submissions, InboxNotification envelopes, linked approvals/input requests, and schedule ticks are appended to a Thread first.
• A Reconciler observes Thread state, classifies and deduplicates events, applies Thread policy, and creates or skips WakeJobs.
• A Scheduler runs selected agent runtimes from WakeJobs. Agents append their outputs back to the Thread.
• Secretary is an in-Thread agent role, not the program controller. The Reconciler may wake Secretary; Secretary then performs semantic judgment.
• Worker tools may submit structured events such as input.required, approval.required, worker.blocked, change.requested, or delivery.submitted, but those events still go through Reconciler/Scheduler.
• auto and Symphony worker Threads use the same path: input, approval, or blocker events wake the same-Thread Secretary first; unresolved requests stay pending in a linked control resource surfaced through Inbox for the human or higher-level Secretary.
• Inbox is the ledger for input and approval lifecycle, including requests that Secretary resolved automatically. It is also the user-visible passive surface for pending approval/input: the user can inspect and act on it directly without any chat turn.
• InboxNotification envelope changes are events distributed through Pod subscribe/watch. Subscribe notifies active clients; it does not directly wake a member or create chat. Every client may refresh Inbox and display badge/toast state. Only an agent-capable client that matches runtime presence/policy and successfully claims the linked ApprovalRequest/InputRequest/control resource through leaseOwner / leaseExpiresAt may schedule a local Secretary Inbox-check job. Clients that lose the claim remain display-only. If the user is active in a main Thread, the winning Secretary may naturally bring the pending item into that conversation; if not, the item remains visible in Inbox without forcing an interruption.
• A pending control resource surfaced through Inbox is runtime/control context, not a user-authored, system-authored, or developer-authored message. Persist the real actor on the InputRequest, ApprovalRequest, or ControlEvent; InboxNotification is only the envelope. If a backend adapter must project it into a user role, label it as a runtime control event and not a human user message.
• Delivery is a stage/result package, not generic message transport. Ordinary questions, answers, steering, and checkpoints remain Messages.
• Schedules are event sources. A schedule tick is appended to a stable schedule main Thread and may split a child execution Thread only when work is noisy, long-running, worker-owned, or needs separate review.

Worker Protocol

Worker-facing minimum contract:

• Treat the worker-facing user input as Secretary-controlled unless the task brief explicitly says a human is speaking directly.
• Read the assigned control record or task brief before implementation.
• Keep ordinary clarification in chat with Secretary.
• When waiting on Secretary or user-owned authority, report the blocker and allow the Run to become waiting_input; unresolved work may move the Task or Issue to blocked.
• Use Delivery only for stage results, async handoff, artifacts, proposed patches, verification evidence, and final reports.
• In final reports, explicitly separate assigned-work evidence from follow-up candidates: new defects, missing shared abstractions, app-local glue that should move to models/drizzle-solid/xpod, live-verification gaps, or deferred cleanup. Workers may recommend follow-up, but they do not decide whether it becomes a new Issue.
• If the LinX Symphony Codex plugin is installed, prefer its linx-symphony MCP tools to check and write the delivery. The MCP helper only validates/writes the portable Delivery file; it does not directly mutate Pod Issues, Tasks, Deliveries, or acceptance state.
• Otherwise include the same terminal facts in the final report using the symphonyFinal: true JSON envelope so LinX can archive the transcript through shared control-plane use-cases; it is not a separate worker schema.
• Never use chat, Delivery, or repo docs to redefine scope, acceptance, compatibility, lifecycle state, or release boundary. Write an Implementation Change Request instead.

Workers must perform an implementation feasibility recheck before committing to execution. This is where downstream work can discover that upstream judgment was wrong, incomplete, or too broad.

If the plan cannot be fully implemented under the current control record, the worker must not silently downgrade acceptance or ship a partial substitute. Write an Implementation Change Request with:

• the failed upstream assumption;
• evidence from code, tests, logs, runtime behavior, or dependency inspection;
• what can be completed safely, if anything;
• recommended next shape: split, redesign, defer, spike/report, reduce scope, or request missing authority;
• the smallest coherent verified increment if partial progress is useful.

Workers may stop at the smallest coherent verified increment only when it still satisfies current acceptance or the control lane has revised acceptance. Otherwise the correct outcome is blocked/change-request, not incomplete work presented as done.

Workers keep execution-facing documentation current while they work. They may update progress, implementation notes within assigned scope, verification evidence, blockers, risks, failed approaches, dependency waits, and proposed adjustments. They must not silently update product semantics, acceptance, compatibility impact, authority/privacy/visibility decisions, task scope, ownership, or split strategy.

Worker documentation updates must be either append-only evidence or scoped patches to the implementation surface they changed. If a needed documentation change would alter scope, acceptance, compatibility, lifecycle state, or release boundary, the worker writes an Implementation Change Request and waits for the control lane to update the authoritative record.

Worker Closure And Attempts

Do not collapse worker completion, integration, and release into one done state. A worker thread is a work room and may be reopened or followed up later; the terminal object is the current Run, Delivery, or Task decision.

Use this minimum lifecycle:

• Run completed: the worker runtime attempt ended without waiting on more input. This does not mean the task is accepted.
• Delivery submitted: the worker packaged a final report, patches/artifacts, verification evidence, risks, and remaining work.
• Delivery accepted: Secretary/control lane checked the Delivery against acceptance and recorded accepted, rejected, partially accepted, follow-up, or reopened.
• integrated: the accepted result has been merged, applied, or otherwise verified in the target workspace. If the worker already acted in the target workspace, record integration as verified rather than inventing a merge step.
• released: the integrated result entered a release boundary. Release is only required when acceptance explicitly includes publishing, packaging, deploy, or user-visible availability.

Worker closure is therefore:

no active Run
+ latest Delivery is final
+ Secretary/control lane has recorded an acceptance/rejection/follow-up decision

Do not require release for every worker. Do require Secretary/control lane acceptance before closing a Task as completed. User acceptance is required only for user-owned intent, product semantic approval, destructive authority, external production access, long-lived grants, or final release acceptance unless an existing auto policy or grant covers it.

Repeated failed attempts must be recorded without creating duplicate Tasks.

• RunStep records each attempt fact: action tried, environment, command/tool, result, error summary, log/artifact pointer, and timestamp.
• Evidence records reusable findings distilled from attempts: failed approach, constraint, dependency behavior, blocker, or proof.
• ImplementationChangeRequest records the worker's conclusion that the current plan or acceptance cannot be completed as written.
• Report summarizes the attempt history, final result, unresolved risks, and recommended next action.

Use URI relations for traceability and duplicate avoidance, not filesystem symlinks or transcript scanning. A next worker should be able to query relevant findings before repeating work:

RunStep -> run
RunStep -> task
RunStep -> delivery
Evidence -> sourceRunStep
Evidence -> subject
Evidence -> blocks / invalidates / supports / recommends
ImplementationChangeRequest -> basedOn Evidence[]
Report -> evidence[]
Delivery -> report

If a failed attempt exposed an independent product bug or future concern, link or promote it through Idea/Issue binding. Otherwise keep it as RunStep/Evidence under the current work so the system learns without multiplying issues.

Post-Run Reconciliation And Follow-Up Extraction

Worker completion is not the end of Secretary work. After every terminal Delivery or Report, Secretary/control lane must perform a post-run reconciliation pass before closing the Task/Issue.

The pass has two separate questions:

1. Did the assigned work satisfy current acceptance with sufficient evidence?
2. Did the execution reveal new work that should be tracked separately?

Secretary must inspect the worker Report, Evidence, RunSteps, failed attempts, review findings, and any local compromises. It should extract follow-up candidates even when the worker did not label them explicitly. Typical signals:

• app-local glue that should be moved into a shared package such as @undefineds.co/models, drizzle-solid, xpod CLI, or shared runtime;
• missing repository/helper APIs exposed by repeated shell-side composition;
• live Pod/cloud/manual verification that was intentionally left out;
• schema, protocol, permission, auth, or persistence gaps discovered while implementing the assigned task;
• cleanup, migration, compatibility, release, or documentation work that is not required to accept the current Delivery but should not be forgotten;
• repeated failed approaches or flaky behavior that future work should avoid.

Secretary owns classification. A worker may propose a follow-up but must not create or close Issues, rewrite acceptance, or re-split the roadmap unless the Delivery explicitly grants that authority.

Classify each follow-up candidate as one of:

• same_issue_task: append a Task or remaining-work item to the current Issue;
• new_issue: create a separate Issue and link the source Report/Evidence/Run;
• idea: capture as an Idea because scope, value, or acceptance is not clear;
• evidence_only: keep as a finding/proof without new work;
• ask_user: escalate only when user-owned intent, authority, priority, or acceptance is required.

When creating a new Issue, link provenance back to the originating Issue, Task, Delivery, Report, Evidence, Run, Thread, and source message where available. When no new Issue is created, record why the finding is evidence-only, deferred, duplicate, or folded into the current Issue. This prevents workers from missing second-order architecture/product gaps and prevents the main thread from silently losing follow-up work after a successful Delivery.

Evidence Feedback

Completion is not a worker saying "done". Accept completion only when evidence satisfies the intended system change.

For non-trivial implementation, Design, Implementation, Tests, Examples, Docs, and Evidence should describe the same capability semantics. Accepted work must update the relevant control record status and evidence so future workers do not need to reconstruct truth from transcript.

After execution, update:

• what changed;
• which control record changed and its new status;
• what remains open;
• what was confirmed or rejected;
• what is now stale or superseded;
• which follow-up should happen next.

Measurement

Record observable events that let later agents judge whether Symphony worked: input classification, control-record updates, dispatch/steering, worker blockers, Implementation Change Requests, delivery acceptance/rejection, release-boundary changes, reopened work, and missing evidence. Metrics events must point to control records, runs, deliveries, and evidence; do not duplicate raw transcripts, prompts, secrets, or private worker context into metrics.

Hard Rules

• Do not treat every Symphony-mode chat message as an Issue.
• Do not expose Symphony binding, routing, Issue/Task analysis, worker selection, or report headings in ordinary user-facing chat. Reply like normal chat by default, and show control-plane detail only for visible state changes, blockers, handoffs, or explicit status/details requests.
• Do not treat /symphony slash arguments as an objective.
• Do not create work before binding the input to the relevant system object.
• Do not dispatch workers before updating the relevant control record enough for bounded execution.
• Do not steer active workers through unrecorded chat context.
• Do not treat breaking changes as ordinary status changes.
• Do not invent Pod paths, RDF predicates, URI templates, or shared model fields.
• Do not use runtime Session as Chat.
• Do not treat worker self-report as sufficient completion evidence.
• Do not read sibling worker transcripts unless Secretary includes them in a Delivery.

Exit

If the user asks to leave Symphony mode, return to normal behavior. Do not keep applying the control-lane rule across future turns unless Symphony is explicitly active or the user asks to continue it.