{"id":"2b42168b-d300-4244-a2f2-5ff11de029b9","slug":"task-spec","kind":"skill","name":"task-spec","summary":"From engineering intent to accepted work: native decomposition, HMAC-sealed atomic task contracts, bounded TaskMesh execution, and verifiable acceptance across Codex, Claude Code, Grok Build, Kimi, an","owner":"luanmorenommaciel","repoUrl":"https://github.com/luanmorenommaciel/task-spec","license":"MIT","licenseTier":"permissive","trust":"community","stars":3,"match":null,"fewStars":true,"format":"skill","createdAt":"2026-07-21T11:48:36.000Z","addedAt":"2026-10-21T23:31:56.695Z","logoUrl":"https://avatars.githubusercontent.com/u/108352147?u=9d6155eb3e46b6da83f80b66e8d46e6124b8d8ec&v=4","linkOnly":false,"collection":null,"skillPath":null,"categories":["productivity","developer-tools","files-documents"],"tags":["agentic","agents","bash","cli","evals","hmac","markdown","task-spec"],"runtime":"node","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-26T02:26:09.503Z","sample":false,"url":"https://conduits.dev/tools/task-spec","language":"Python","transports":["stdio"],"install":{"npm":"@luanmorenommaciel/task-spec"},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"\n\n\n\n# TaskSpec\n\n**From engineering intent to accepted work.**\n\nNative decomposition, HMAC-sealed atomic contracts, bounded execution recipes,
\nand verifiable acceptance across Codex, Claude Code, Grok Build, Kimi, Cursor, and OMP.\n\n[](CHANGELOG.md)\n[](https://github.com/luanmorenommaciel/task-spec/releases/latest)\n[](https://github.com/luanmorenommaciel/task-spec/releases/tag/v3.9.0)\n[](https://github.com/luanmorenommaciel/task-spec/actions/workflows/ci.yml)\n[](LICENSE)\n\n[Why](#why-taskspec) · [At a glance](#at-a-glance) · [How it works](#how-it-works) ·\n[Quick start](#quick-start) · [Chat](#chat-experience) · [Workflow](#workflow) ·\n[TaskMesh](#taskmesh-execution) · [Trust](#trust-boundaries) · [Repository](#repository-map) · [Docs](#documentation)\n\n
\n\n## Why TaskSpec\n\nCoding agents are good at writing code and bad at knowing when they are done,\nwhat they were allowed to touch, and who said yes. A chat transcript is not a\ncontract. A green test run is not an authorization. A merged branch is not proof\nthat the capability you asked for exists.\n\nTaskSpec gives every unit of engineering work a durable contract: the outcome,\nthe writable paths, the evidence that counts as done, the execution budget, and a\ncryptographic seal bound to that exact revision. TaskMesh executes sealed work in\nbounded rounds and records what happened. Your coding harness still writes the\ncode. TaskSpec proves the result and keeps the human decisions separate.\n\n| What you get | How TaskSpec delivers it |\n|---|---|\n| One outcome per task, small enough to accept or reject | Atomic TaskSpecs sized XS to L, with behavior-to-eval traceability |\n| Plans you can review before anything is authorized | Native decomposition into seams, swimlanes, capability legs, and leaves; review is signed |\n| Authority that cannot drift | `hmac-sha256-v3` seal over the exact task revision; a changed byte is a new revision |\n| Execution that stops instead of wandering | Recipes with round budgets, no-progress breakers, scope checks, and permission-denial parking |\n| Proof, not status labels | Canonical acceptance records, capability proof gaps, and imported operational evidence |\n| Freedom to pick the harness | Same contract for Codex, Claude Code, Grok Build, Kimi, Cursor, and attested OMP sandboxes |\n\nTaskSpec is not a coding agent, a hosted service, or a merge bot. It never merges\nor pushes your branch, it never widens the scope of a sealed task, and it does not\nclaim semantic truth about your product. It records who authorized what, what ran,\nand what evidence exists.\n\n## At a glance\n\nMeasured on the 3.10.0 candidate source on `main`.\n\n| Measure | Value | Source |\n|---|---|---|\n| CLI commands | 43 top-level, 76 including subcommands | `src/cli/commands.json`, [CLI reference](docs/reference/cli.md) |\n| Machine contracts | 58 JSON Schemas | [`spec/schemas/`](spec/README.md) |\n| Conformance fixtures | 8 task fixtures and 2 toolkit fixtures | [`spec/conformance/`](spec/conformance/README.md) |\n| Test scripts | 53 shell, 2 Python | [`tests/`](tests/README.md) |\n| Execution strategies | 5 pinned recipes | `taskspec recipe list` |\n| TaskMesh adapters | 4: Codex, Claude Code, Grok Build, OMP | [`harness/mesh-adapters/`](harness/README.md) |\n| Chat harnesses | 5, through 4 skill directories | [Skills pack](skills/README.md) |\n| Task formats | v1 to v4 readable; v3 is the authoring default | [Format v3](spec/task-spec-v3.md), [opt-in v4](spec/task-spec-v4.md) |\n| Documentation pages | 73 | [`docs/`](docs/index.md) |\n| Retained quality score | 97/100 for the 3.8.1 corridor | [Release evidence](release/README.md) |\n\n**Current status.** `main` holds the **3.10.0 integrated-toolkit candidate**. GitHub\nmarks **v3.10.0-rc.1** as Latest; it has not passed release qualification. The most\nrecent qualified release is **v3.9.0**. Native decomposition and recipes are opt-in\nwhile harness qualification and the comparative pilot are incomplete. A passing CI\nrun is evidence for its source revision, not a release or a production claim. See\nthe [release process](docs/maintainers/release-process.md).\n\n**Availability.** This repository is private. Every install command below needs an\naccount with access and an authenticated `gh` or `git` client. Distribution today:\n\n| Channel | State |\n|---|---|\n| GitHub release, Latest | `v3.10.0-rc.1`, this candidate's archive, checksums, SPDX SBOM, signed provenance, and Mesh helpers. Marked Latest for visibility; not qualified |\n| GitHub release, qualified | `v3.9.0`, with the same asset set and the retained 97/100 evidence baseline |\n| Source install | `install.sh` from a clone, the only way to get the 3.10.0 candidate toolkit |\n| GitHub Packages | Private npm package `@luanmorenommaciel/task-spec`: `3.9.0` on `latest`, `3.10.0-rc.1` on `next`. Install with a `read:packages` token and the `@luanmorenommaciel:registry=https://npm.pkg.github.com` scope. Not on the public npm registry |\n| Claude plugin marketplace | Manifests are version-matched in [`.claude-plugin/`](.claude-plugin/plugin.json); listing follows publication |\n\n## How it works\n\n```mermaid\nflowchart LR\n Intent[\"Intent and evidence\"] --> Plan[\"Reviewed decomposition\"]\n Plan --> Task[\"Atomic TaskSpecs\"]\n Task --> Seal[\"HMAC authorization\"]\n Seal --> Mesh[\"TaskMesh execution\"]\n Mesh --> Accept[\"Canonical acceptance\"]\n Accept --> Proof[\"Capability proof\"]\n Proof --> Release[\"Release decision in your CI/CD\"]\n Release -. \"incidents and observations\" .-> Intent\n```\n\n| Stage | Who decides | Durable artifact | Command surface |\n|---|---|---|---|\n| Intent | You, with the chat skill | `intent.md`, evidence digests, open decisions | `decompose init`, `example intent` |\n| Decomposition | Human reviewer | Signed plan review, TaskPlan, `TaskPlanLineage/v1` | `decompose prepare`, `review`, `compile` |\n| Atomic contract | Human authorizer | `hmac-sha256-v3` seal over `TaskRevision/v1` | `validate`, `dod`, `author-doctor`, `gate --stamp` |\n| Execution | TaskMesh, inside the signed budget | Attempts, leases, round evidence, worktrees | `mesh run`, `mesh status`, `mesh resume` |\n| Acceptance | Supervisor | `AcceptanceRecord/v1` and receipts | `mesh accept`, `accept --stamp` |\n| Proof and release | You, in your existing CI/CD | Capability proof gaps, imported operational receipts | `status --initiative`, `graph --view capabilities` |\n\nSmall work can start directly with one atomic task. Design, testing, and deployment\nattach to the work they concern; they never become mandatory swimlanes.\n\n## Quick start\n\n### Install the 3.10.0 candidate\n\nRequires Python 3.11+ and Go 1.25+ for the source-built Mesh helper.\n\n```bash\ngit clone https://github.com/luanmorenommaciel/task-spec.git \\\n \"$HOME/.local/share/task-spec-src\"\nbash \"$HOME/.local/share/task-spec-src/install.sh\" --global --copy --toolkit\nexport PATH=\"$HOME/.local/bin:$PATH\"\ntaskspec doctor\ntaskspec mesh doctor\ntaskspec recipe list\ntaskspec guide decomposition\n```\n\n`--toolkit` installs the CLI, a version-matched Mesh helper, the chat skill for\nevery harness, installed guides, and a private Python runtime with locked\ndependencies. Omit `--toolkit` for a core-only install. Use\n`--target /path/to/project --copy` for a project-local install. Existing\nunmanaged destinations are refused by default.\n\n### Prove the lifecycle in one command\n\n```console\n$ taskspec demo\nTask-Spec isolated lifecycle\n PLAN=VALID\n DOD=COMPLETE\n VERDICT=DELEGATE TIER=1\n HANDOFF=TaskHandoff/v3\n EVAL=PASS\n ACCEPTED=1\nDEMO=READY\n```\n\nThe demo creates and removes a disposable repository. It exercises planning,\nsealing, handoff, evals, and acceptance without touching your project. Every\ncommand shown in this README is indexed to the test that executes it in\n[README command coverage](docs/readme-command-coverage.json).\n\n\nPublished release v3.9.0 (no native decomposition or recipes)
\n\n```bash\nrelease_dir=\"$(mktemp -d)\"\ngh release download v3.9.0 --repo luanmorenommaciel/task-spec \\\n --pattern 'task-spec-3.9.0.tar.gz*' --pattern 'taskspec-meshd-*' \\\n --dir \"$release_dir\"\n(cd \"$release_dir\" && shasum -a 256 -c task-spec-3.9.0.tar.gz.sha256)\ntar -xzf \"$release_dir/task-spec-3.9.0.tar.gz\" -C \"$release_dir\"\nbash \"$release_dir/task-spec-3.9.0/install.sh\" --global --copy --with-mesh\n```\n\nnpm, Claude marketplace, and per-harness options are in the\n[installation reference](docs/getting-started/installation.md).\n\n \n\n\nRequirements by feature
\n\n| Feature | Needs |\n|---|---|\n| Core authoring, gate, accept | Bash 3.2+, Git, Python 3, `shellcheck`; OpenSSL, `shasum`, or `sha256sum` for HMAC |\n| Native decomposition | Python 3.11+ in the provisioned private runtime |\n| TaskMesh from source | Go 1.25+; supervised execution also needs the selected harness CLI |\n| Attested autonomous OMP | Pinned container runtime, provider configuration, external attestor. See [execution](docs/guides/toolkit/execution.md) |\n\n \n\n## Chat experience\n\nInstall once and the `task-spec` skill is available inside your coding harness.\nThe skill reads current CLI state before it acts, so plans, attempts, and\nacceptance records carry context across sessions and across harnesses.\n\n| Harness | User-level skill | Project-local skill |\n|---|---|---|\n| Codex, Kimi | `~/.agents/skills/task-spec/` | `.agents/skills/task-spec/` |\n| Claude Code | `~/.claude/skills/task-spec/` | `.claude/skills/task-spec/` |\n| Grok Build | `~/.grok/skills/task-spec/` | `.grok/skills/task-spec/` |\n| Cursor | `~/.cursor/skills/task-spec/` | `.cursor/skills/task-spec/` |\n\nStart with an outcome, not a task list:\n\n> Use task-spec. Inspect this repository and plan reliable payment ingestion:\n> handle duplicates and late updates, quarantine malformed records, and prove\n> reconciliation. Show unresolved decisions and proposed atomic tasks.\n> Deployment is outside this request.\n\nThen talk normally as the work progresses:\n\n| You say | The skill does |\n|---|---|\n| \"Why are these tasks separate?\" | Explains seams, dependencies, and independently assessable completion |\n| \"What needs my decision?\" | Lists missing product decisions and pending authorizations |\n| \"Run the authorized work.\" | Verifies seals and dispatches the eligible wave through TaskMesh |\n| \"Why did execution stop?\" | Reads the actual attempt, evidence, deadline, and remaining rounds |\n| \"Continue this initiative.\" | Reconstructs persisted state and reuses recorded decisions |\n| \"What is accepted and what remains unproven?\" | Reads canonical acceptance and capability proof gaps |\n\nReplies follow one shape: **outcome, current state, evidence or blocker, next\naction**. Plan approval, task authorization, supervisor acceptance, and deployment\nstay separate human decisions. Routine repair inside an authorized recipe does not\nneed a new decision. A denied tool action stops at the reported boundary.\n\nThe [data-engineering walkthrough](docs/guides/toolkit/chat.md) shows a full\nconversation with the internal commands and artifacts behind each reply. Skill\ninstallation is supported for every harness above; behavioral qualification per\nharness is tracked separately in [release evidence](release/README.md). Root\n[SKILL.md](SKILL.md) and its [pack mirror](skills/task-spec/SKILL.md) are\nbyte-for-byte identical.\n\n## Workflow\n\nTwo paths share one contract. Use the initiative path when the outcome spans\nseveral owners or capabilities. Use direct authoring when one small change is\nalready understood.\n\n### Initiative path\n\nThe decomposition recipe is the central authored file. Each seam owns one\nswimlane. Each leg names an observable state and its proof. Each leaf owns\nbounded writes and discriminating evals.\n\n```mermaid\nflowchart TD\n I[\"intent.md
outcome, evidence, constraints, owner, unknowns\"] --> R[\"recipe.yaml
seams, legs, tasks, decisions, objections\"]\n R --> SA[\"Seam: File intake
owner: ingestion team\"]\n R --> SB[\"Seam: Curated payment state
owner: data platform\"]\n SA --> LA[\"Leg: every input preserved and classified\"]\n SB --> LB[\"Leg: one deterministic state per payment\"]\n SB --> LC[\"Leg: reconciliation proven end to end\"]\n LA --> T1[\"T1 intake and quarantine
recipe: test-first\"]\n LB --> T2[\"T2 merge and late-update policy
recipe: test-first\"]\n LC --> T3[\"T3 integration proof
proves_capabilities: LB, LC\"]\n T1 --> T3\n T2 --> T3\n```\n\nRun these inside your project. Replace IDs, paths, and reviewer identities with\nthe real reviewed work; these are checkpoints, not an unattended script.\n\n**1. Capture intent.**\n\n```bash\ntaskspec init\ntaskspec setup signing\ntaskspec doctor\ntaskspec agent-context\ntaskspec example intent --out intent.md\ntaskspec decompose init payments --intent-file intent.md\n```\n\nEdit `intent.md`, then research the repository and author `recipe.yaml`. Local\nevidence needs exact digests. Missing ownership or an unresolved product decision\nis a blocker to record, not a gap to fill with a guess.\n\n**2. Prepare, review, materialize.**\n\n```bash\ntaskspec decompose prepare payments --recipe recipe.yaml\ntaskspec decompose status payments\ntaskspec decompose review payments --accept --reviewer --reason \ntaskspec decompose compile payments\ntaskspec plan --manifest tasks/.plans/payments/task-plan.json\ntaskspec batch --plan tasks/.plans/payments/task-plan.json\n```\n\n`prepare` validates and projects the topology; it never approves. `review`\nsigns the snapshot with the repository key. `compile` emits the TaskPlan and\nlineage. `batch` writes unsealed leaves under `tasks/`. A blocked proposal with\n`OPEN` objections is a valid outcome. See [decomposition](docs/guides/toolkit/decomposition.md).\n\n**3. Inspect and seal exact revisions.**\n\n```bash\ntaskspec validate tasks/T-...-payments.md\ntaskspec dod tasks/T-...-payments.md\ntaskspec author-doctor tasks/T-...-payments.md\ntaskspec recipe show test-first\ntaskspec gate --stamp tasks/T-...-payments.md\n```\n\nCheck outcome, writable paths, dependencies, eval quality, and budget before\nsealing. The gate runs the evals to prove they execute; failing evals on unbuilt\nwork are expected. Commit the plan bundle and leaves first, because TaskMesh\ncreates worktrees from the committed revision. See [recipes](docs/guides/toolkit/recipes.md).\n\n**4. Execute, accept, and prove.**\n\n```bash\ntaskspec mesh init\ntaskspec status --initiative payments\ntaskspec graph --initiative payments --view capabilities\ntaskspec mesh frontier\ntaskspec mesh run --initiative payments --execute\n```\n\nA run starts the currently eligible wave. Passing supervised evals wait for a\nsupervisor. `status --initiative` reports accepted tasks and unproven\ncapabilities separately. See [execution](docs/guides/toolkit/execution.md) and\n[acceptance](docs/guides/toolkit/acceptance.md).\n\n### Direct atomic authoring\n\n\n\nFor a small, understood change, scaffold one task, author its outcome and evals,\ninspect it, and seal it:\n\n```bash\ntaskspec new add-search S codex\n```\n\nOrdinary tasks without a managed recipe can use the direct handoff path:\n\n```bash\ntaskspec handoff tasks/T-...-add-search.md --backend codex \\\n --out .taskspec/handoffs/add-search.json\n```\n\nGive the handoff to the executor. After implementation, verify and accept the\nactual result:\n\n```bash\ntaskspec run tasks/T-...-add-search.md\ntaskspec accept --stamp --gold-sanity \\\n --handoff .taskspec/handoffs/add-search.json tasks/T-...-add-search.md\ntaskspec transition T-...-add-search done\ntaskspec ready --all\ntaskspec graph --check\ntaskspec status T-...-add-search\n```\n\n`run` executes evals. `accept` verifies acceptance and writes the record.\nManaged recipes always go through TaskMesh, even for a graph of one task.\nSee [first accepted task](docs/getting-started/first-task.md).\n\n## TaskMesh execution\n\nTaskMesh is the optional, repository-local control plane. It owns scheduling,\nleases with fencing tokens, worktrees, attempt records, bounded repair, and\nrecovery. It runs only leaves that already carry a valid seal, and it cannot\nwiden their scope.\n\n```mermaid\nstateDiagram-v2\n [*] --> Verify: mesh run with execute\n Verify --> Round: seal valid, dependencies ready, lease fenced\n Verify --> Stopped: stale seal, scope escape, or unavailable enforcement\n Round --> Evals: executor round completes\n Round --> Parked: permission denial reported by the harness\n Evals --> AwaitingSupervision: declared evals pass\n Evals --> Budget: evals fail\n Budget --> Round: rounds remain and progress observed\n Budget --> Parked: two rounds without progress, or budget exhausted\n AwaitingSupervision --> Accepted: mesh accept by a supervisor\n Accepted --> [*]: mesh finish prints the merge route\n Parked --> [*]: resume only after the recorded blocker is resolved\n Stopped --> [*]\n```\n\n**Recipes** resolve a versioned strategy into the task before it is sealed, so a\nlater library update cannot change authorized work.\n\n| Strategy | Use when | Internal steps |\n|---|---|---|\n| `direct` | The change is understood and small | Read context, implement, run evals |\n| `test-first` | Behavior must be pinned before code | Write a discriminating check, implement, run checks and regressions |\n| `plan-execute-verify` | Several files or a non-obvious order | Record a concise plan, execute, verify against the plan |\n| `diagnose-repair-verify` | A failure or incident | Reproduce and gather evidence, repair the evidenced cause, re-verify |\n| `research-synthesize-verify` | The answer depends on sources | Inspect authoritative sources, synthesize with revisions, verify claims |\n\nNew managed recipes default to three rounds and a two-round no-progress breaker,\ncapped by the signed budget and deadline. `mesh resume` never refunds rounds or\nrestarts the deadline; exhaustion needs reviewed successor work.\n\n**Adapters** receive one `TaskHandoff/v3`, report their exact version, preserve\nrevision and scope identity, and never receive signing keys.\n\n| Adapter | Harness | Mode |\n|---|---|---|\n| `codex-native` | Codex CLI | Supervised |\n| `claude-native` | Claude Code | Supervised; restricted tools and empty MCP config unless declared |\n| `grok-native` | Grok Build | Supervised |\n| `omp-rpc` | OMP | Supervised, or attested autonomous in a pinned non-root sandbox with per-round signed evidence |\n\nRules that matter on first use:\n\n- `mesh run` without `--execute` still creates a run, worktree, and lease. Use `--dry-run` for a preview.\n- Supervised execution is the default. Required enforcement that is unavailable refuses; nothing downgrades silently.\n- A reported permission denial parks the attempt. It is not an eval failure and never enters another repair round.\n- `mesh finish` prints the human integration route. It does not merge or push your branch.\n\nSee [execution and recovery](docs/guides/toolkit/execution.md),\n[TaskMesh contracts](docs/reference/taskmesh-contracts.md), and\n[trust boundaries](docs/trust/taskmesh-boundaries.md).\n\n## Trust boundaries\n\n\n\nFour human decisions, four separate signatures or records. No worker can produce\nany of them for itself.\n\n```mermaid\nsequenceDiagram\n autonumber\n participant H as Human\n participant TS as taskspec CLI\n participant M as TaskMesh\n participant X as Executor harness\n H->>TS: decompose review with accept\n Note over TS: plan-review HMAC over the topology snapshot\n H->>TS: gate with stamp, per leaf\n Note over TS: hmac-sha256-v3 over TaskRevision/v1\n H->>M: mesh run with execute\n M->>X: TaskHandoff/v3, no signing keys\n X-->>M: scoped changes and normalized events\n M->>TS: run declared evals in the host environment\n H->>M: mesh accept, supervised by identity\n M->>TS: accept with stamp writes AcceptanceRecord/v1\n M-->>H: finish prints the merge route\n Note over H: the human commits receipts and merges\n```\n\n| Evidence | What it establishes | What it does not establish |\n|---|---|---|\n| Plan review | Approval bound to the reviewed topology | Permission to execute any leaf |\n| HMAC seal | Shared-key authorization and integrity of one exact task revision | Author identity, isolation, or semantic truth |\n| Passing evals | The configured checks passed in their evaluated environment | A complete or correct oracle |\n| Canonical acceptance | Required task proof and authority checks passed | Deployment or production health |\n| Capability proof | Explicit composition obligations have evidence | Completion inferred from child status labels |\n| Imported operational receipt | A reported result tied to its source and artifacts | Independent verification of target health |\n| Hosted CI | The named checks passed on the named revision and platforms | Provider quality or release publication |\n\nThe [threat model](docs/trust/threat-model.md) lists what the seal defends\nagainst and what it deliberately leaves to your environment.\n\n## Repository map\n\n| Surface | Where to look |\n|---|---|\n| Normative contract | [`spec/`](spec/README.md): formats, schemas, conformance, and the triple-lock rule for changing them |\n| CLI and engine | `bin/taskspec`, `src/`: authoring, decomposition, recipes, gates, acceptance |\n| Execution | `src/meshctl/` Python cockpit; `mesh/` Go control plane |\n| Chat and adapters | [SKILL.md](SKILL.md), [`skills/`](skills/README.md), [`harness/`](harness/README.md) |\n| Learning and reference | [`docs/`](docs/index.md): getting started, guides, concepts, reference |\n| Validation | [`tests/`](tests/README.md), `spec/conformance/`, `.github/workflows/` |\n| Distribution and evidence | `install.sh`, `tools/`, [`release/`](release/README.md) |\n| The engine's own work | [`tasks/`](tasks/README.md), `.taskspec/`: dogfooded backlog and acceptance records |\n\nThe [ownership map](docs/maintainers/repository-map.md) explains change\nboundaries. Frozen release evidence and accepted task history keep their original\npaths. New how-tos belong in `docs/guides/`; canonical rules stay in `spec/`.\n\n## Documentation\n\n| Goal | Read |\n|---|---|\n| Understand the complete experience | [Toolkit journey](docs/guides/toolkit/index.md), [chat walkthrough](docs/guides/toolkit/chat.md) |\n| Get a first accepted task | [Install](docs/guides/toolkit/install.md), [first task](docs/getting-started/first-task.md), [quick reference](docs/quick-reference.md) |\n| Turn intent into contracts | [Intent](docs/guides/toolkit/intent.md), [decomposition](docs/guides/toolkit/decomposition.md), [recipes](docs/guides/toolkit/recipes.md) |\n| Execute and recover | [Execution](docs/guides/toolkit/execution.md), [TaskMesh overview](docs/getting-started/taskmesh.md), [replanning](docs/guides/replanning-and-recovery.md) |\n| Prove completion and operate | [Acceptance](docs/guides/toolkit/acceptance.md), [release and maintenance](docs/guides/toolkit/sdlc.md) |\n| Migrate existing plans | [Seamwise import and rollback](docs/guides/toolkit/migration.md) |\n| Evaluate the claims | [Five-minute reviewer route](docs/getting-started/reviewer-route.md), [release evidence](release/README.md) |\n| Inspect the contract | [CLI reference](docs/reference/cli.md), [format v3](spec/task-spec-v3.md), [opt-in v4](spec/task-spec-v4.md), [conformance levels](docs/concepts/conformance-levels.md) |\n| Understand the method | [Eval-driven development](docs/concepts/eval-driven-development.md), [decomposition concepts](docs/concepts/decomposition.md) |\n\nThis README follows patterns observed in the GitHub CLI, uv, and ripgrep READMEs:\ndirect navigation, an executable first result, and explicit limits. The\n[grounding record](docs/maintainers/readme-grounding.json) keeps the sources.\n\n## Contributing\n\nStart with [CONTRIBUTING.md](CONTRIBUTING.md), [OPERATING.md](OPERATING.md), and\n[AGENTS.md](AGENTS.md). Run the same release gate as hosted CI:\n\n```bash\nmake check\n```\n\nFormat changes update schemas, conformance fixtures, and the changelog together.\nSkill changes preserve root and mirror parity and installed resources. README\nchanges must keep every command indexed to an executing test. Publication follows\nthe [release process](docs/maintainers/release-process.md).\n\n### Contributors\n\nMaintained by Luan Moreno Medeiros Maciel.\n\nTaskSpec is built and dogfooded with coding agents working under its own contract.\nThe backlog in [`tasks/`](tasks/README.md) records which agent executed each accepted\nleaf, and [`release/`](release/README.md) retains the evidence, including the runs\nthat failed review.\n\n| Agent | Role in this repository |\n|---|---|\n| Claude Code | Authoring, execution through the `claude-native` adapter, and chat-behavior qualification |\n| Codex | Authoring, execution through the `codex-native` adapter, and release supervision |\n| Kimi | Dispatch harness target; see [`harness/engines/kimi.md`](harness/engines/kimi.md) |\n\nAgent work meets the same boundary as human work. No worker seals its own task, no\nworker accepts its own result, and no agent merges the user branch. See\n[CONTRIBUTING.md](CONTRIBUTING.md) for the full rule set.\n\n[MIT licensed](LICENSE). Report vulnerabilities through [SECURITY.md](SECURITY.md).\n\n## Retained release evidence\n\nThis generated scorecard describes the **historical 3.8.1 release corridor**. It\nis preserved as evidence, not a readiness score for the 3.10.0 candidate. The\n[release catalog](release/README.md) separates the versioned corridors.\n\n\n| Surface | Repository evidence | Status |\n|---|---|---|\n| Evidence-derived score | Only digest-matching retained artifacts earn points | **97/100**; target 97; release gate passed |\n| Contract and trust | Revision-bound authorization, compatibility, and the explicit HMAC boundary | 24/25 |\n| Lifecycle and recovery | Nested workspaces, graph recovery, atomic acceptance, and replay resistance | 25/25 |\n| Documentation and DX | Installed reviewer route, executable docs, and generated status | 20/20 |\n| Harness and packaging | All installation doors plus frozen Codex and Claude execution | 10/10 |\n| Standards interoperability | Pinned official A2A and MCP SDK conformance | 9/10 |\n| Private distribution and external proof | Hosted CI, private signed provenance, authenticated installs, and externally signed sandbox evidence | 9/10 |\n| Publication | Task-Spec 3.8.1 at `351c39908ca0` | Published |\n| Deliberately unclaimed | Semantic truth, ecosystem-wide certification, and long-running production reliability | 3 points remain unavailable by design |\n\n"}