{"slug": "agentic-project-kit-a-control-harness-for-llm-assisted-coding-via-repo-state", "title": "Agentic Project Kit – A control harness for LLM-assisted coding via repo-state", "summary": "A local Python CLI called agentic-project-kit has been published to PyPI to govern AI-assisted repository work through contracts, gates, evidence, handoffs, policy selection, task tracking, GitHub automation and release validation. The kit generates repository scaffolding including `.agentic/project.yaml` as a machine-readable project contract, `AGENTS.md` agent rules, `docs/TEST_GATES.md` evidence matrix, `.agentic/todo.yaml`, a GitHub Actions CI workflow and a `sentinel.yaml` document and task checker, and its deterministic Successor Handoff Package writes `successor_context.yaml`, `source_manifest.json`, `validation_report.json`, `execution_contract.json` and `successor_prompt.md` so new chats verify the package and execution contract rather than chat memory. The project positions these as governance aids rather than semantic-completeness or production-readiness claims, aimed at reducing context drift from stale handoffs, unclear branch rules and missing test evidence.", "body_md": "Handoff architecture: the deterministic Successor Handoff Package writes `successor_context.yaml`, `source_manifest.json`, `validation_report.json`, `execution_contract.json`, and `successor_prompt.md` under `docs/reports/handoff-packages/latest/` for this repo or `.agentic/state/handoff/packages/latest/` externally. New chats verify package and execution contract, not chat memory.\n\n`agentic-project-kit` is a local Python CLI for governing AI-assisted repository work with contracts, gates, evidence, handoffs, policy selection, task tracking, GitHub automation, and release validation.\n\nGenerated website: [https://vfi64.github.io/agentic-project-kit/](https://vfi64.github.io/agentic-project-kit/).\n\nExternal finding adjudications and exact retest contracts are available with\n`agentic-kit greenfield status --json`. The generated\n`docs/reports/greenfield/external-findings-status.json` distinguishes Kit fixes\nfrom consumer VERIFIED_FIXED. Maintainers regenerate it through a signed\n`agentic-kit greenfield export` plan. Opt-in `release.evidence_archive: true`\nadds the separately signed final E1 archive gate to release run, after publishing\nand DOI checks pass; committed evidence contains bounded step results and gate\nattribution. When the workspace has `site/scripts/build.py`, E1 declares\n`projection_paths` in its signature, regenerates the canonical Pages fallback after\nwriting evidence, and includes it in the archive commit. A rendering failure stops\nbefore commit or push; workspaces without that optional site are unchanged.\nSee `docs/reports/greenfield/KIT-GF-066-machine-readable-evidence-2026-10-13.md`.\n`release.changelog_summary: curated` writes only the curated summary lines into a\nrelease's CHANGELOG section (by default the Unreleased entries, which must all be\ncovered) instead of combining them with the generated PR-title list. Release run\nreports C3 as `WAITING` while the package-index run waits for an environment\napproval in GitHub, settles C3 from the finished run, and resumes an unchanged,\nalready approved gate without asking again.\n\nAI-assisted development works best when context is explicit, current, and machine-checkable. Otherwise, agents drift into stale handoffs, unclear branch rules, missing test evidence, and unstructured logs.\n\nThe kit turns those lessons into reusable repository scaffolding.\n\nGoal: make repository state, handoffs, documentation coverage, tasks, release state, and policy expectations visible enough to reduce context drift.\n\nCookiecutter-style generators create initial files. `agentic-project-kit` keeps AI-assisted repository work reviewable after the first commit.\n\nA generated project includes machine-readable state, current handoff files, documentation coverage expectations, task gates, local health checks, release-state validation, policy-pack fixtures, and evidence conventions. These are governance aids, not semantic-completeness or production-readiness claims.\n\nA generated project includes:\n\n- professional GitHub repository structure\n- `.agentic/project.yaml` as a machine-readable project contract\n- recommended project profiles and policy packs\n- `AGENTS.md` with stable agent rules and closeout expectations\n- `docs/PROJECT_START.md` for first-run decisions\n- `docs/STATUS.md` as compact current-state dashboard\n- `docs/TEST_GATES.md` as evidence matrix for different change types\n- `docs/handoff/CURRENT_HANDOFF.md` and`STANDARD_AGENT_PROMPT.md`\n- `.agentic/todo.yaml` plus rendered`docs/TODO.md`\n- GitHub Actions CI workflow\n- pull request template and agent-regression issue template\n- GitHub Copilot instruction file\n- pre-commit configuration\n- bounded diagnostic log staging script\n- `sentinel.yaml` for document and task checks\n- minimal package/test skeleton for Python projects\n\nInstall the package from PyPI in a virtual environment:\n\n```\npython -m venv .venv\nsource .venv/bin/activate\npython -m pip install agentic-project-kit\nagentic-kit --version\n```\n\nHistorical first-contact findings:\n`docs/reports/V1_0_1_DOCKER_PYPI_FIRST_CONTACT_20260820.md`.\n\nGit is a system prerequisite for `agentic-kit init` and Git-backed workflows.\n`pip install agentic-project-kit` cannot install Git portably across macOS,\nLinux, and Windows. Install Git with your operating-system package manager or\ninstaller before creating a new governed repository.\n\nFor Kit development from the public source projection:\n\n```\npython -m venv .venv\nsource .venv/bin/activate\npython -m pip install \"agentic-project-kit @ git+https://github.com/vfi64/agentic-project-kit.git@main\"\nagentic-kit --version\n```\n\nFor Kit development from a local checkout:\n\n```\npython -m venv .venv\nsource .venv/bin/activate\npython -m pip install -e \".[dev]\"\n```\n\nRun gates:\n\n```\npytest -q\nruff check .\nagentic-kit check-docs\nagentic-kit doctor\nagentic-kit --version\nagentic-kit --help\n```\n\nFirst-chat route selection is in `docs/ONBOARDING.md`. It separates creating a\nnew governed project, adding the Kit operating layer to an existing repository,\nand working on this Kit repository. Use `agentic-kit onboarding measure` to\ncheck that the onboarding guide still matches the command manifest and\nworkspace-detection message.\n\nFor the generated install and usage walkthrough, including the PyPI install\npath, the source install path, a Docker-based safe package test, new\nrepositories, and existing repositories, see\n[https://vfi64.github.io/agentic-project-kit/quickstart/](https://vfi64.github.io/agentic-project-kit/quickstart/).\n\nEvidence labels: Historical PyPI Validation means The first public PyPI validation confirmed a package from `pypi.org`; Post-fix Build/Checkout Validation covers local checkout/wheel tests; Post-release PyPI Validation covers later packages.\n\nDocker without an official registry image uses the local source image:\n\n```\ngit clone https://github.com/vfi64/agentic-project-kit.git\ncd agentic-project-kit\ndocker build -t agentic-project-kit:local .\ndocker run --rm -v \"/path/to/repo:/work\" agentic-project-kit:local doctor --root /work\n```\n\nCreating a new repository inside Docker also needs a Git identity for the initial convenience commit:\n\n```\ndocker run --rm \\\n  -e GIT_AUTHOR_NAME=\"Your Name\" \\\n  -e GIT_AUTHOR_EMAIL=\"you@example.com\" \\\n  -e GIT_COMMITTER_NAME=\"Your Name\" \\\n  -e GIT_COMMITTER_EMAIL=\"you@example.com\" \\\n  -v \"$PWD:/work\" \\\n  agentic-project-kit:local init my-new-project --type generic --kit-source none\n```\n\nWithout that identity the project files are still created, but the initial Git\ncommit is skipped with an explicit warning. GitHub operations inside Docker\nrequire explicit `gh` and SSH credentials; no secret should be baked into the\nimage.\n\nCreate a new project interactively:\n\n```\nagentic-kit init\n```\n\nCreate a new Python CLI project non-interactively:\n\n```\nagentic-kit init my-new-project \\\n  --type python-cli \\\n  --description \"My new project\" \\\n  --license MIT \\\n  --github-actions \\\n  --pre-commit \\\n  --agent-docs \\\n  --logging-evidence\n```\n\nThen enter the generated project and run:\n\n```\ncd my-new-project\npython -m venv .venv\nsource .venv/bin/activate\npip install -e \".[dev]\"\npytest -q\nagentic-kit check\nagentic-kit doctor\n```\n\nSee `docs/examples/minimal-python-cli.md` for a small end-to-end example showing how a generated Python CLI project gets project state files, agent instructions, documentation gates, task gates, and a local doctor check.\n\nGenerated projects contain `.agentic/project.yaml` as a machine-readable project contract and a standard `.gitignore` for local Python/tooling byproducts. The contract records the project name, description, project type, selected profiles, selected policy packs, and basic governance expectations.\n\nProfiles describe what kind of repository the project is, for example `generic-git-repo`, `markdown-docs`, `python-cli`, `python-lib`, `git-github`, or `release-managed`.\n\nPolicy packs describe which development rules are recommended for the project goal, for example `starter`, `prototype`, `solo-maintainer`, `agentic-development`, `release-managed`, or `documentation-governed`.\n\nBy default, `agentic-kit init` recommends profiles and policy packs from the selected project type and enabled features. You can override them explicitly:\n\n```\nagentic-kit init my-docs-project \\\n  --type generic \\\n  --profiles generic-git-repo,markdown-docs \\\n  --policy-packs starter,documentation-governed\n```\n\n`agentic-kit doctor` validates the project contract when `.agentic/project.yaml` is present and reports selected profiles and policy packs.\n\nAfter `agentic-kit workspace init --root PATH --execute`, `.agentic/config.yaml` enables external workspace health mode without the self-hosting Kit documentation set. `agentic-kit check`/` agentic-kit check-docs` inspect `.agentic/state/` and `.agentic/registries/`; `agentic-kit governance check`, `agentic-kit doctor`, `agentic-kit standard-gates-audit-suite`, and `agentic-kit slice gate --kind planning-doc` use external gate sets. `doctor` reports `SKIP`/` WARN`, skips not-applicable Kit checks plus repo-local source audit, treats target documentation lifecycle remains project-owned, verifies packaged command manifest availability, and treats Kit-specific version drift as project-owned release governance. `rules snapshot`/` rules acknowledge` use external workspace rule sources (`.agentic/rules/README.md`, `.agentic/state/status.md`); `repo_head` drift is a Rule-Ack warning, source snapshot drift remains blocking. Carriers: `.agentic/state/handoff/transfer_handoff_reports/`; packages: `.agentic/state/handoff/packages/latest/`. External first-cycle workspace start skips post-merge handoff checks only before a successor package exists; `transfer status` reports `NO_COMMAND` for empty inbox. PR/merge preflights only auto-clean allowlisted volatile carriers such as `.agentic/rule_ack/current.json`; `workspace init` ignores `.agentic/tmp/` and `.agentic/rule_ack/`; product files stay nonvolatile unless explicit policy classifies them safely. When a clean foreign checkout is currently on a branch without `.agentic/config.yaml`, `transfer branch-switch` and `transfer sync-main --main-branch BRANCH` may switch to an external target branch that contains `.agentic/config.yaml` before requiring external rule acknowledgement. For external admin refresh, `transfer admin-refresh-pr --main-branch BRANCH` may create the refresh branch from `origin/BRANCH` without checking out a basis branch that is already active in another worktree. Run `transfer pr-merge-safe` after fresh context, rule acknowledgement, and clean-except-known-transient worktree.\n\nExternal `.agentic/transfer/inbox` and `.agentic/transfer/outbox` are local transfer work directories; a fresh Git checkout may not contain them until a transfer command creates them.\n\n`agentic-kit doctor` activates lightweight policy-pack checks from `.agentic/project.yaml`.\n\nThey verify structural prerequisites:\n\n- `solo-maintainer` expects status, handoff, sentinel, and task gate files.\n- `agentic-development` expects agent instructions, test gates, handoff, and the architecture contract.\n- `release-managed` expects changelog, citation metadata, and Zenodo metadata.\n- `documentation-governed` expects the documentation coverage matrix and architecture contract.\n- `starter` and`prototype` expect basic README/status scaffolding.\n\nThe policy-pack checks are structural. They prove that the selected policy pack has its required fixtures, not prose completeness or release readiness.\n\nUse `agentic-kit doctor` as the compact repository health check:\n\n```\nagentic-kit doctor\n```\n\nIt reports project files, workspace manifest status, project contract status,\npolicy-pack checks, documentation gates, task validation, and version drift.\n`SKIP` means not applicable; `WARN` means advisory. The command exits non-zero\nonly when required checks fail.\n\n`agentic-kit check` and `agentic-kit doctor` treat a directory with no Kit\nmarkers as `not an Agentic Project Kit workspace` and exit non-zero with the\nnext safe setup command instead of an internal traceback. A freshly generated\nproject uses `.agentic/project.yaml`; `doctor` reports the operating-layer\n`.agentic/config.yaml` checks as `SKIP` there instead of warning that the new\nproject is implicitly legacy.\n\nUse the deterministic successor handoff package before switching chats or continuing in another LLM:\n\n```\nagentic-kit transfer chat-switch-complete --render-prompt\n```\n\nFor an existing external manifest workspace, `agentic-kit kit status --json` detects its own Kit environment without relying on global PATH. On a work branch, `agentic-kit kit update --version X.Y.Z --json` plans adoption of an exact released version. Its signed execution updates that environment, preserves customized CI while raising both managed pins, synchronizes the target version's command entrypoints and runs check/doctor. See [workspace Kit maintenance](https://github.com/vfi64/agentic-project-kit/blob/main/docs/reference/HUMAN_WORKFLOW_COMMANDS.md#workspace-kit-maintenance-kit-gf-051021) for approval, configuration and recovery details.\n\nFor local development in this repository, run it through the project environment:\n\n```\n./.venv/bin/agentic-kit transfer chat-switch-complete --render-prompt\n```\n\nThe command writes a machine-readable successor context, source manifest, validation report, and copy/paste successor prompt under:\n\n```\ndocs/reports/handoff-packages/latest/\n```\n\nThe successor package separates the committed projection head from the final repository identity. `validation_report.json` records the HEAD used to generate the committed package. After an admin refresh commit, `post-merge-check` may report `successor_package_head_status=refresh_only_descendant` and `successor_package_current_head=<sha>` when the only intervening changes are generated handoff refresh/projection files. That post-merge evidence is the exact final-HEAD authority; do not rerender and recommit projections only to chase their own commit SHA.\n\nIn external workspace mode the default package path is `.agentic/state/handoff/packages/latest/`. It updates canonical chat-switch projections, including the initial `START_NEW_CHAT_PROMPT.md` when missing. A successor chat uses `successor_prompt.md`, runs `agentic-kit transfer repo-status`, `agentic-kit check --root .`, and `agentic-kit doctor --root .`, and stops unless `validation_report.json` is `PASS`.\n\nAfter a PR merge, run `agentic-kit transfer post-merge-settle --after-pr PR_NUMBER`; it stops at READY/NOOP and blocks repeated generated/admin refresh loops.\n\n`agentic-kit slice gate --kind planning-doc` emits `SLICE_GATE_RESULT` and `slice_result=PASS|BLOCKED`. helper-local PASS is not a slice PASS; `planning-doc` runs targeted tests plus `agentic-kit handoff check`, `agentic-kit check-docs`, `agentic-kit docs-audit`, and `agentic-kit doctor`. Dirty state reports `merge_pr_ready=NO`.\n\n`agentic-kit direction validate`, `agentic-kit direction render`, and `agentic-kit direction audit-drift` guard `docs/planning/PROJECT_DIRECTION.yaml`.\n`meta.updated_after_pr` is a strategic direction refresh marker, not a current-main freshness claim; validation requires `updated_after_pr_semantics` and keeps `updated_after_pr_current_main_claimed=false` when the marker is set.\nOpen Direction items whose `target_release` passed the current package version require revalidation.\n\nFor an existing Git repo, add `.agentic/` governance; use `agentic-kit init` only for new scaffolds.\n\n```\npython -m pip install \"agentic-project-kit @ git+https://github.com/vfi64/agentic-project-kit.git@main\"\nagentic-kit workspace dpa-intake --root PATH\nagentic-kit workspace adopt --root PATH\nagentic-kit dpa repo-adoption-assessment --root PATH\nagentic-kit workspace init --root PATH --execute [--inject-ci|--inject-pre-commit]\nagentic-kit workspace ci-update --root PATH [--execute]\nagentic-kit workspace remove --root PATH\nagentic-kit-gui --root PATH\n```\n\n`workspace dpa-intake` is the one-shot DPA intake orchestrator for takeover or\nnew-workspace planning. It resolves the target repo exact Git ref when possible,\nruns `workspace adopt`, runs the DPA repo-adoption assessment, groups surfaces\ninto an `adjudication_plan`, and can write bounded intake evidence with\n`--write-evidence --execute`. It remains read-only by default and keeps\n`external_repo_conformance_claimed=false`,\n`automatic_migration_performed=false`, and `production_mutation_performed=false`;\n`READY_FOR_DPA_INTAKE_ADJUDICATION` means the repo is ready for Maintainer\nadjudication, not automatically conformant.\n\n`workspace adopt` is read-only: it proposes `.agentic/config.yaml`, reports the private/public boundary, documentation age baseline, DPA repo-adoption assessment, and foreign `.agentic/` directory. `agentic-kit dpa repo-adoption-assessment --root PATH` inventories candidate surfaces, including top-level architecture/specification files and common specification directories such as `JSON/`, records source authority and target identity, classifies `specification_authority`, generated, or command-updated outputs, records DPA-600/DPA-700 evidence requirements, requires exact-ref evidence before adoption readiness, and keeps `external_repo_conformance_claimed=false`. `workspace init` is dry-run by default; `--execute` creates `.agentic/state/status.md`, `.agentic/state/handoff/`, `.agentic/DOC_LIFECYCLE.md`, `docs/archive/README.md`, transfer/CI/prompt files, and a `hygiene` manifest block with warn-mode doc lifecycle defaults. It appends `.agentic/tmp/` and `.agentic/rule_ack/`; versioned `.agentic/` must not hold secrets, chat fragments, logs, or local Rule-Ack runtime state. The managed CI template pins the installed `agentic-project-kit==<current version>`, runs `pull_request` plus `push` to `main`, uses workflow concurrency to avoid duplicate PR work, caches Playwright browsers, and can be refreshed with `agentic-kit workspace ci-update --root PATH --execute`; a customized template or workflow is never overwritten (` modified_managed_ci_template`, `modified_managed_ci_workflow`).\n\n`agentic-kit workspace upgrade --root PATH` is also a dry-run by default. It\nplans deterministic manifest schema migrations step by step, prints the\nmanifest diff, reports when a workspace is already at schema v2, and with\n`--execute` writes `.agentic/config.yaml.bak.v<N>` before each migration step.\nThe first real schema migration upgrades v1 manifests to v2 by materializing\n`hygiene`. Manifest-less repositories should run `workspace init`;\nnewer-schema repositories should upgrade the kit.\n\nAfter updating the Kit package in an already managed repository, run the bounded upgrade path from inside or against the target repository:\n\n```\npython -m pip install --upgrade \"agentic-project-kit @ git+https://github.com/vfi64/agentic-project-kit.git@main\"\nagentic-kit doctor --root PATH\nagentic-kit workspace upgrade --root PATH\nagentic-kit workspace upgrade --root PATH --execute\nagentic-kit check --root PATH\nagentic-kit doctor --root PATH\n```\n\n`doctor` reports an actionable warning when the workspace manifest schema is\nolder than the schema supported by the installed Kit.\n\nBrownfield path: `docs/guides/BROWNFIELD_EXTERNAL_REPO_15_MINUTES.md`.\n\n`agentic-kit workspace remove --root PATH` is the bounded rollback path for an\nunmodified Kit operating layer. It is dry-run by default. With `--execute` it\nremoves only exact Kit-generated `.agentic/` workspace files and managed injected\nCI/pre-commit files; generated successor handoff package files are recognized.\nRule: unknown or modified `.agentic/` paths block execution; project docs/source files are preserved.\n\nManifest-less repositories still use the implicit legacy profile for the 1.x\nline, but that fallback is deprecated. The resolver emits a suppressible\nlegacy profile deprecation warning for compatibility repositories that have Kit\ngovernance markers but no `.agentic/config.yaml`; empty non-workspaces and\nfresh generator-mode projects have explicit public CLI states instead. Set\n`AGENTIC_KIT_SUPPRESS_LEGACY_PROFILE_WARNING=1` for temporary quiet\ncompatibility while planning `workspace init`.\n\n`agentic-kit docs-registry` shows the read-only summary. Reviewed additions use\n`agentic-kit doc-registry register --path PATH --class CLASS --json`;\n`agentic-kit doc-registry check-unregistered --json` warns without broad\nmigration. `docs/DOC_REGISTRY_SCOPE.yaml` declares required files, required\npaths, and exemptions; `agentic-kit doc-registry check-unregistered --strict-scope`\nfails only on declared required scope violations.\n`agentic-kit doc-registry reconcile --execute` refreshes only the scope decision table; `doc-registry register` uses the same projection path so scope counters remain current or\nfails closed before writing a registry entry.\n\n`agentic-kit rule-registry check` validates the governed rule mechanism registry.\n`agentic-kit rule-registry report --json` summarizes direct coverage and follow-up\nstate. Reviewed additive rule entries use `agentic-kit rule-registry register`\nwith direct source and test evidence; it does not edit or deactivate existing\nrules and fails closed when the registry would no longer validate.\n\n`agentic-kit check-docs` includes deterministic document-quality heuristics for machine-checkable problems such as unresolved placeholder markers, stale handoff markers, missing required sections, missing coverage terms, and documentation drift.\n\nThese checks are intentionally limited. They are useful hard gates for known bad patterns, but they do not prove semantic perfection. A passing check does not prove that an architecture is globally optimal, a README is persuasive for every audience, or a handoff is sufficient for every future agent.\n\nFuture commands such as `review-docs` or `review-architecture` may provide advisory review for clarity, didactic quality, audience fit, missing rationale, overclaims, architecture drift, or review questions. Such advisory review must remain separate from `doctor` and must not be treated as merge authority.\n\n`agentic-project-kit` includes a small deterministic validation path for generated governance artifacts.\n\nThe current workflow is intentionally narrow:\n\n```\nagentic-kit validate-sections output.md -s \"Plan\" -s \"Solution\" -s \"Check\" -s \"Final Answer\"\nagentic-kit validate-contract --root .\nagentic-kit validate-output-contract output.md --contract docs/output-contracts/default-answer.yaml\nagentic-kit validate-output-contract output.md --contract docs/output-contracts/default-answer.yaml --report validation-report.json\nagentic-kit validate-output-contract output.md --contract docs/output-contracts/default-answer.yaml --repair-output output.repaired.md --repair-report repair-report.json\n```\n\nThe optional `--report` flag writes machine-readable validation evidence as JSON with `ok`, `contract`, `contract_version`, `checked_file`, and `findings`.\n\nValidation report schema:\n\n```\n{\n  \"ok\": false,\n  \"contract\": \"default-answer\",\n  \"contract_version\": 1,\n  \"checked_file\": \"output.md\",\n  \"findings\": [\n    {\n      \"severity\": \"error\",\n      \"code\": \"missing_required_section\",\n      \"message\": \"Missing required section: Solution\"\n    }\n  ]\n}\n```\n\nThe report schema is intentionally small and structural. `findings` entries use stable string fields so CI, wrappers, and review scripts can consume them without parsing human console output.\n\nWhat these commands do:\n\n- `validate-sections` checks literal required section markers in a text file.\n- `validate-contract` checks the machine-readable`.agentic/project.yaml` project contract.\n- `validate-output-contract` loads a machine-readable output-contract YAML file and validates an output text file using the same required-section semantics.\n- `validate-output-contract --repair-output ... --repair-report ...` can write a deterministic structural repair for missing required sections and a machine-readable repair report. The repair inserts missing section markers with explicit TODO text only; it does not invent semantic content.\n\nBoundary: these checks do not repair content, infer missing facts, or prove semantic correctness. They are deterministic structural gates for known contract requirements.\n\nGenerated `governance-wrapper` projects include a sample output contract at:\n\n```\ndocs/output-contracts/default-answer.yaml\n```\n\nUse `agentic-kit release-plan` before preparing a release:\n\n```\nagentic-kit release-plan --version 0.3.4\n```\n\nUse `agentic-kit release-check` before tagging:\n\n```\nagentic-kit release-check --version 0.3.4\n```\n\nThese commands help prevent release-state drift between `pyproject.toml`, `CHANGELOG.md`, project state files, local tags, remote tags, GitHub releases, and citation metadata.\n\nIn an external workspace (a workspace manifest and no Kit package) `release-check`, `release-plan` and the release commit integrity check of `release-publish` use the workspace's own version anchors: `pyproject.toml`, a literal package `__version__` where the package declares one, `CHANGELOG.md` when present, `CITATION.cff` when present or required by a Zenodo publication policy, and `docs/STATUS.md` or `docs/handoff/CURRENT_HANDOFF.md` only when they carry a current-version line. A workspace can also declare additional anchors under `release.version_anchors`: `source_constant` updates a named constant such as `APP_VERSION`, and `json_table` updates or prepends a version-table row such as `docs/releases/versions.json`. The Kit's own files (` src/agentic_project_kit/__init__.py`, the README version marker) are anchors only in the Kit's self-hosting layout. `release-prep` updates exactly these external anchors (a new `## vX.Y.Z - date` CHANGELOG section, also for a first release after an Unreleased section); `release-status` takes the package version from them and, without a Zenodo publication policy, ends the lifecycle with the tag and skips remote lookups; the release-oriented standard-error scan skips the Kit's self-hosting checks (its own release tests, DOI/handoff currency audit and planning-document consolidation) in an external workspace.\n\nThis post-release command is separate from release-check: release-check is a pre-release gate, while post-release-check verifies the already-published release and its Zenodo archive state.\n\nUse `agentic-kit post-release-check` after publishing a GitHub release:\n\n```\nagentic-kit post-release-check --version 0.3.4\n```\n\nThis command checks that the GitHub release exists and then looks for a verified Zenodo version record derived from the DOI in `CITATION.cff`. If Zenodo has not archived the release yet, the command reports `WAITING` and leaves README/CITATION DOI metadata unchanged. It is intentionally separate from `release-check`, because `release-check` is a pre-release gate that expects the tag and GitHub release to be unused.\n\nExternal workspaces can set `publication: none` in `.agentic/config.yaml` when a repository must never publish a GitHub Release, PyPI package, or Zenodo archive. Under that policy, `release-publish --dry-run` still checks release preparation and metadata authority, prints an `approval_signature` over the version, tag, target commit, publication policy, and planned actions, then plans a private annotated tag and `git push origin <tag>` only. Live execution requires `--allow-execute` plus either the optional repository marker `.agentic/release/ENABLE_LIVE_PUBLISH` or the matching `--expected-signature`; it creates or reuses the annotated tag and pushes that tag, without GitHub Release, PyPI, Zenodo, post-release-check, or Zenodo queries. `post-release-check`, `post-release-doi-closeout`, and CHANGELOG quality checks also skip GitHub/PyPI/Zenodo publication requirements. The default policy remains `github+pypi+zenodo` for release-managed Kit-style projects. Other supported manifest values are `github` and `github+pypi`.\n\nIn an external workspace `release ready` regenerates the LLM-context carriers with `transfer refresh-llm-context-carriers` right after its sync-main step, because sync-main normalizes the session and removes those carriers from the excluded runtime paths. `release ready` also generates release summary lines and runs `release-prep --dry-run` so the planned CHANGELOG section is quality-checked before a release PR. The release-oriented standard-error scan writes the release summary lines into the workspace temp root (`.agentic/tmp` in an external workspace). Under `publication: none` the release-notes generator lists unclassified release-note items under Changed with a warning instead of blocking (private fallback), and `release prepare --write` records the docs-pages fallback refresh as skipped when an external workspace has no `site/scripts/build.py`. For Kit self-hosting releases, `post-release-doi-closeout --write` regenerates the committed docs-pages fallback (`docs/index.html`, `docs/.nojekyll`, and `docs/site/`) after DOI metadata changes so CI sees fresh website projections.\n\n`agentic-kit release run --version X` is the resumable end-to-end release route. It composes existing release commands, stores state/logs under the workspace temp root, and stops at signed approval gates before `work finish --execute`, signed `release-publish --execute`, package-index workflow dispatch, and DOI closeout `work finish --execute`. With `publication: none`, it skips package-index publication, Zenodo wait, and DOI phase.\n\n`agentic-kit ci status --commit SHA --branch BRANCH --json` is the read-only CI verdict command for commits or branches without a pull request. It reports `PASS`, `PENDING`, or `BLOCKED` as structured JSON; red CI remains a finding.\n\nFor external manifest workspaces, `agentic-kit release ready` keeps Kit self-hosting documentation audits out of the release scan. If the manifest sets `doc_lifecycle: warn`, lifecycle findings stay visible as warnings rather than release blockers; `doc_lifecycle: strict` keeps blocking behavior.\n\nGenerated projects contain a machine-readable TODO file and a rendered Markdown view.\n\n```\nagentic-kit todo list\nagentic-kit todo complete BOOT-001 --evidence \"LICENSE reviewed\"\nagentic-kit todo render\nagentic-kit check-todo\n```\n\nThe intended pattern is simple: bootstrap tasks are explicit, evidence is recorded, and the human-readable TODO file is regenerated from the YAML source.\n\nFor local LLM handoff, prefer the package CLI:\n\n```\nagentic-kit workflow status\nagentic-kit workflow status --explain\nagentic-kit workflow request\nagentic-kit workflow run\nagentic-kit workflow cleanup\nagentic-kit workflow fail-report\n```\n\nUse `workflow status --explain` when you are unsure what to do next. It is read-only and explains the current state before recommending a safe command. This guided path is intentionally conservative: dirty working trees and failed workflow states point to evidence upload or inspection first instead of hidden state changes.\n\nQuick command guide:\n\n- `agentic-kit audit-command-authority` : verify that agent-facing chat/handoff entrypoints carry the current command manifest ACK,`command-for` guidance to choose the most specific available Kit workflow command, and the no-memory-reconstruction contract.\n- `agentic-kit instruction lint --file PATH` or`--stdin` : lint LLM instruction text against the current command manifest before applying transfer orders.\n- `agentic-kit chat refresher --mode copy-paste` : print the six-line command-manifest refresher for chat replies that may include commands.\n- `agentic-kit chat session-start --mode copy-paste` : print the refresher plus the full inline command manifest for a new session.\n- `agentic-kit commands sync-entrypoints --execute` : synchronize command reference files and command-manifest entrypoint headers.\n\nCommand manifest surface classes are role metadata, not stability metadata. `orchestrator` marks primary task/lifecycle operations, `diagnostic` marks inspection and readiness operations, and `primitive` marks public low-level command building blocks. Surface classification is intent-oriented: read-only session start or dry-run maintenance workflows may be primary, while highly parameterized evidence/log/file helpers may remain low-level even when implemented as mini-workflows. `agentic-kit command-for` uses the same surface classes as a tie-breaker after semantic task matching and safety checks: equally suitable task matches prefer orchestrator, diagnostic task tags may prefer diagnostic, and exact primitive matches are not displaced by broader orchestrators. GUI and website projections must consume this same generated `surface` field: Primary (`orchestrator`), Diagnostics (` diagnostic`), and Expert / Low-level (` primitive`).\nSurface classification does not by itself change command safety, compatibility, or deprecation status; primitive does not mean unstable. GUI and website projections may add presentation-only guidance: `diagnostic_priority`, `safety_review`, and `claim_evidence` mark common blockers, manual-review items, and claims needing evidence.\n\nThe generated Understand the Kit page explains audience, architecture, local controllers and bounded practice evidence. External tool comparisons are dated, sourced editorial snapshots; current Kit facts derive from repository sources.\n\n`site/scripts/build.py` uses `agentic_project_kit.site_generator` for ignored\n`site/dist/`: package version, Python requirement, command\ncount, `meta.manifest_sha`, `manifest_sha(commands)`, and build commit. The\nsite is not a second hand-maintained technical truth surface.\n\nPages: [https://vfi64.github.io/agentic-project-kit/](https://vfi64.github.io/agentic-project-kit/). Workflow\nchooser: [https://vfi64.github.io/agentic-project-kit/workflows/](https://vfi64.github.io/agentic-project-kit/workflows/)\n(`workflows/index.html`, `workflows/workflows.json`). `Choose How You Want To Work`:\nFile Transfer, Copy and Paste, Agent Direct, and\nexperimental early GUI surface. Brownfield evidence:\n`docs/reports/POST_V1_0_5_B1_EVIDENCE_CLOSEOUT_20260826.json`; Cycle 007\nreport; `B1_EVALUABLE`; general Brownfield portability is not claimed.\n\nlegacy `main` `/docs`: `python site/scripts/build.py --docs-pages-fallback --json`\nwrites `docs/index.html`, `docs/.nojekyll`, and `docs/site/`; `site/dist/`\nstays ignored. `site/` and `/docs` Pages fallback files are excluded from Python sdist and wheel artifacts.\n\n- `agentic-kit workspace dpa-intake` : run deterministic DPA intake by resolving exact-ref evidence, adoption analysis, repo-adoption assessment, adjudication plan, and optional bounded evidence without migration or external-repo conformance claims.\n- `agentic-kit workspace remove` : plan or execute bounded removal of exact Kit-generated workspace files while preserving modified, unknown, source, and project-documentation paths.\n- `agentic-kit dpa readiness` : validate the staged DPA DP1 Assessment readiness record, report the deterministic DP2 selected self-hosting target-scope implementation percentage, and keep that separate from Kit-wide DPA conformance.\n- `agentic-kit dpa repo-adoption-assessment` : assess a foreign or new repository without mutation; record inventory, source authority, target identity, DPA-600/DPA-700 evidence, exact-ref readiness, and no external conformance claim.\n- `agentic-kit dpa post-dp2-scope-assessment` : inventory post-DP2 rollout, status-authority, and strict lifecycle-gate blockers without claiming Kit-wide DPA completion.\n- `agentic-kit dpa dp3-dp4-adjudication-check` : validate the bounded DP3/DP4 adjudication record without authorizing DP5 strict lifecycle gates.\n- `agentic-kit dpa dp5-stage-check` : validate the bounded DP5 stage record; the current default is strict for the accepted post-DP2 DP3/DP4 scope.\n- `agentic-kit dpa dp5-block-new-gate` : fail when current DPA scope nonconformance introduces items outside the accepted warn-stage baseline.\n- `agentic-kit dpa dp5-strict-gate` : fail when any configured noncompliance remains in the accepted DPA scope before final closeout.\n- `agentic-kit dpa final-closeout-check` : validate the final DP1-DP5 closeout record that owns the bounded Kit-wide DPA conformance claim.\n- `agentic-kit dpa stable-readiness-check` : validate Stable-DPA readiness and the bounded Stable Promotion record; foreign repositories still require fresh per-repo inventory, DPA-600/DPA-700 evidence and Maintainer-authorized scope.\n- `agentic-kit dpa dp2-decision-readiness` : prepare the DP2 decision package without recording Maintainer Assessment or authorization.\n- `agentic-kit dpa maintainer-record-check` : validate a DP2 Maintainer Assessment record or blocked template without authorizing DP2.\n- `agentic-kit dpa probe-002-readiness` : inspect PROBE-002 lifecycle and selected-writer readiness, optionally writing bounded DPA probe evidence under`docs/architecture/evidence/dpa/probes/` .\n- `agentic-kit dpa probe-003-readiness` : inspect PROBE-003 workflow serialization readiness, optionally writing bounded DPA probe evidence without workflow mutation.\n- `agentic-kit dpa renderer-readiness` : inspect Renderer Probe readiness, optionally writing bounded DPA probe evidence without renderer conformance claims.\n- `agentic-kit dpa probe-004-readiness` : inspect PROBE-004 migration and rollback readiness, optionally writing bounded DPA probe evidence without migration or rollback execution.\n- `agentic-kit dpa wrt-ch001-evidence` : observe a WRT-CH-001 administrative handoff refresh PR without claiming disposable fixture PASS.\n- `agentic-kit work start --from-ref REF` : create a fresh work branch based on a selected release tag, branch, or remote-tracking integration ref; non-main refs do not run the post-merge check as a pre-PR gate.\n- `agentic-kit work discard-changes` : preview the explicitly destructive feature-branch discard flow;`--execute` requires a deliberate confirmation path.\n- `agentic-kit transfer list-refs --json` : list local release tags and branches for the guided work-start picker.\n- `workflow status --explain` : inspect the current state and next safe step.\n- `workflow request` : mark a concrete local workflow slice as requested.\n- `workflow run` : run one bounded workflow state-machine step.\n- `workflow cleanup` : clean uploaded temporary evidence after review.\n- `workflow fail-report` : upload preserved FAILED-state evidence for diagnosis without cleanup or retry.\n\nLegacy compatibility remains available through:\n\n```\nagentic-kit workflow request\nagentic-kit workflow\n```\n\nPrefer the package CLI for normal use; the legacy command is kept visible for compatibility and documentation coverage.\n\nThe legacy cycle uses `IDLE`, `TEST`, `UPLOAD`, and `CLEANUP`. Details are documented in `docs/WORKFLOW_OUTPUT_CYCLE.md`.\n\nUse `agentic-kit workflow-guard check` before mutation-oriented workflow repair or protected control-file changes. The workflow guard diagnoses recurring workflow failures such as governance YAML parse errors, missing protected anchors, weakened no-hard-length-limit preservation policy, and missing workflow guard policy documentation.\n\nThe guard is conservative by design: it diagnoses first and requires a repair plan for semantic rule loss, release-state conflict, broad document rewrites, and unclear YAML recovery. It is a workflow guard, not an autonomous semantic fixer.\n\nThe Pattern Advisor MVP is a local, read-only catalog for recurring project patterns and anti-patterns. It is advisory-only: no gates, no automatic architecture choice, no workflow-state mutation, and no candidate promotion.\n\n```\nagentic-kit patterns list\nagentic-kit patterns show bounded-workflow-evidence\n```\n\nExternal workspace rule inventory: `agentic-kit rule-registry bootstrap --json`\nplans a deterministic, evidence-derived Kit mechanism projection. Execute only\nwith its `approval_signature`; missing inventories report NOT_APPLICABLE with\nthe exact route. This does not register project rules or claim local test coverage.\nSee [external inventory repair and retest](https://github.com/vfi64/agentic-project-kit/blob/main/docs/reports/greenfield/KIT-GF-RULE-REGISTRY-BOOTSTRAP-external-inventory-2026-10-13.md).\n\nThe local cockpit foundation exposes a conservative control surface for local project operation. Use `agentic-kit cockpit`, `agentic-kit actions`, `agentic-kit cockpit status`, `agentic-kit cockpit actions`, and `agentic-kit cockpit run <action-id>` to inspect state, read the structured action inventory, and execute registered read-only actions. For `agentic-kit` actions, inventory output includes `manifest_surface` and `gui_layer` from the command manifest: Primary layer, Diagnostics layer, and Expert / Low-level layer. It also includes `gui_diagnostic_priority`, `claim_evidence`, and `safety_review` so GUI and website views can show Guided Diagnostics common blockers before specialized audits and avoid prose-only readiness or release claims.\n\nThe action inventory classifies by category, safety, and Access level. Access level is a Tkinter cockpit visibility convenience, not permission. Execution allows `read_only` by default, blocks `bounded` without an allow path, and blocks general `destructive` actions. The experimental `agentic-kit-gui` entry point starts a local Tkinter cockpit skeleton and may guide `agentic-kit release ready` before confirmed `agentic-kit release prepare`; its release controls must not publish releases, push tags, or run remote cleanup. The work-cycle controls invoke the existing Kit finish workflow only after a passing preview and explicit publish confirmation; that workflow can commit, create a PR and merge through the configured guards. The GUI button catalog is a Bedienprojektion, not a second taxonomy: `agentic-kit` wrappers must resolve to generated command-reference entries with valid `surface`, and stale wrappers fail tests. The bounded Upload Result Log button uses `agentic-kit work-order upload`.\n\nThe **optional Guided GUI** starts with `agentic-kit-gui-guided --root PATH`. It arranges the existing Kit controls into Standard tasks, Work, Kit tools and System tabs, with a persistent activity pane and background execution feedback. The original GUI remains available; both share the guarded Kit actions. See [Guided GUI usage and boundaries](https://github.com/vfi64/agentic-project-kit/blob/main/docs/reference/GUIDED_GUI.md). This alternative remains experimental pending operational and platform acceptance.\n\nThe historical foundation is documented in `docs/archive/LOCAL_COCKPIT_FOUNDATION.md`; the current frontend decision is in `docs/architecture/ADR_GUIDED_GUI_FRONTEND.md`.\n\n`agentic-kit executor plan INTENT` and `agentic-kit executor run INTENT` expose the governed Planner-Kit-Executor surface. The intent may name `hermes` as the first executor adapter, but every runnable step must still resolve through the generated command manifest or the cockpit/action registry. This keeps Kit authority in one place instead of creating a parallel planner or workflow taxonomy.\n\n`agentic-kit executor run` is dry-run by default. Read-only manifest and cockpit steps may run with `--execute`; bounded cockpit actions also require step-level `allow_bounded: true` and CLI `--allow-bounded`; destructive actions remain blocked. The contract, failure states, and evidence rules are documented in `docs/architecture/PLANNER_KIT_EXECUTOR_CONTRACT.md`.\n\nThe root CLI module is intentionally a thin root command registry. Command implementations live under `src/agentic_project_kit/cli_commands/`.\n\n```\nsrc/agentic_project_kit/\n  cli.py\n  cli_commands/\n    checks.py\n    github.py\n    init.py\n    profiles.py\n    release.py\n    todo.py\n    validation.py\n    workflow.py\n```\n\nBoundary tests keep `cli.py` from regrowing into a monolith.\n\nCreate a GitHub repository from inside a generated project:\n\n```\nagentic-kit github-create --owner YOUR_GITHUB_NAME --visibility private\n```\n\nThis command uses the official GitHub CLI `gh`. It does not ask for or store GitHub tokens.\n\nThe generated CI workflow runs the basic project gate once per pull-request commit and once per `main` push. It pins the Kit package version and caches Playwright browsers. The generated pull request template asks for intended outcome, required evidence, tests, and remaining risks.\n\nGenerated projects separate:\n\n- stable rules from volatile status\n- current handoff from historical notes\n- output from outcome\n- logs from committed source state\n- agent instructions from project overview\n- project profiles from policy packs\n\nAgents should start with `AGENTS.md`, `.agentic/project.yaml`, `docs/PROJECT_START.md`, `docs/STATUS.md`, and `docs/TEST_GATES.md`. They should not infer current state from memory or stale prose.\n\n`docs/DOCUMENTATION_COVERAGE.yaml` is the machine-checkable documentation coverage matrix.\n\n`agentic-kit check-docs` validates that important commands, workflows, governance concepts, safety rules, release commands, and evidence expectations remain visible.\n\nWhen adding a public command, workflow, gate, profile, policy pack, generated file, architecture concept, or release-visible feature, update the coverage matrix and the affected documentation in the same change.\n\n`agentic-kit doc-mesh-audit` checks machine-readable drift across the project documentation mesh. It is bounded and does not claim semantic proof.\n\nThe first audit slice distinguishes four document classes:\n\n- current-state documents, such as README, CITATION, pyproject, package `__version__` , STATUS, and CURRENT_HANDOFF;\n- release-history documents, currently CHANGELOG.md, which remain required and may feed release DOI synchronization without being treated as live project state;\n- governance documents, such as AGENTS, TEST_GATES, DOCUMENTATION_COVERAGE, sentinel, and project contract files;\n- architecture/design documents, such as ARCHITECTURE_CONTRACT, WORKFLOW_OUTPUT_CYCLE, and optional DESIGN.md;\n- historical-plan documents, such as roadmap summaries, status reports, and v0.3.0 output-repair planning files.\n\nThe hard checks currently cover version mismatches, stale current-state wording, missing historical-source-of-truth banners, and release DOI list mismatches.\n\n`agentic-kit doc-mesh-audit --report doc-mesh-report.json` writes a machine-readable JSON report for CI, review tools, or later workflow evidence.\n\n`agentic-kit doc-mesh-audit --repair-plan doc-mesh-repair-plan.json` writes a bounded repair plan. `agentic-kit doc-mesh-repair` currently applies only one safe automatic repair class: inserting missing historical-source-of-truth banners into known historical-plan documents. Version, DOI, stale-state, and missing-document findings remain manual review items.\n\nFuture repair tools should stay bounded to mechanical edits and must not rewrite semantics.\n\n`agentic-kit doc-lifecycle-audit --json`; `agentic-kit doc-lifecycle-audit --strict`; `agentic-kit doc-lifecycle-audit --suggest-review-after`; `agentic-kit audit-doc-orphans`; `agentic-kit docs lifecycle sweep --dry-run`; `agentic-kit docs lifecycle bootstrap --dry-run`; `agentic-kit docs lifecycle propose-delete`. Lifecycle metadata such as `Status`, `Decision status`, and `Review policy` is recognized only in the document head before the first `##` section, so prose examples later in the file do not satisfy the gate.\n\n`agentic-kit audit-status-current-state` checks that `docs/STATUS.md` Current verified main, the handoff validation report, `release-status`, `origin/main`, and the `CHANGELOG.md` release block agree. It allows bounded admin-refresh lag, but blocks stale current-state claims: a pending DOI line after STATUS records a verified DOI for the same version, stale concrete administrative refresh-only descendant markers, and active Current governed slice / Next safe step instructions that still tell maintainers to publish, prepare, or verify an already verified current release.\n\n`agentic-kit audit-path-literals` is report-only. `agentic-kit audit-path-literals --enforce-active`\nruns in the standard gate suite and blocks active path/repository identity\nliterals outside resolver exceptions. Evidence:\n`docs/architecture/evidence/path-literal-audit-2026-07-04.md`.\n\n`agentic-kit audit-mutation-lock-coverage` runs in the standard gate suite. It\nblocks unlocked core runtime git or GitHub mutators; others stay\nnon-blocking review data. Evidence:\n`docs/architecture/evidence/mutation-lock-coverage-2026-07-11-post-lc3.md`.\n\nUse `agentic-kit docs-audit` as the umbrella documentation-system audit command. It reports Aktualität, Vollständigkeit, Korrektheit, Redundanzfreiheit, Stringenz der Dokumentenordnung, and Konsistenz in one ordered result.\n\nThe command aggregates deterministic findings from `agentic-kit check-docs`, `agentic-kit doc-mesh-audit`, and `agentic-kit doc-lifecycle-audit`. It also marks full semantic redundancy review as review-only instead of pretending to prove what deterministic gates cannot prove.\n\n```\nagentic-kit docs-audit\nagentic-kit docs-audit --report docs-audit.json\nagentic-kit docs-audit --json\n```\n\nIn external manifest workspaces, the audit checks declared documents, workspace\nversion anchors and registered facts. It does not require the Kit's own document\nset. `hygiene.doc_lifecycle: warn` reports lifecycle warnings without blocking;\n`strict` and explicit `doc-lifecycle-audit --strict` retain blockers.\n\nThe generated `scripts/stage_recent_logs.py` script is intentionally bounded. It stages only a recent diagnostic window from known log folders into `tmp/agent-evidence`.\n\nLogs are diagnostic evidence, not automatic source material. Do not commit secrets, local credentials, broad raw logs, or private runtime state.\n\nCitation metadata is provided in `CITATION.cff`; Zenodo metadata is provided in `.zenodo.json`.\n\nFor citation across versions, prefer the all-versions DOI: `10.5281/zenodo.20101359`.\n\nHistorical verified version-specific DOI notes are maintained in `docs/releases/VERIFIED_RELEASES.md`.\n\nUse the `governance-wrapper` profile for strict human-AI wrapper projects that need explicit output contracts, validation, bounded repair, and auditability.\n\n```\nagentic-kit init demo-governance \\\n  --type governance-wrapper \\\n  --description \"Governance wrapper demo\" \\\n  --github-actions \\\n  --agent-docs \\\n  --logging-evidence\n```\n\nThis profile is intended for projects where generated answers or tool outputs must be checked against explicit contracts before they are accepted. The related `output-contracts` policy pack emphasizes schemas, validators, repair boundaries, and evidence-oriented failure handling.\n\nTo inspect available profiles and policy packs, run:\n\n```\nagentic-kit profile-explain\n```\n\nDo not generate a public project from a private repository history.\n\nThis kit creates a fresh repository from generic templates. It does not copy a private `.git` history.\n\n`agentic-project-kit` is a generic open repository governance and agentic-development kit. It is not tied to a specific private legacy refactoring project, and examples should stay generic unless they describe generated files or this repository itself.\n\nSuggested GitHub description:\n\n```\nReproducible AI-assisted repository work through project contracts, documentation gates, release checks, task gates, and policy packs.\n```\n\nSuggested topics:\n\n```\nagentic-development\nai-agents\ndeveloper-tools\ngithub\nproject-template\nsoftware-engineering\ndocumentation\nrelease-management\npython\ncli\n```\n\nThese repository settings are maintainer-owned and are not changed by the package.\n\nPrepared release: `v1.1.6`; GitHub Release, tag publication, PyPI publication, and Zenodo version DOI verification are complete.\nVersion `1.1.6` is the current release line prepared as a safety baseline after the pre-GUI transfer-wrapper, output-discipline, GUI wrapper-gating, PR diagnostics, and release-plan guard hardening work.\nCurrent verified release: `v1.1.6` with Zenodo version DOI `10.5281/zenodo.23651539`.\nEarlier verified version-specific DOI notes are maintained in `docs/releases/VERIFIED_RELEASES.md`; historical release records remain in this section and the verified release archive.\n\nArchived GUI/cockpit release notes: v0.3.22 verified DOI `10.5281/zenodo.20256637`; v0.3.19 verified DOI `10.5281/zenodo.20246121`.\n\nArchived release v0.3.10 covers workflow shortcut commands, bounded workflow-output upload, aligned shortcut guidance, and the contract-only Pattern Advisor MVP report with DOI `10.5281/zenodo.20214382`. Compatibility coverage anchor: Version `0.3.10`.\n\nArchived release v0.3.9 remains the previous post-release verified archived release before v0.3.10. Compatibility coverage anchor: Version `0.3.9`.\n\nVerified version-specific DOI history is maintained in `docs/releases/VERIFIED_RELEASES.md`.\n\n- `agentic-kit workflow go`\n- `agentic-kit workflow upload-output`\n- `agentic-kit workflow state`\n- `agentic-kit workflow list`\n- `agentic-kit workflow show`\n- `agentic-kit workflow upload`\n- `.agentic/workflow_state` Supported cockpit status check:`agentic-kit cockpit status` .", "url": "https://wpnews.pro/news/agentic-project-kit-a-control-harness-for-llm-assisted-coding-via-repo-state", "canonical_source": "https://github.com/vfi64/agentic-project-kit", "published_at": "2026-10-26 10:48:11+00:00", "updated_at": "2026-10-26 11:14:25.494996+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-safety"], "entities": ["agentic-project-kit", "PyPI", "GitHub Actions", "GitHub Copilot", "agentic-kit"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/agentic-project-kit-a-control-harness-for-llm-assisted-coding-via-repo-state", "markdown": "https://wpnews.pro/news/agentic-project-kit-a-control-harness-for-llm-assisted-coding-via-repo-state.md", "text": "https://wpnews.pro/news/agentic-project-kit-a-control-harness-for-llm-assisted-coding-via-repo-state.txt", "jsonld": "https://wpnews.pro/news/agentic-project-kit-a-control-harness-for-llm-assisted-coding-via-repo-state.jsonld"}}