starci

Imported from starci183/starci-skills (ex-testing/lint/scratch/_tinkle4-before/runtime/engine/builds/edd5d213cfba556fbf56b80a5a00cd832d6a8d87bca7ead19c68315e2df45920/SKILL.md). Install upstream with npx skills add starci183/starci-skills --skill edd5d213cfba556fbf56b80a5a00cd832d6a8d87bca7ead19c68315e2df45920. Copyright stays with the author.

StarCi 1.0 provides the opt-in protocol described in the execution contract. For an enrolled workflow (state.engine.schema = starci/engine@1), that document takes precedence over the 5-plus execution details below: all managed model calls and operation workers share atomic admission; required validation is fail closed; owner choices require an authenticated owner receipt; execution uses a sealed runtime pin. The existing Orca native adapter provides detection-only write isolation and serializes native writers. Do not describe its allowlists as an OS sandbox or this build as proven unattended end-to-end delivery. Updating the package alone does not enroll or migrate an existing product workflow. Follow the upgrade note for the deliberate retry boundary.

All projects in this standard use TypeScript, Next.js frontend and NestJS backend with the owner's Academy code patterns. Monorepo/single-source mappings do not authorize framework substitution. Read common architecture rules and .dist/knowledge/architecture-rules.json first. Mechanical code-pattern conformance requires executable checks with complete applicable rule/file coverage; a missing checker cannot be replaced by agent approval. Agents review design patterns and edge cases using the Markdown guidance and relevant behavior evidence.

For design review, read the applicable entries in the enterprise design pattern catalog. It covers ownership, CQRS, transactions, idempotency, outbox/inbox, durable sagas, fencing/reconciliation, resilience, scoped authority and frontend state recovery. Select from actual invariants; do not impose every pattern on every feature. The source research note records Academy/Nivo observations and primary research without certifying product behavior. Code-pattern enforcement separately defines executable coverage and unresolved checker gaps.

Before implementation or code review, read coding reference and the applicable pattern topics (stable public names like knowledge/coding-reference.json resolve from .dist after build; authored sources are the matching knowledge/**/*.yaml). Read portable source architecture and, for backend changes, backend source pattern. Academy FE/BE are inspected references containing both useful patterns and debt; they do not turn historical file counts or boilerplate into requirements. Apply one ownership/dependency pattern through the applicable Nest/Next profile and verified installed APIs. Target-project legacy code and passing tests do not replace this standard. Knowledge is maintained in English only.

For existing-source work, use executable checks before choosing repairs: starci check-stales --work <work root> --repo <id>=<git root> reads canonical freshness and source identities; optional --target values bound the inspected closure. review.verify modes stales and lint execute scripts and write attempt reports only. Nonzero findings never authorize source writes or completion refresh. A changed input means revalidation, not proof that its implementation must be rewritten. Repair the owned scope under its existing authority, rerun the scripts and required implementation checks, and obtain independent verification; see .dist/docs/source-staleness.md.

Use starci architecture check <repository root> with actual project config for FE/BE boundaries. Mono versus separate repositories changes source resolution, not module/feature responsibilities. Explicit combined FE/BE bindings share one backend-owned Work tree. Static checks complement actual repository lint/typecheck and semantic review; they do not prove DI scope, behavior, runtime readiness or product completion. See .dist/docs/architecture-check.md and .dist/docs/source-layout.md.

Before designing or configuring any external API, service or SDK integration, read its current official documentation for the intended use. Record the primary sources and actual read date, supported authentication/account/scope/lifecycle constraints, applicable callback or webhook setup, owner-only versus workflow-owned prerequisites, and a real verification plan in the owning integration declaration. Missing research returns to the owning operation; it never becomes an unsupported credential request. The workflow prepares what its authority permits, presents researched owner input through its own Orca GUI, then verifies the provider separately from credential presence. See .dist/docs/workflow-kernel.md.

Fix minor form-only defects and missing flow details directly in their owning Work or product source, then re-run the affected checks. If business behavior or a code flow is wrong, return to the owning Business/SRS or Architecture/SDS workflow, revise it under current authority, and produce fresh downstream evidence; never defer the defect into a separate ledger or refresh stale proof by assertion.

For application deployment, environment bootstrap, or changes to .stacks, read .dist/knowledge/application-stacks.json and .dist/docs/application-stacks.md. Bind placement per application component and the selected deployment package: local processes, managed containers and separately deployed application APIs may coexist. Compose/Swarm are supported package profiles, not permission to relocate an existing remote API or replace its project-selected runtime. An external dependency needs an explicit owner and failure domain; network location alone does not remove its deployment ownership. Follow .dist/docs/remote-application-api.md for remote application APIs, including APIs hosted in Kubernetes/K3s. API consumption, application rollout and cluster administration have separate contracts and verification. Use the declared inventory, encrypted custody and lifecycle entrypoints, then run applicable static checks and actual readiness/recovery checks. Installing this standard does not migrate or deploy an existing app.

An explicitly declared development profile may instead run application processes natively while dependencies remain in Docker. Both Docker-app and native-app profiles must account for the same selected components, source/build roots, endpoint contexts, ports and persistent-data custody; selecting a profile never grants teardown or live-data effects. Static profile validation does not prove startup or recovery. Preserve legacy declarations until an authorized stack migration, and do not label an undeclared legacy stack dual-mode capable.

Select execution by scope, not by prompt count or line count. Use a Plan at the start of a new large, unclear or multi-workflow outcome (for example, delivering a feature). For a clear bounded request that fits one workflow (for example, a UI or backend repair), execute that workflow directly without a Plan wrapper; read .dist/docs/standalone-workflow.md. For a small, clear, cohesive, reversible low-risk local fix, use .dist/workflows/flash.json: state the change briefly, execute and run focused checks, without Plan, workflow ceremony or a required flash keyword. Higher-impact edits cannot use flash merely because they touch few lines; route them to the appropriate bounded workflow or a Plan when their scope needs decomposition. Questions remain read-only. An existing Plan resumes at its current checkpoint; do not create or revise a Plan just because the user sent another prompt. A materially expanded or unclear scope needs planning again.

Execution has four participants in an enrolled agent-led workflow: the kernel and supervisor programs, one bounded manager model function, operation agents that each execute exactly one contract, and independent validators. The manager orders only executable action IDs authored by the kernel; it never writes workflow state, performs an operation, changes Work or answers for the owner. Only an operation is a mandatory write boundary. Workflows not explicitly enrolled in engine.coordination: agent-v1 retain their recorded coordination policy. Read .dist/docs/execution-agent-model.md before selecting an execution host. The kernel resolves dependencies, normalizes each operation's explicit input, rechecks every manager-selected action, verifies the normalized output itself and routes only that output to dependents; no participant relies on another agent's hidden conversation state.

Before creating any execution agent, load .dist/providers/catalog.json, then the selected provider's referenced index, capabilities, api, recipes and validation contracts. Run the executable provider validator and fail closed if these contracts disagree. Provider calls, arguments, lifecycle sequences and agent forms come only from this tree plus the active runtime-discovery schema; never infer them from prose, another provider or a previous runtime version. Orca additionally requires its complete public-command inventory and role allowlist, then the live orca agent-context --json signature for the selected command before effects.

Solo and orchestrated are the only execution modes. A single unrelated workflow may run solo in the current Codex, Claude or Orca session; that session combines the flexible Plan/Coordinator/workflow responsibilities while every ready operation instance maps one-to-one to one isolated background agent. At most three distinct operation agents may be active; dependency-safe operations may overlap, but one operation may never be split among several agents. Preserve gates, normalized input/output envelopes and the resumable receipt; read .dist/docs/solo-execution.md. Qwen is an operation provider, not an independent solo host in v1. Multi-workflow coordination, child worktrees, conflict ownership or cross-worktree integration require Orca orchestrated mode. In Orca every operation is a supervised native agent inside its owning workflow worktree, never inline work performed by a Coordinator and never a shell-only fallback. Do not attach unrelated workflows to an Orca parent merely to gain concurrency.

When Orca is the orchestrator, the 5-plus compatibility control loop is entirely in the workflow kernel. An explicitly enrolled agent-v1 workflow additionally uses the bounded manager function described in the execution contract; the kernel remains the sole state writer and action executor: the kernel/ folder, one file per concern, running on the declared data of model/ (record kinds, operation kinds, lanes, routes, hosts, runtimes) through the host adapters of hosts/. Every command of it is typed on one command entry, node <skill root>/bin/starci.mjs <command> ..., which forwards argv unchanged to the launcher, so no instruction ever names a module path inside the runtime; --host <skill root> is what lets a repository that shares another repository's Work tree resolve its ledger, because the host is otherwise looked for under <repo>/.claude. workflow-goal assesses the job into a goal and prints it for exactly one user approval, workflow-approve freezes it, and workflow-run allocates each ready operation to a runtime with the role, a free slot and remaining budget, uses the global ceiling of ten admitted AI jobs (including the manager while it runs) and launches eligible operation agents with disjoint write allowlists in the single workflow worktree, then accepts a slice only after the kernel itself re-runs the checks and computes the changed files from git, commits that operation, and finally runs the gates and writes the final report into .starciwork/_local/workflows/<id>/. Orca supplies only worktrees and attested agent terminals, so the same kernel runs on a Codex or Claude host; every operation still ends with one typed report (done | partial | failed | ask | blocked, file first, signal second), one operation never fans out into several agents, and a verify operation is always allocated away from the runtime that implemented the slice. The kernel must invoke .dist/hosts/orca/launch.mjs start-op with the exact nested workflow Run, parent workflow Task identity, its own terminal, a filesystem-relative workflow worktree path, operation, scope and relative spec-file. It must never embed a machine drive/root or compose task-create, worker-start, provider fallback or terminal naming calls itself. Every Orca call goes through the typed contract in .dist/providers/orca/calls.json and hosts/orca/calls.mjs: run node <skill root>/bin/starci.mjs verify before the first effect, and treat every Orca exit code as a classified result with outcome and effectState, never as an untyped error. The launcher resolves the relative worktree internally to the exact Orca selector and first proves that this terminal is the nested Run's coordinator_handle; this keeps every op question/result inside its workflow. It then creates the canonical [Op] <operation> - <scope> Task once and walks the whole operator chain from model/registry.json inside that one invocation: per candidate it starts one fresh native worker, proves prompt delivery, attests its effective provider/model and worktree, canonicalizes its terminal title, and on any failure fences and settles that Dispatch (worker-stop, worker-release must report released) before the next candidate may start. Only a proven none effect state admits fall-through; partial or unknown effects, permission, safety, ambiguity and checkpoints stop with a typed reconciliation result, and an exhausted chain is reported as worker_failed to the workflow boundary. After every settlement and before reporting workflow completion the kernel runs sweep --worktree . --from <its terminal> so no dead agent terminal is left in its worktree; live workers are never closed. The allocated runtime chooses the concrete operation agent only and never changes the normalized input/output contract, Work routing, operator ownership, criteria or authority. Because every operation in a workflow holds a disjoint write allowlist there is no shared conflict to arbitrate and no cross-worktree integration to perform; a goal, scope, authority or safety change returns to the user instead of being resolved by another agent layer.

Lifecycle correction for the compatibility paragraph above: effect settlement and terminal cleanup are separate facts. Its parenthetical "worker-release must report released" describes complete owned-resource cleanup, not the fallback gate. Only a typed, identity-bound effectState: none permits fallback; released or already_released proves cleanup, while retained identity_unproven or no_owned_resource is reported as cleanup.complete: false unless the exact terminal is closed or proved absent. A missing output, unknown effect or guessed terminal identity never permits fallback or cleanup.

For an owner-authorized clarification of an already approved goal, preserve the workflow id: first run workflow-stop --id <id> and wait for its controller to exit, then run workflow-amend --id <id> --amendment <starci/workflow-amendment@1.yaml>. The record binds the frozen goal identity, real owner provenance and bounded added effects separately from the coordinator's application decision; it never rewrites the original approval, accepted operations, evidence, decisions or unknown effects.

When the host is a plain Claude Code or Codex chat rather than Orca, the same kernel runs there on the headless host adapter (workflow-run --host-adapter headless, or STARCI_HOST=headless) with each operation as a sequential headless model process, and the chat is that workflow's monitor, never an agent layer above the kernel: follow workflow chat - one chat, one workflow, the owner's prompt as the goal, approval only on the owner's word, the kernel detached, its questions relayed verbatim, an operation the host cannot serve relayed as needing the Orca host. Read .dist/docs/workflow-chat.md for what a chat can and cannot run and how the shared store lets a workflow move between the two hosts.

For every Orca workflow child, immediately set the parent to the exact worktree controlled by the current user-designated coordinator and attest the returned parentWorktreeId with worktree show. An external Codex or Claude chat may remain that coordinator when the user selected it; never spawn or force a replacement Coordinator agent merely to satisfy a topology convention. A null or mismatched lineage blocks all operation Task creation even when the workflow Task belongs to the parent Run; orchestration membership never substitutes for UI/worktree lineage.

The Plan-specific rules below apply only when the Plan route is selected. Standalone workflows retain concrete goals, actual approval, Work/input bindings, scoped effects and verification without inventing a one-job Plan. Flash skips the workflow/load-order/build ceremony and creates no local Plan records. None of these routes expands the user's authority.

For standalone workflows and Plan-bound invocations, run node scripts/ensure-build.mjs in this skill directory and stop if the current source and .dist cannot be verified.

Before the first workflow effect, load .dist/approvals/policy.json and present one complete brief containing the goal, scope, repositories, worktree topology, operators/model chains, allowed action and effect ceilings, exclusions, completion criteria and any reserved checkpoints. Bind the actual subsequent user acceptance to the brief digest. After it is accepted, use starci approval decide for the current structured action: auto means proceed without another procedural question; need-user means stop at the reported material boundary. Worktree creation, dispatch, bounded source edits, implementation-owned tests, bounded retries, no-effect provider fallback, separately owned conflict resolution and implementation-to-architecture SDS sidearms are automatic when explicitly inside the accepted envelope. Commit, push, deploy, migration and delete are automatic only when named in that envelope. A changed goal, business/SRS intent, repository/scope/owner expansion, missing credential, unresolved business alternative, safety block, reserved checkpoint, or partial/unknown effect returns to the user. Validator success never manufactures an acceptance record.

In every execution mode, follow whole-workflow delivery: review the complete scope at entry, execute and repair within that scope without fragmented approval stops, then review the complete output at exit. True authority, business, safety and dependency blockers still stop effects. For browser workflows, check browser prerequisites at entry, not after implementation.

A coordinator sequences Plans, approves/rejects goals within delegated authority and reviews expected versus actual outputs. Executors own implementation and repair. When the accepted brief delegates bounded technical acceptance, the coordinator may record verified technical completion and report it without another formal question; a reserved exit checkpoint or changed effect envelope still returns to the user. Between workflow boundaries, wait quietly on task state; do not supervise logs, duplicate their work or report unchanged polls. See whole-workflow delivery for exceptions and authorized runtime improvement.

For product intent and target design, current accepted done Business/SRS and Architecture/SDS in .starciwork are the source of trust. Code is legacy implementation to compare against that target, not authority for requirements or architecture, even when tests pass. Read source of trust and specification repair before resolving an SRS/SDS question or a code/design mismatch. Within authorized scope, close missing cases in the owning canonical specifications, review affected consumers and re-establish current done before dependent implementation resumes; do not stop at a gap report or force completion. Existing done never forbids a necessary revision.

Normal Plans default to mode: manual. Only an explicit request to execute this Plan in mode: auto selects .dist/workflows/auto.json; read it completely before preparing the delegation. Auto keeps the complete Plan and every bounded workflow/verification gate, but replaces repetitive per-workflow confirmations with an actual user-approved Plan delegation and a recorded assistant risk assessment. It does not grant production, publication, real-data correction, runtime self-update or unresolved user choices. The auto contract defines the distinct delegated goal/result receipts and stop conditions; all per-workflow user-confirmation rules below describe manual mode. Never turn a request to add auto support into permission to activate it in existing tasks.

If the actual user explicitly delegates bounded technical approval to a named coordinator in the accepted brief, read .dist/workflows/delegation.json and .dist/docs/scoped-approval.md completely. This is an approver role on an unchanged manual Plan, not auto or a third execution mode. Combined with approvals/policy.json, its scoped assistant decisions replace repetitive direct-user technical approval steps while the envelope remains unchanged; preserve each task's actual goal brief, current risk and all verification gates. An observer has no such authority by default. Record real user-grant provenance separately from actual coordinator decisions; when native message IDs are not exposed, record that honestly, never invent user replies. Runtime maintenance cannot self-grant product execution authority.

Initialization creates ignored config.json from config.example.yaml (legacy config.example.json accepted when YAML is absent) only when config.json is missing; existing local config is never rewritten. Read local config for user-facing language, requested model/effort and the three non-operation model roles: the Fable/Astra pool serves the separately typed planner and validator functions, while the Opus/Sol pool serves the manager and technical decision function. Pool selection is quota-aware before each call and still requires eligibility and qualification. Defaults are vi, inherited host model (null), and medium; explicit task choices override those presentation defaults. Pass supported model/effort preferences when dispatch is authorized; never claim to change the current session or silently substitute unsupported settings. Runtime contracts, knowledge, and all current canonical SRS/SDS content are English; config never translates canonical specifications or changes operation-agent authority. The host-local file is not bundled into .dist, but an enrolled workflow's runtime pin seals its accepted digest so detached jobs share one configuration. See config format.

Resolve project bindings through .dist/schemas/workspace-routing.json. Source is the host containing .claude and .workspaces; its AGENTS.md and CLAUDE.md are bootstrap entrypoints installed from init/. The selected project's backend owns the canonical .starciwork for BE and FE; Plan-bound session YAML stays under .starciwork/_local/plans; standalone sessions stay under .starciwork/_local/workflows. Frontend repositories contain product source, not a second StarCi workspace. Starting or preparing a project binds those locations; it does not install bootstraps or runtime copies in routed sources. Preserve host and binding when changing directories or delegating. A projectless task or a task opened directly in FE must receive the host entry and binding explicitly; do not assume host instructions were auto-loaded. Read-only questions may be answered without a job. For every action prompt, inspect enough context to freeze a semantic classification, then select only from .dist/workflows/catalog.json.

Before choosing feature paths, read .dist/schemas/work-layout.json. One project has one bound .starciwork; its product catalog is features/index.yaml, and each actual capability owns features/<feature>/{business,architecture,ui,implementation,uat}/ as applicable. The project/repository name is workspace metadata, never an extra folder. Do not create .starciwork/<project>/, .starciwork/business/ or .starciwork/features/business/. Shared rules, data, NFRs and cross-feature journeys have one accountable feature owner and are referenced by stable IDs from other features. Create only layers with actual authorized content; FE, BE and services do not create separate copies of the project workspace. This ownership rule applies to both current typed specifications and requested SRS/SDS folder-pattern upgrades.

After resolving backend and frontend roots, run node bin/starci.mjs source-layout <backend-root> <frontend-root> before a workflow effect. The contract in .dist/schemas/source-layout.json requires the explicit host bootstrap/runtime identity and route registry, the backend-owned canonical feature Work, and the frontend manifests/source roots. It rejects another .claude/SKILL.md runtime identity, another .workspaces project/route registry, or a misplaced Work tree; it does not reject a project metadata directory merely because it is named .claude or .workspaces, and legitimate repository .stacks deployment knowledge is not host runtime state. A role-bound lifecycle using repository keys be or fe enforces the same resolved host/backend/frontend pair automatically. Treat an identity or binding failure as a source-routing defect; do not create a duplicate runtime or workspace to make the check pass. See .dist/docs/source-layout.md for the required trees and ownership rules.

Before creating a project workspace or Plan, run node bin/starci.mjs storage <resolved-backend>. Legacy .work / .starci means migration-required, not the normal naming convention; mixed trees mean conflict. Report this explicitly and coordinate migration before new planning. New records use .starciwork / .starciwork/_local; never create a parallel empty tree. Existing bound Plan bundles may resume in place under their original approvals until a safe migration checkpoint. workflows/storage.mjs retains old paths for recovery only; never rewrite frozen bindings or approval digests. Read .dist/docs/migration.md before migration; runtime maintenance alone does not authorize moving live product data.

When auto is requested, determine and present the ASAP candidate chain immediately with the full Plan: which ordered workflows can proceed first, their estimated range, and the later checkpoint. Two jobs is an example, not a fixed limit. Propose a bounded time budget together with scope and effect ceilings in that same delegation presentation, not a separate time-only confirmation round. With current valid delegation, announce each concrete goal and risk decision and cook the eligible sequence now; later job questions do not block earlier work. Use autoASAPStatus with actual authorization and current runs on resume. Candidates are not already-approved effects: recheck each predecessor, risk, evidence and remaining time. Keep waiting stages in the same full Plan. Waiting never extends authority or installs a background scheduler.

Runtime maintenance is separate from project preparation: consuming or checking an installed .claude does not authorize editing, upgrading or publishing it. Select update-knowledge only when the user explicitly requests a runtime/knowledge change in that scope. A product workflow encountering a runtime defect reports the evidence and waits for that authority; it never repairs its own rules to unblock dispatch.

On resumption or an entry-path error, reread the actual host bootstrap before diagnosing an installation failure. node scripts/check-entry.mjs <explicit-host> [claimed-entry] distinguishes a missing runtime from a stale INDEX.md reference. Do not recreate retired entrypoints or require a push because the runtime is dirty. A conflicting explicit instruction needs a replacement instruction from its authority, not a runtime rewrite; do not override it merely because disk contents differ.

The public jobs are exactly: analyze-request, prepare-work, define-business, design-architecture, design-interface, implement-backend, implement-frontend, verify-flows, review-code, publish-code, deploy-release, operate-runtime, correct-data, update-knowledge, produce-content, and retire-scope. There are no aliases or effectful fallback. analyze-request is read-only discovery with no mutation or completion claim. prepare-work explicitly selects prepare or import. Other operator modes are also exact; never union permissions.

When selecting Plan jobs, populate request-bound selection facts honestly; validators do not infer intent from natural language. Never create new requirements from missing source features: record them as openQuestions and ask the user. Existing filters means existing filters, not permission to add filters. Backend inspection alone is not implement-backend. Unit/component verification belongs to review-code or implementation checks, never verify-flows (browser UAT). Frontend includes draw/reuse and UAT; split these into extra jobs only for a separately requested deliverable or retest. Plan-wide openQuestions block all goal approvals; a workflow's openQuestions block only that workflow. Keep later unresolved workflows in the Plan instead of dropping them or asking the user to design all technical details up front.

One Plan owns the entire requested outcome, not just today's approved workflow. Follow .dist/workflows/plan.json: preserve the end-to-end delivery chain and terminal criteria in Plan v2, including explicit backend and frontend coverage. A workflow is a short bounded segment with its own goal, effects, evidence and acceptance inside that same Plan. Future execution not yet authorized is still planned work, never reuse. Reuse needs existing target/evidence references; not-applicable needs a genuine scope reason. A planning-only request must describe the whole intended delivery route without authorizing its execution. A narrow maintenance/design-only request must not grow into unrelated product stages. Record blockers against the affected segment; a repair Plan never replaces the product Plan or proves its terminal outcome. Every task presents its own goal, output and required user decisions directly; an observer is not an approval authority.

Only when the Plan route is selected for a new large, unclear or multi-workflow outcome, use the Plan template at .dist/workflows/plan.template.json. Run node .dist/scripts/plan.mjs template to obtain YAML, fill it from evidence in English, then node .dist/scripts/plan.mjs create <filled-plan.yaml> <new-plan-directory>. If repository writes are forbidden, create the same four-file bundle under the allowed task draft directory. Never substitute an unstructured Markdown analysis or patch for this Plan. Run node .dist/scripts/plan.mjs render <goal/index.yaml> and preserve its complete section/table structure in a user-accessible rendered document in config.language, translating prose without changing IDs, scope or criteria. Include Goal, areas (business/architecture/implementation/backend/frontend/UAT), coverage, terminal Plan completion, ordered workflows (purpose/input/output/criteria/estimate), workflow checkpoints, exclusions and approval. Do not paste the full document into chat by default: at every workflow goal checkpoint, lead with a short, self-contained brief and link the complete goal and rendered document. Follow the presentation contract in .dist/workflows/plan.json; a raw YAML link, tool output, opened file panel or message only to a coordinator is not an on-screen goal brief. Legacy v1 remains readable and existing approved runs remain bound to their original receipts; explicitly revise to v2 before a new goal presentation, never silently convert or fabricate approval. An empty template must fail validation. If source already appears to implement the request, distinguish source observations from verified behavior and propose a bounded verification job; do not invent changes or claim tested completion. Pure explanatory questions remain exempt.

For normal planned work, before any workflow effects, follow .dist/workflows/plan.json: draft the complete business, architecture, implementation and UAT Plan in .starciwork/_local/plans/<task-name>/index.yaml, present the complete brief in the configured user language with the ordered workflow estimates, and WAIT once for the user to approve that presented goal/effect envelope. The original task request or task-creation message is never approval of a later plan. Use presentGoal before approveGoal, binding actual presentation and subsequent user reply IDs. Do not invent receipts. Inside an unchanged accepted envelope, follow approvals/policy.json and do not stop for procedural confirmations between workflows or secondary operations. If scope changes, present it again. A Plan is a long-running sequence of workflows; planning is a preflight stage, not another workflow. Remove only owned temporary scope/session files after accepted completion and valid Work proof; preserve unfinished scopes.

Before effects, announce the selected job, why it matches, ordered operators, Work targets, and effect ceiling. Use .dist/workflows/lifecycle.mjs: valid Work, exact targets, a frozen goal (standalone or Plan-bound), and existing user authorization must bind every cell request. Unknown, vague, incompatible, read-only-as-effectful, duplicate, stale, or unapproved dispatch fails. If Work is missing, select prepare-work while preserving the original chosen job and scope; invalid Work is never overwritten.

A long prompt becomes an explicit ordered list of these jobs. Planning grants no effects or result acceptance, infers no successors, and states each pause point and accepted producer input. Accepted outputs are copied unchanged into the next separately bound job. When the same plan changes backend and frontend, implement-backend finishes first with accepted unit, backend E2E and API evidence. Frontend-only work may reuse a complete typed accepted backend receipt. implement-frontend is one complete job using the strict draw/reuse, frontend implementation and UAT gate. Its draw cell always validates/reuses the bound UI design or creates/revises it only within approved UI scope. verify-flows is a standalone explicit retest and is not silently appended.

When delegating a cell, use the exact delegationPrompt and projectSkillPath emitted by requestCell. The prompt opens this project entrypoint, never an older global skill, and carries the workflow, approved goal, cell, Work bindings, typed outputs, criteria and effect ceiling. Never substitute free-form implementation instructions. In Orca, the Workflow Monitor asserts the exact active DAG operation and passes it to the canonical supervised launcher; the Monitor is not allowed to select or start the worker manually. A Task title, terminal subtitle or provider default is never model proof; the launcher requires worker-show effective agent/model and exact worktree proof before any effect is accepted, and a mismatch fences the attempt without silently continuing or falling through. Both backend.implement and interface.implement may use their declared implementation.architecture sidearm only when the active implementation emits the typed secondary_request with reason: sds-technical-gap, secondaryOp: architecture.decide, and an explicit bounded SDS allowlist. Review findings, suggestions, open questions and inferred gaps never create that sidearm. The code worker waits, a separate architecture.decide operation owns the SDS edit/review, the Coordinator integrates it, and a fresh affected implementation attempt reruns its checks. FE secondary backend support remains limited to an explicitly granted compatible API/render repair inside the FE cell. Business, authorization, schema, or broader backend defects leave FE and require their owning job; backend repair must re-establish accepted unit and E2E proof before a fresh FE job.

Before goal approval, provide final behavior, ownership, exact repository paths, verified source hashes/anchors for existing files, proposed new paths, non-code effects, criteria, exclusions and Work targets. Never fabricate approval or acceptance. After execution, present actual results and use current digest-bound evidence before marking only selected leaves done.

For each workflow handoff, follow delivery review: show actual results against the approved criteria and link usable outputs directly in its task. UI draws, screenshots of implemented FE and UAT videos are distinct artifacts; display the relevant visuals, not only filenames or a coordinator report. Inspect failures across product, fixture, environment and contract boundaries before choosing a repair. Shared write conflicts have an explicit owner, never a last-writer-wins merge. A full Plan completes only after its terminal criteria pass; a release promotion, when requested, additionally requires verified end-to-end use of the changed runtime, not merely its unit suite.

Before asking for result acceptance, finalize the applicable verification record and call preflightCompletion(run, proposedCompletions) from .dist/workflows/lifecycle.mjs. It predicts exact selected-leaf completion read-only, including all node assertions, and grants no acceptance. Fix missing proof before presenting the result digest. Preparation targets are creation scope, not permission to mark future business/UI/code/UAT leaves done. Current Business overview, split SRS and SDS use collocated completion.review as described in source of trust, not evidence folders or copied specifications. A semantic migration changes the reviewed inputs: rereview the changed owner and affected consumers, never copy done, rewrite receipt hashes or treat runtime installation as permission to migrate product Work. This changes the Work completion record, not workflow authorization or result acceptance. For profiles using evidence bundles, stage a complete sealed bundle outside canonical records under backend .starciwork/_local/evidence-staging/<unique-name> and use publishEvidence from workflows/evidence.mjs; publication validates before moving a whole new directory. Never edit bytes beneath an already published manifest. Use a new evidence ID/name for corrected proof; preserve useful test results/media and do not reuse an approval for a changed result.

Canonical Work uses YAML workspace.yaml and index.yaml records with English structural vocabulary, English natural-language content, and direct current provenance; it contains no underscore directories, JSON, archives, histories or resource manifests. The one workspace-root _local/ directory is reserved for Plan/workflow/run/drafts/staging, is excluded from validation and semantic hashes, and never supplies canonical evidence before publication; nested _local directories remain invalid. Module ownership is business, architecture, UI with design PNGs, thin implementation parent with backend/frontend leaves, and per-flow UAT fixtures/captures. Leaves use uninvestigate, todo, or done; parent/dependency changes invalidate affected proof without rewriting stored completion evidence. An accepted SRS/SDS leaf is authored as done in the same reviewed change. Reserve todo for a genuinely unfinished draft or unresolved design task; an implementation workflow must not reopen or rewrite accepted SRS/SDS merely because stale lifecycle metadata says todo.

Read .dist/schemas/work-layout.json when creating or expanding Work. Every semantic scope can have index.yaml, child scope folders and optional assets/**; assets are payloads, not Work nodes and need no index. This recursive convention applies across Business, Architecture, UI, BE/FE implementation and UAT. interface.draw writes to the selected UI nodes, not a separate operator tree. For every large FE task it selects a small representative set of critical screens and uses built-in ImageGen with accepted business/SDS, brand, relevant UI knowledge and actual Grammar anatomy/reference inputs; it retains exact prompts, generated assets and actual tool provenance, while every remaining screen/state derives through an explicit coverage/component/state map. The tool does not expose image-model selection, so never promise or record an inferred model name. Generated direction is not exact component/render/API proof: actual Grammar implementation captures and browser UAT remain separate downstream evidence. Keep small scopes flat, shared assets under one owner, and execution captures with their implementation/UAT scope. See .dist/docs/work-tree.md for the expandable tree and ownership rules. done never locks authorized edits: re-evaluate changed content and affected dependents without claiming stale results still pass. Do not delete useful images or videos merely because a legacy folder is named evidence.

Before recording downstream delivery results, read useful verification and dependency repair. The tree organizes ownership; typed refs and dependencies form the repair graph. Keep proof appropriate to each layer, identify what was actually tested or served, and retain useful implementation/E2E/UAT results. Do not turn examples into a mandatory file inventory or duplicate Git diffs in Work.

Select tests by the actual change. During edits and workflow retries, run the affected tests and relevant lint/typecheck/build checks; do not rerun the entire repository suite per operation, poll or small fix. A required full-suite run belongs at the main-publication checkpoint, after integration, and is reused while its tested code, dependencies and configuration remain unchanged. A documentation-only follow-up needs its own applicable checks and an explicit source comparison, not another identical full run. Installing the same verified artifact uses installation/build/import smoke checks unless an environment change or failure justifies more. Preserve each run's real revision and coverage; never relabel older evidence as a new full-suite run or waive a required CI check. See the test-selection policy in that verification guide.

SRS and SDS are the project's upstream source of truth. SRS owns required product behavior; SDS owns the target technical design that realizes it. UI, frontend, backend, tests and UAT must trace to these contracts and cannot redefine them from current code. A deliberate SRS/SDS change invalidates affected downstream proof until implementation and verification are updated.

New Business uses business/overview/index.yaml for readable intent and separates business/srs/ into functional-requirements, non-functional-requirements, business-rules, data and customer-journeys. Read .dist/specifications/srs-sections.json and .dist/docs/business-srs.md before authoring. Each detailed item owns one folder and index.yaml; parent indexes aggregate without copying children. Every FR keeps its main, alternative and exception flows plus Given/When/Then acceptance together. NFRs, journeys, rules, decisions and data are independent typed leaves linked by stable IDs. Write all canonical SRS content in English. Business defines observable outcomes, not implementation design. Legacy cohesive starci/specification@2 remains readable but is not the new authoring format.

New Architecture uses a structured starci/sds-overview@1 payload at architecture/overview/index.yaml and recursive source-independent design under architecture/sds/{flows,components,contracts,data,quality,deployment,decisions,verification}/. Read .dist/specifications/sds-map.json and .dist/docs/architecture-sds.md before authoring. Write all canonical SDS content in English. Inspect only relevant source, configuration and installed APIs to understand feasibility and migration, then independently record retain/extend/correct/replace/add target decisions from accepted SRS and quality constraints; observed code is neither design authority nor completion proof. Each flow traces exact SRS requirement/flow/acceptance IDs through a logical entry point, components, interfaces, data transactions, security/performance/reliability mechanisms, deployment topology, recovery, result mapping and planned verification. Repository roles, paths, symbols, signatures, actual behavior, revisions and executed tests belong to Implementation and UAT. Shared design has one owner and consumers reference stable IDs. Legacy source-independent starci/specification@3 stays readable, but is not the new authoring format.

SRS/SDS must reason proactively and broadly about realistic main, alternative, failure and edge cases plus relevant constraints for the selected implementation slice. Foreseeable material behavior, boundaries, contracts, data, authority, assumptions and decisions must be clear enough to implement without guessing; record consequential unknowns instead of omitting them. This is comprehensive thinking, not a demand for theoretical perfection or exhaustive certainty before coding. Unresolved consequential business, security or data choices block affected effects, while a sufficiently decided slice proceeds to implementation/testing so concrete observations refine the design. Repair its owning SRS/SDS and affected dependencies, re-review the affected scope, preserve valid unrelated work and continue; never silently diverge or copy stale done.

The compatibility validators also keep pre-upstream starci/srs@3 leaves readable for recovery and explicit migration. They are not new-authoring authority. Runtime installation does not authorize product Work migration; a separately authorized migration preserves stable IDs and useful evidence, then rereviews the changed owners and affected consumers.