{"id":"bdc56872-6008-4324-8143-5778c766993c","slug":"openaccp","kind":"skill","name":"OpenACCP","summary":"Open workflow protocol for source-driven multi-agent coordination, handoffs, reviews, authority boundaries, and recoverable AI software delivery.","owner":"0fuk","repoUrl":"https://github.com/0fuk/OpenACCP","license":"MIT","licenseTier":"permissive","trust":"community","stars":2,"match":null,"fewStars":true,"format":"skill","createdAt":"2026-06-03T16:18:10.000Z","addedAt":"2026-10-22T01:15:12.609Z","logoUrl":"https://avatars.githubusercontent.com/u/278898763?u=40216cd3e9f5df1b394e9094960bf75e7751e0a4&v=4","linkOnly":false,"collection":null,"skillPath":null,"categories":["developer-tools","productivity"],"tags":["agentic-workflow","ai-agents","coordination","handoff","multi-agent","software-engineering","validator","agent-orchestration"],"runtime":"python","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-26T19:10:43.411Z","sample":false,"url":"https://conduits.dev/tools/openaccp","language":"Python","transports":["stdio"],"install":{"pypi":"openaccp"},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"# OpenACCP - Coordination Layer for AI Coding Agents\n\n**Agentic Continuous Coordination Protocol**\n\n**Stop babysitting agents. Start coordinating them.**\n\nOpenACCP is an open workflow protocol for coordinating multi-agent software work.\n\nIt gives Codex, Claude Code, Aider, OpenHands, SWE-agent, LangGraph, CrewAI, AutoGen, and the OpenAI Agents SDK a shared way to move from project facts to accepted work: `source pack`, `CARD`, `task-card`, `authority boundary`, `handoff`, review evidence, validator gates, worktrees, return wake, and final acceptance.\n\nOne agent can keep a small task moving with a good prompt or a loop. Real projects get harder: the PRD is fuzzy, specs drift, several agents work in parallel, reviewers return partial evidence, CI only proves part of the story, and the human quietly becomes the event bus. OpenACCP gives that work a coordination layer so the team knows which facts count, which agent owns which lane, what came back, and what is actually accepted.\n\n## The Moment OpenACCP Is For\n\nUse OpenACCP when your AI coding workflow has grown past \"paste a prompt and hope\":\n\n- A vague ticket, PRD, or design note needs to become agent-ready work.\n- Several agents need to work at the same time without mixing scope.\n- A returned handoff needs consume, review, or follow-up dispatch.\n- Reviewers need evidence instead of a cheerful summary.\n- A Frontier lane can keep closing B0/B1/B2 work without bouncing every question to the human.\n- Specs, decisions, and code need one recoverable source of truth.\n- CI passes, but final acceptance still needs a clear owner.\n\n## Why Teams Use OpenACCP\n\n- **Start from source facts.** Classify project material as current, reference-only, deprecated, invalid, or unknown before agents act on it.\n- **Give every agent a job.** Primary, Frontier, worker, reviewer, discovery, and validator roles each get a clear lane and authority boundary.\n- **Keep Frontier lanes moving.** Frontiers continue B0/B1/B2-safe closure, dispatch subagents when useful, and return to Primary only when the lane is truly ready.\n- **Turn output into evidence.** Handoffs, review reports, consume results, and machine summaries show what is proven, provisional, rejected, or still missing.\n- **Separate doing from accepting.** Worker output, reviewer recommendations, validator passes, Primary consume, and human final authority stay distinct.\n- **Recover from long-running work.** Prompt records, Response IDs, CARD registries, manifests, and coordination files make agent work restartable after thread or context loss.\n\n## What You Get\n\n| Need | OpenACCP gives you |\n|---|---|\n| Several agents working at once | Primary/Frontier lanes, CARDs, task cards, child ledgers, return wake, and handoffs. |\n| A rough PRD or scattered notes | Bootstrap flow for source packs, assumptions, open questions, starter specs, and first CARDs. |\n| Real code changes | Authority charters, worktree policy, scoped worker dispatch, verification evidence, and reviewer loops. |\n| Clear acceptance | Consume results that say what evidence proves before final acceptance or release decisions. |\n| Tool-neutral workflow | A protocol layer that can sit beside Codex, Claude Code, Aider, OpenHands, SWE-agent, LangGraph, CrewAI, AutoGen, or your own agent stack. |\n\n## Who This Is For\n\nOpenACCP is for people who already see the ceiling of one-off prompts and want AI agents to behave more like a small delivery team.\n\n| You are | Common pain | What OpenACCP gives you |\n|---|---|---|\n| An independent developer running several agent threads | One thread reads the spec, another edits code, another reviews, and soon nobody knows which result still counts. | Each thread gets a role, scope, authority, handoff, and status path. |\n| A startup founder or engineering lead | Agents can move quickly, but merge, release, customer impact, and risk acceptance still need a clear owner. | Execution authority and final authority are kept separate. |\n| A large repo maintainer | Migration, refactor, testing, docs, and release prep happen across branches, PRs, CI, and chat history. | Source packs, CARDs, authority charters, handoffs, review reports, and consume results connect the work. |\n| An AI coding workflow owner | The team already uses Codex, Claude Code, Aider, OpenHands, or other tools, but handoff and review practices differ by tool. | A tool-neutral coordination layer that different agents can share. |\n| A complex delivery owner | Backend, frontend, tests, security, docs, and launch work move in parallel, but only some agent output should be accepted. | A clean distinction between \"an agent produced this\" and \"the project accepted this.\" |\n| A team with only a PRD or rough product idea | The starting material needs structure before agents can execute safely. | Bootstrap turns rough material into a minimal source pack, scope boundary, assumptions ledger, open questions, starter spec, and first CARDs. |\n\nOpenACCP keeps tests, CI, code review, security review, legal review, release ownership, and engineering judgment visible inside one coordination flow.\n\n## Quick Start\n\nAsk Codex or Claude Code:\n\n```text\nInstall https://github.com/0fuk/OpenACCP as a skill + workflow kit, then follow the README startup flow.\n```\n\nStartup performs three setup steps:\n\n1. Install or load every OpenACCP skill under `skills/`.\n2. Install the Python workflow kit and run basic validation.\n3. Produce a formal report automatically as part of startup.\n\nFor manual skill installation details, see [docs/skill-install.md](docs/skill-install.md).\n\nThe post-install formal report stays short and human-readable. It summarizes validation in words and keeps command output, executable paths, local install paths, and temporary directories out of chat.\n\nAfter installation and validation, the agent asks for these setup inputs in three clear lines:\n\n1. **Facts input / project facts**: a source pack, PRD, spec, design document, facts folder, or uploaded project materials.\n2. **Working directory / local agent coordination workbench**: the place where OpenACCP may write `.openaccp`, `launchers`, `coordination`, `reports`, `handoffs`, the CARD registry, and the source pack. This is the coordination workbench.\n3. **Repo path / product code repository path**: the real product Git repository. Primary uses it to infer the current Git branch, base branch, writable scope, test entrypoints, worktree policy, and which files scoped workers may edit. This is the code workspace.\n\nIf the working directory and repo path are the same directory, say so. If there is no product repo yet, say `no repo yet`; Primary will stay in planning, packaging, and readiness mode until a repo is available. The agent uses the current conversation language unless you provide a preferred language.\n\nAfter you provide those inputs:\n\n1. Startup writes one full Primary prompt record to your working directory.\n2. Startup writes one short Primary launcher file beside it.\n3. Startup dispatches the Primary thread directly when the agent tool supports agent/thread spawn.\n4. If direct dispatch is unavailable, Startup returns one copyable short Primary launcher in chat as a fenced `prompt` block and clearly labels it as the manual fallback.\n\nThe full prompt body belongs on disk. Chat carries only the short launcher seed when manual fallback is needed, with file links or attachments used only as supporting references.\n\n## Pre-1.0 Compatibility\n\nBefore v1.0, breaking artifact schema changes bump that artifact's `schemaVersion` suffix. After upgrading, re-run the validator on stored artifacts and check `CHANGELOG.md` for the migration note.\n\n## What Happens After Startup\n\nGitHub install startup creates **one Primary prompt record first**. Primary creates and dispatches Frontier lanes later after workspace review, CARD creation, and lane analysis.\n\nThe Primary thread starts directly when the agent tool supports agent/thread spawn. If manual fallback is the only available channel, paste the short Primary launcher into a new thread. Primary then reviews the real workspace and facts before deciding how much parallel coordination is useful.\n\nPrimary does the coordination work:\n\n1. Read the facts input, working directory, repo path, and preferred language or language fallback.\n2. Classify sources as `current`, `reference`, `deprecated`, or `invalid`.\n3. Create or refresh the source pack, scope boundary, assumptions ledger, execution boundary, current manifest, source status registry, lane registry, decision registry, sequence registry, and CARD registry.\n4. Resolve the execution boundary before B2 Frontier dispatch. Primary takes the repo path as the product code entry point, then infers base branch, source roots, test entrypoints, worktree policy, writable/read-only/forbidden paths, side effects, and data risk from Git metadata, repo files, CI files, package metadata, and common project layouts. Primary asks follow-up questions only when inference is ambiguous, risky, or impossible.\n5. Split the project into CARDs before dispatching Frontier lanes.\n6. Decide how many Frontier lanes are useful based on project complexity, dependencies, risk, and parallel safety.\n7. Write full Frontier prompt records and short Frontier launchers for selected lanes.\n8. Dispatch selected Frontier lanes directly when the agent tool supports it; otherwise print fallback Frontier launchers as copyable fenced `prompt` blocks.\n\nPrimary defaults to **at least two Frontier lanes** for normal or medium-complexity projects when two safe independent CARD clusters exist. It launches one Frontier only when the project is clearly small, only one safe lane exists, or the user explicitly asks for a single lane. Broad or medium-high-complexity projects normally receive two to ten Frontier lanes. More than ten requires explicit user approval.\n\n## Manual Primary And Frontier Startup\n\nAfter the skills are installed, you can also manually start a new Primary or Frontier.\n\nManual Primary launcher:\n\n```prompt\nUse primary-orchestrator-openaccp to start OpenACCP coordination for this project.\n\nFacts input: <source pack, PRD, spec, design document, facts folder, or uploaded materials>\nWorking directory: <where OpenACCP may write .openaccp coordination files>\nRepo path: <actual product Git repository path, or \"no repo yet\">\nPreferred language: <English / Chinese / your choice>\n\nFirst review the facts, coordination workbench, and product repo path. Create or refresh the source pack, scope boundary, assumptions ledger, execution boundary, current manifest, source status registry, lane registry, decision registry, sequence registry, and CARD registry. Infer base branch, source roots, test entrypoints, and worktree policy from the repo before B2 Frontier dispatch; ask only for ambiguous or risky execution choices. Split the project into enough CARDs to support useful parallel Frontier lanes. Then return a human-readable status report, dispatch selected Frontier lanes directly when possible, and provide manual fallback launchers only when direct dispatch is unavailable.\n```\n\nManual Frontier launcher:\n\n```prompt\nUse frontier-orchestrator-openaccp for this lane.\n\nLane objective: <what this lane closes>\nAuthority: B2 lane-local unless explicitly narrowed\nWorking directory: <project path>\nFacts/source pack: <path or artifact>\nAssigned CARDs: <CARD ids or task cards>\nPreferred language: <same as Primary>\n\nContinue B0/B1/B2 lane-local closure. Dispatch worker, reviewer, discovery, or validation subagents when safe. Stay inside the lane until only final authority or missing user facts remain.\n```\n\nIf a full prompt record already exists, use a short launcher. The short launcher tells the new thread which prompt record to read, which Prompt ID to execute, which language to use, and how to report a clean read failure.\n\n## How Orchestrators Communicate\n\nOpenACCP uses classified project facts as the coordination anchor. Artifacts are the audit trail and control surface that keep those facts, authority boundaries, handoffs, and decisions visible across orchestrators.\n\n```text\nPrimary\n  -> writes CARDs, authority charters, and Frontier prompt records\n  -> dispatches Frontier lanes or records fallback launchers\n\nFrontier\n  -> reads assigned CARDs and source pack\n  -> runs B0/B1/B2 lane-local closure\n  -> dispatches worker/reviewer/discovery subagents when safe\n  -> consumes child handoffs\n  -> writes lane status, child ledger, lane-progress packet, and frontier closure proof\n\nworker / reviewer / discovery\n  -> returns handoff, review report, machine summary, or evidence summary\n  -> wakes the owning orchestrator after writing the return artifact\n\nPrimary\n  -> consumes handoffs and reviewer evidence\n  -> cross-checks Frontier closure proof before final accepted consume of a Frontier return\n  -> accepts, rejects, amends, splits follow-up, or asks for a B3 human decision\n```\n\nOpenACCP uses a return wake owner rule. A child return should not depend on a human noticing it in the sidebar. A returning Frontier wakes Primary. A worker or reviewer wakes the orchestrator that spawned it: Primary if Primary spawned it, or Frontier if Frontier spawned it. The wake is short and points to the written artifact; it is not acceptance. The owner still has to consume the evidence.\n\nWhen direct thread messaging exists, the child sends a short wake to the owner. When it does not, the child writes `.openaccp/coordination/wake-pending/<wakeId>.json` so the pending consume is visible in the coordination workbench. Heartbeat polling can still be used as a temporary safety net, but it is not the normal return path.\n\nImportant artifacts:\n\n| Artifact | Plain meaning |\n|---|---|\n| `source pack` | The current fact list. It tells agents what may drive implementation and what is only background. |\n| `scope boundary` | The line between allowed work and forbidden work. |\n| `assumptions ledger` | Explicit assumptions that are not fully proven yet. |\n| `execution boundary` | Repo path, inferred base branch, source roots, test entrypoints, worktree policy, writable/read-only/forbidden paths, side effects, data risk, and the `b2DispatchGate` that says whether product-write B2 work is ready, blocked, or coordination-only. |\n| `current manifest` | The current coordination anchor: source pack, execution boundary, source status registry, lane registry, CARD registry, and active lanes. |\n| `sequence registry` | Prompt IDs, Response IDs, handoffs, consumes, cards, active lanes, lifecycle states, and current/latest pointers. |\n| `source status registry` | Current, reference, deprecated, invalid, and unknown sources with reasons and locators. |\n| `lane registry` | Primary and Frontier lanes, project complexity, Frontier dispatch mode, lane-count reason, assigned CARDs, authority, child ledger refs, consume refs, closure refs, return-gate state, and per-lane B2 dispatch mode. |\n| `child ledger` | Worker, reviewer, discovery, validation, or task-card-only child lifecycle, return wake contract, handoff status, wake status, consume status, and remaining risk. |\n| `decision registry` | Owner questions, Primary decisions, waivers, out-of-scope decisions, blockers, and safe defaults. |\n| `CARD` | A project-level work slice large enough for lane planning. A CARD can later become several task cards. |\n| `task card` | A bounded executable task with scope, acceptance, verification, and stop conditions. |\n| `authority charter` | The permission contract: who can read, who can write, allowed effects, forbidden effects, and data risk. |\n| `prompt record` | The full role prompt saved on disk and executed by Prompt ID. |\n| `short launcher` | A compact seed that points a thread to the full prompt record. It is printed in chat only when manual fallback is needed. |\n| `handoff` | Evidence from a worker, reviewer, or discovery agent. It proves some things and leaves other things unproven. |\n| `return wake` | A concise packet that tells the owning orchestrator a child has returned and which artifact needs consume or inspection. |\n| `consume result` | The orchestrator decision about what a handoff actually proves before acceptance. For Frontier returns, a final accepted consume should cite the `closureId`, `laneId`, or closure path in `basisRefs` and validate against that `frontier closure`. |\n| `lane-progress packet` | A stage packet showing useful Frontier progress. It stays inside the lane by default and becomes Primary evidence only when closure is ready. |\n| `frontier closure` | The gate proof for whether a Frontier can keep working, close, or return to Primary. A Primary-ready packet is valid only when this proof shows that all visible remaining gaps are final-authority-only or explicitly out. |\n| `formal report` | Human-readable status: what changed, progress, area, goal, gaps, next action, and evidence. |\n| `machine summary` | Compact locators for downstream agents and validators. |\n\n## Role Model\n\n| Role | What it does | Authority boundary |\n|---|---|---|\n| `Primary` | Owns project-level coordination, CARD decomposition, lane dispatch, final consume, and final acceptance decisions. | Keeps final acceptance separate from worker claims, reviewer recommendations, and validator pass. |\n| `Frontier` | Owns one lane. It keeps closing B0/B1/B2-safe work by refreshing backlog, dispatching subagents, consuming child handoffs, and writing lane-progress packets. It prepares a Primary-ready packet only when the return gate proves no lane-local safe work remains. | Runs lane orchestration and reserves B3 final authority for Primary or the human owner. |\n| `worker` | Executes one bounded task card and returns verification evidence. | Stays inside the assigned task card, authority charter, and stop conditions. |\n| `reviewer` | Performs read-only review of scope, correctness, verification, side effects, and overclaiming. | Stays read-only and returns recommendations as evidence. |\n| `discovery` | Reads facts, classifies gaps, and prepares safe next actions. | Keeps source promotion under explicit authority. |\n| `human owner` | Decides product intent, risk acceptance, customer-visible release, public publication, production launch, and high-risk exceptions. | Receives questions only when the next useful step needs owner facts or owner-reserved final authority. |\n\n## B0 / B1 / B2 / B3\n\nThese levels answer one practical question: **how much authority does this agent have right now?**\n\n| Level | Plain meaning | Typical actions |\n|---|---|---|\n| `B0` | Read-only discovery and review. | Source discovery, risk scan, evidence review, backlog refresh, source classification. |\n| `B1` | Package preparation. | CARD shaping, task-card drafts, verification matrices, owner questions, handoff schema, dispatch-ready packets. |\n| `B2` | Scoped execution under an authority charter. | Worker dispatch, worktree setup, bounded implementation, focused verification, child handoff consume. |\n| `B3` | Final authority. | Primary may act only on decisions listed in `delegatedFinalAuthority`; production launch, public publication, customer-visible release, and risk waiver stay with the human owner by default. |\n\nThe key rule: **a B3 blocker still leaves B0/B1/B2 work available.** If agents can still discover facts, narrow scope, prepare packages, dispatch scoped workers, or add review evidence, they keep moving.\n\n## CARD Decomposition\n\nGood CARDs are the difference between one overloaded Frontier and several useful lanes.\n\nFor a normal product or medium-high-complexity project, Primary usually creates **10-20 project-level CARDs**, and those CARDs may later expand into dozens or hundreds of concrete task cards. That gives Frontier lanes enough independent surface area to work in parallel.\n\nPrimary scans the facts for product domains before cutting CARDs. Examples include:\n\n- product workflow and user journeys,\n- backend/API and service contracts,\n- frontend/UI surfaces when the facts mention them,\n- desktop/mobile/native/Electron/Tauri surfaces when the facts mention them,\n- data model, storage, migration, import/export, or analytics,\n- integrations, external systems, and platform behavior,\n- authentication, authorization, privacy, compliance, and data risk,\n- testing, QA, accessibility, performance, observability, and CI,\n- docs, release, operations, deployment, and rollback.\n\nCreate frontend, UI, Electron, mobile, or compliance lanes when the project facts name those surfaces. If the PRD, spec, or source pack explicitly names Electron, UI, frontend, desktop shell, mobile, or another surface, Primary should create CARD coverage for that surface instead of treating the project as backend-only.\n\nCARDs are then grouped into Frontier lanes. A lane can own several related CARDs, and each lane has a clear objective plus enough independence to make parallel work useful.\n\n## Skills\n\nOpenACCP skills are installable agent workflow instructions. Each skill maps to a real coordination role or governance action.\n\n| Skill | When to use it | Why it matters |\n|---|---|---|\n| `primary-orchestrator-openaccp` | Start or run project-level coordination. Use it for CARD decomposition, lane dispatch, final handoff consume, and acceptance decisions. | Keeps the project moving without mixing provisional agent output with final acceptance. |\n| `frontier-orchestrator-openaccp` | Run one bounded lane. Use it for lane backlog, discovery, package preparation, worker/reviewer dispatch, and child handoff consume. | Helps avoid early Frontier return when B0/B1/B2 work can still continue. |\n| `worker-openaccp` | Execute one narrow task under a task card and authority charter. | Keeps implementation scoped and evidence-backed. |\n| `reviewer-openaccp` | Review a task card, diff, branch, handoff, prompt, or status artifact. | Turns \"looks okay\" into an approve/amend/reject/split-follow-up recommendation with evidence. |\n| `discovery-openaccp` | Run read-only fact discovery when scope, source status, risk, or next safe action is unclear. | Prevents agents from treating guesses as facts. |\n| `source-pack-openaccp` | Create, review, or update source packs and manifests. | Keeps current, reference, deprecated, and invalid sources separate. |\n| `bootstrap-openaccp` | Start from a rough PRD, idea, issue list, or scattered notes. | Builds the first source pack, scope boundary, assumptions ledger, starter spec, and CARDs. |\n| `handoff-consume-openaccp` | Decide what a handoff proves before merge, release, follow-up dispatch, or acceptance. | Prevents \"a file exists\" from becoming \"the project accepted it.\" |\n| `formal-report-openaccp` | Report project, lane, review, validation, or release-readiness status. | Gives humans stable, readable status without machine-log noise. |\n| `human-explain-openaccp` | Explain orchestration status in plain language. | Translates Prompt IDs, lanes, handoffs, and B0/B1/B2/B3 into delivery meaning. |\n| `validator-openaccp` | Validate artifacts before dispatch, consume, reports, launchers, or release packaging. | Checks structure, encoding, source status, authority boundary, overclaiming, and public package hygiene. |\n\n### Field-evolved rule set\n\n`field/` holds the author's current production rules (2026-10), evolved from the role model above while shipping a real multi-agent project: a five-gate release paradigm (`5gate`), three-way verification, independent senior review, unattended pushing with wake fallbacks, compact-safe checkpoints, and construction rules. See [`field/README.md`](field/README.md) for the mapping and install notes. Written in Chinese.\n\n## Language Contract\n\nIf the user chooses a preferred language, all Primary, Frontier, worker, reviewer, discovery, and formal report replies use that language as the main language.\n\nFor example, if the preferred language is Chinese, the reply is Chinese-first. Keep fixed technical terms in English only when they are useful as terms: `Primary`, `Frontier`, `worker`, `reviewer`, `handoff`, `validator`, `source pack`, `authority boundary`, `Prompt ID`, `Response ID`, `CARD`, `task-card`, `B0/B1/B2/B3`, `CI`, `README`, `CLI`, `JSON`, `schema`, `Electron`, or exact file names. A Chinese report keeps long explanatory paragraphs in Chinese.\n\n## Core Technology\n\nOpenACCP is a reusable coordination layer for agent work.\n\n### Source-Driven Coordination\n\nWork starts from current facts. A PRD, old spec, screenshot, chat note, or draft becomes current truth only after source classification. OpenACCP asks agents to classify source status:\n\n- `current`: may drive implementation.\n- `reference`: may provide background while current sources continue to define scope.\n- `deprecated`: replaced by newer material.\n- `invalid`: unreadable, contaminated, role-mismatched, stale, or untrusted.\n\n### Authority Boundary\n\nWorker output, reviewer recommendations, Frontier synthesis, and validator pass remain evidence until B3 final authority accepts them.\n\n### Active Closure\n\nPrimary and Frontier turn blockers into the next safe B0/B1/B2 action whenever possible:\n\n- Can this gap be reduced by B0 discovery?\n- Can it be turned into a B1 package?\n- Can a scoped B2 worker or reviewer handle it?\n- Is the remaining issue truly B3 final authority?\n\nFrontier returns the lane to Primary only when all visible remaining gaps are final-authority-only or explicitly out.\n\n### Handoff Consume\n\nA handoff is evidence that becomes completion only after consume and acceptance. The consuming orchestrator checks scope, changed files, verification evidence, skipped checks, reviewer findings, data risk, authority limits, and overclaims.\n\nWhen Primary final-accepts a Frontier return or Primary-ready packet, the consume result cites the closure proof in `basisRefs` and is checked against that `frontier closure`. That cross-check keeps a stage-progress packet from being treated as final lane acceptance.\n\n### Human-Readable Status\n\nOpenACCP rejects machine-log replies as the main user-facing answer. A useful status says what changed, what is proven, what is provisional, what is missing, and what happens next.\n\nEvery Primary, Frontier, worker, reviewer, discovery, bootstrap, and validation reply uses `human-explain-openaccp` style. Status-like replies end with a practical recommended next step. If the agent can continue, the answer names the next Primary-owned or Frontier-owned action. If human input is needed, it names the exact path, fact, repo boundary, branch, source root, test entrypoint, approval, or decision.\n\n## Minimum Useful Setup\n\nThe smallest useful OpenACCP package is the single-worker flow. It matches `examples/single-worker-flow/` and contains nine artifacts:\n\n```text\nsource pack\ntask card\nauthority charter\nworker handoff\nreview report\nconsume result\nstatus report\nmachine summary\nformal report\n```\n\nMulti-lane coordination adds these artifacts when Primary needs Frontier lanes, execution boundaries, and shared state:\n\n```text\nscope boundary\nassumptions ledger\nCARD registry\nexecution boundary\ncurrent manifest\nsequence registry\nlane registry\nchild ledger\nsource status registry\ndecision registry\nfrontier closure\n```\n\nWhen the minimum package inputs are missing, start with `bootstrap-openaccp` so implementation begins from task cards, acceptance criteria, verification plans, and stop conditions.\n\n## Repository Map\n\n```text\ndocs/        Concepts, role model, authority model, bootstrap, coordination, validator rules.\ntemplates/   Reusable Markdown templates for source packs, specs, prompts, reports, handoffs.\nopenaccp/    Python package, CLI, validator, and packaged JSON Schemas under openaccp/schemas/.\ntools/       Validator and helper CLI.\nskills/      Portable agent skills for using OpenACCP workflows.\nexamples/    Strict fixtures and concept examples.\n```\n\n## Examples\n\n- `examples/single-worker-flow/`: complete strict-validation fixture.\n- `examples/prd-only-bootstrap/`: bootstrap fixture for teams starting from rough material.\n- `examples/primary-two-frontier-kickoff/`: concept example for Primary-generated Frontier launchers after CARD and lane analysis.\n- `examples/primary-orchestrator-flow/`: concept example for final-authority dispatch and consume.\n- `examples/frontier-lane-flow/`: concept example for lane authority.\n- `examples/multi-frontier-closure/`: strict fixture for execution boundary, lane registry, child ledger, source status, decision registry, and Frontier closure.\n- `examples/multi-worktree-review/`: concept example for multiple workers and reviewer sidecars.\n\nThe first two are best for direct validation. The other examples show shape and vocabulary for larger project packages.\n\n## Local CLI\n\nFor a local trial:\n\n```bash\ngit clone https://github.com/0fuk/OpenACCP.git\ncd OpenACCP\npython -m pip install -e .\nopenaccp --version\nopenaccp-validate --version\n```\n\nIf you only have a rough PRD or scattered material, create a starter package:\n\n```bash\nopenaccp init ./my-openaccp-package\nopenaccp init ./my-openaccp-package --write\n```\n\n`openaccp init` is a dry run by default. It is a bootstrap fallback. For real projects, install the skills first, then let Primary create project-specific prompt records and launchers from your facts input, working directory, and repo path.\n\n## How It Compares\n\nOpenACCP sits around the tools that run agents.\n\nA prompt tells one agent what to try next. A loop keeps one agent moving until a check passes. A spec tells agents what the product should become. OpenACCP coordinates the project around all of that.\n\nLoops help an agent finish a task. OpenACCP helps a team of agents finish a project.\n\n- **Codex, Claude Code, Aider, OpenHands, and SWE-agent** are strong places to run coding work. OpenACCP gives that work a shared source pack, CARDs, authority boundaries, handoffs, return wake, reviews, and consume decisions.\n- **LangGraph, CrewAI, AutoGen, and the OpenAI Agents SDK** help teams build agent frameworks, flows, graphs, tools, and application-level agent behavior. OpenACCP adds the project delivery layer: which facts count, who can act, what evidence came back, which returns need consume, and who can accept the result.\n- **Agent loops** keep one lane of work alive. OpenACCP keeps multiple lanes aligned, especially when a returned handoff, reviewer result, or Frontier closure needs the right owner to consume it.\n- **Spec-driven workflows** make intent clearer. OpenACCP carries that intent into execution, review, handoff, and final acceptance so the source facts remain visible after agents start changing files.\n\nThe practical difference is simple: OpenACCP lets you keep your current agent tool while adding a shared coordination protocol for source facts, roles, authority, evidence, and acceptance.\n\n## Public Package Hygiene\n\nThe public repository contains public-safe docs, templates, schemas, examples, CLI, and validator code. Keep private response logs, private source packs, local absolute paths, customer material, credentials, and production logs in ignored local paths such as `.openaccp-local/` or your team's private workspace.\n\nBefore release, run:\n\n```bash\npython tools/openaccp_validate_selftest.py\npython tools/openaccp_validate.py --artifact . --ruleset public-package --strict\npython -m build\npython -m twine check dist/*\n```\n\nThen install the built wheel or sdist in a clean environment and run a small validator smoke test. The validator checks structure, common leakage patterns, and common overclaims. Pair it with a dedicated secret scanner and human review before a formal release.\n\n\n"}