{"slug": "show-hn-arka-norn-local-governance-and-delivery-for-coding-agents", "title": "Show HN: Arka.norn – Local governance and delivery for coding agents", "summary": "Arka.norn released version 2.3.6, a local-first delivery framework for coding agents that provides a durable recovery source through published, fingerprinted plan revisions. The framework, built on Node.js 22.13+, enables agents to frame projects and features from provider chats and continue across Web, TUI, and CLI, with human stabilizations required before publication. Version 2.3.6 adds a post-install welcome and grouped interactive menu, while legacy 2.2 campaigns remain inspection-only.", "body_md": "arka.norn is a local-first delivery framework for Projects, Features, attributed documents, human decisions, evidence, and auditable workflows.\n\nIt gives teams one durable recovery source: the published plan.\n\nFrom a provider chat, an Agent can frame a Project or a Feature, connect that work to arka.norn, and continue across Web, TUI, and CLI without turning a SaaS workspace into the source of truth.\n\n`arka-norn`\n\nis the command.\n\nVersion 2.3.6 adds a post-install welcome and a grouped interactive menu, on top of the 2.3.5 branded setup and 'arka-norn version' update check. It builds on 2.3 orchestration control in Norn Web: preview a run, authorize it against the exact plan fingerprint, and apply a verified candidate under the 2.3 invariants, alongside Doctor inspect, preview, and repair, over the 2.3 live framing engine that frames a Project into Feature candidates or a Feature into bounded Lots and hands one exact published revision to the 2.3 delivery DAG.\n\nLegacy 2.2 campaigns are inspection-only. Existing v4 Features keep their historical workflows. English remains canonical for contracts and machine data.\n\n- Start from a provider chat instead of a blank internal workflow\n- Recover from the published plan, not from chat history\n- Keep the human as the authority on scope, policy, and release\n- Operate locally across Web, TUI, and CLI\n- Produce attributed, integrity-verified, auditable, reproducible delivery artifacts\n\n- Node.js 22.13 or newer\n- npm\n- A local repository to manage\n- A registered and authenticated execution profile when automatic Agent execution is needed\n- Docker or Podman with the Project’s pinned recipe image already present for automatic tests and builds\n\nSupported execution transports for automatic runs:\n\n- Codex CLI\n- Claude CLI\n- Explicitly diagnosed API / Gemini profiles\n\n```\nnpm install\nnpm run build\nnode bin/arka-norn.mjs --version\nnode bin/arka-norn.mjs doctor\n```\n\nOpen the cockpit:\n\n```\nnode bin/arka-norn.mjs\n```\n\narka.norn does not replace the provider experience. It connects the Agent’s work to a durable local framework.\n\nA typical flow is:\n\n- You ask for work in a provider chat\n- The Agent frames the task and links it to arka.norn\n- arka.norn publishes an immutable, fingerprinted plan revision\n- The same state becomes available in Web, TUI, and CLI\n\nThe plan is the recovery source. If the provider session changes, the Project state remains available through published local artifacts.\n\nLive framing lets a connected Agent create a bounded, resumable plan before delivery.\n\n```\narka-norn framing enter .\narka-norn framing enter . --new-feature \"The outcome to deliver\"\narka-norn framing show --view plan\narka-norn framing show --view evidence\narka-norn framing show --view map\narka-norn framing resume\n```\n\nThe connected Agent updates the plan through bounded local deltas while the public CLI and Web interface expose human projections.\n\nThe plan, not the chat, is the recovery source.\n\nWork in progress remains under `$ARKA_NORN_HOME/framing`\n\n. Only a twice-stabilized, fingerprinted revision is published under the Project’s `.arka-norn/plans`\n\ndirectory.\n\nThere are exactly two human stabilizations:\n\n-\n**Repository grounding** Authorizes grounding against the actual repository. -\n**Publication and route binding** Binds publication, decomposition, and the calculated delivery route.\n\nBefore the first stabilization, Norn probes the repository and adapts how it discovers the ground truth. It never runs a blind audit on an empty folder, and it never invents facts about code it has not read.\n\n**Empty**— no audit and no code reader. Norn moves straight to explicitly greenfield technical design.** Skeleton**— reads only manifests and declared constraints.** Implemented**— performs a first intent-blind reading of the structure and public surfaces, then confronts those findings with the Product intent.**Indeterminate**— reduces its authority and avoids broad positive or negative claims.\n\nPositive facts require the current snapshot and a `file:line`\n\nanchor; absence claims require an inventory attestation.\n\n**Project plans** produce Feature candidates without creating them in bulk**Feature plans** produce bounded Lots with scopes, dependencies, and proofs- A directly framed new Feature is materialized only after publication\n\nOpen Project tracking in the browser:\n\n```\nnode bin/arka-norn.mjs web start\nnode bin/arka-norn.mjs web status\nnode bin/arka-norn.mjs web restart\nnode bin/arka-norn.mjs web stop\n```\n\n`web`\n\nwithout an action is an alias for `web start`\n\n.\n\nThe managed server runs in the background, survives the launching terminal, and opens the secured browser session by default.\n\nUseful options:\n\n`--port 4317`\n\n`--no-open`\n\n`--json`\n\n`web restart`\n\npreserves the current port and browser session. `web stop`\n\nfollowed by `web start`\n\ncreates a new secure session. Use `web foreground`\n\nonly when the server must remain attached to the current terminal.\n\nFrom a source checkout, the equivalent shortcuts are:\n\n`npm run web:start`\n\n`npm run web:status`\n\n`npm run web:restart`\n\n`npm run web:stop`\n\nThe Web interface presents:\n\n- Project health\n- Active framing\n- Feature paths\n- Attributed documents\n- Decisions\n- Audits\n- Registered Agents\n- Live Norn orchestration state\n\nA Project prioritizes its current framing card. Plan, Evidence, Map, and History remain available after a provider or session change.\n\nStarting a new Feature asks only for its expected outcome.\n\nThe CLI owns profile registration, preview, run authorization, recovery, and application. The TUI cannot relaunch quarantined 2.2 campaigns.\n\nProject entry and Feature framing are guided for non-developers. Generated identifiers, folder choices, workflows, and advanced technical values stay out of the primary framing flow.\n\nAutomatic mode builds a confirmed, fingerprinted task DAG.\n\nEvery task gets its own:\n\n- branch\n- private Git worktree\n- execution profile\n- read/write scopes\n- mechanical proof\n\nDependency-ready tasks with disjoint write scopes can run in parallel. Overlapping scopes are serialized before authorization.\n\nDirect automatic execution no longer exists.\n\nThe human selects one provider/model profile per role and confirms:\n\n- the plan\n- the risk policy\n- the commit authority\n- the application policy\n- the budget\n- the parallelism\n\nAgents have no native shell, Git, commit, network, or sub-agent authority.\n\nAll reads, proposed changes, Docker or Podman recipes, evidence, and decisions pass through the bounded Norn broker. Norn validates the result and creates the commit.\n\nChoose the preferred tracking surface in Norn Web settings:\n\n**Web**: functional explanations and a live read-only timeline, with no command blocks** TUI**: manual workflow and Agent identity management, with an explicit handoff to the 2.3 CLI for automatic runs** CLI**: exact commands and stable JSON for expert automation\n\nSee [Automatic orchestration](https://github.com/arka-squad/arka-norn/blob/main/docs/automatic-orchestration.md) for workspace, budget, recovery, and application guarantees.\n\nInstall the generated Agent skills:\n\n```\nnode bin/arka-norn.mjs install --global\nnode bin/arka-norn.mjs skills doctor\n```\n\nEnglish is canonical for:\n\n- code\n- commands\n- identifiers\n- JSON fields\n- schemas\n- public documentation\n\nDisplay text can be English or French.\n\n```\narka-norn locale show\narka-norn locale set en\narka-norn locale set fr\narka-norn locale set auto\narka-norn --locale fr workflow list\nARKA_NORN_LOCALE=en arka-norn doctor\n```\n\nResolution order is:\n\n`--locale`\n\n`ARKA_NORN_LOCALE`\n\n- saved preference\n- system locale\n- English\n\nPreferences are stored atomically in `$ARKA_NORN_HOME/.arka-norn/preferences.json`\n\nand never enter portable Project or Feature markers.\n\nMachine JSON always uses canonical English values. Only its `display`\n\nblock varies by locale.\n\n| Workflow | Use it for | Required path |\n|---|---|---|\n| Essential 2.3 | New grounded Features with bounded Lots | `development_report -> delivery_audit -> delivery_validation` |\n| Complete 2.3 | Grounded higher-risk Features whose downstream consumers require technical artifacts | Required technical contracts, delivery, audit, and validation |\n| Essential legacy | Existing well-understood v4 Features | `feature_brief -> development_report -> delivery_audit -> delivery_validation` |\n| Complete legacy | Existing v4 Features with the historical full document chain | Concept, plan, evidence, invariants, tasks, specification, delivery, and QA |\n| FastDev | Small, bounded corrections and refactors | `rework_brief -> development_report -> delivery_audit -> delivery_validation` |\n\n`technical_contract_appendix`\n\nis optional in Essential.\n\nDelivery audits can require a corrective `development_report`\n\n. Validation always targets the latest report.\n\n```\narka-norn workflow list\narka-norn workflow show essential\narka-norn essential start \"Filter Features by status\" --project product\narka-norn essential next <feature-id> --session <session-id> --json\n```\n\nDeprecated aliases `standard`\n\nand `essentiel`\n\nremain accepted with warnings throughout 2.x. Existing legacy Features continue on their French v3 contract until explicitly migrated.\n\nThe delivery chain remains attributed, integrity-verified, auditable, and machine-readable from framing to validation.\n\n```\ncd /workspace/product\narka-norn framing enter . --new-feature \"Filter Features by status\"\narka-norn framing resume\narka-norn framing show --view plan\n\n# After the connected Agent obtains the second stabilization and publishes:\narka-norn agent advise --project product --feature filter-features\narka-norn pipeline next filter-features --json\n```\n\nA v5 document uses English field names and declares the prose locale:\n\n```\n{\n  \"schema_version\": 5,\n  \"content_locale\": \"fr\",\n  \"id\": \"brief-filter-features-01\",\n  \"feature_id\": \"filter-features\",\n  \"type\": \"feature_brief\",\n  \"sequence\": 1,\n  \"created_at\": \"2026-08-23T09:00:00.000Z\",\n  \"depends_on_document_ids\": [],\n  \"author_agent_id\": \"Codex_product_20260823\"\n}\n```\n\nThe reader accepts legacy French v2/v3 Feature documents and Project audit v4 documents without rewriting them.\n\n```\narka-norn migrate --target /workspace/product/feature\narka-norn migrate --target /workspace/product/feature --apply\n```\n\nMigration validates the whole Feature first, creates backups, preserves identity and graph relations, translates fields and enums, records the source version and SHA-256, and commits the marker last.\n\nUnknown, mixed, or ambiguous contracts stop the entire operation.\n\nRepeating a successful migration is a no-op.\n\nFraming does not silently migrate existing Feature markers. Marker v4 remains on its historical pipeline. Marker v5 requires `pipelineDefinitionVersion: 2.3`\n\nand an exact `framingPlanRef`\n\n.\n\nSee [Migration to live framing](https://github.com/arka-squad/arka-norn/blob/main/docs/migration-2.3.2.md).\n\nPublic CLI JSON uses `schemaVersion: 2`\n\n:\n\n```\n{\n  \"schemaVersion\": 2,\n  \"command\": \"pipeline.status\",\n  \"ok\": true,\n  \"data\": {},\n  \"errors\": [],\n  \"warnings\": [],\n  \"diagnostics\": {\n    \"errors\": [],\n    \"warnings\": []\n  },\n  \"display\": {\n    \"locale\": \"en\",\n    \"errors\": [],\n    \"warnings\": []\n  }\n}\n```\n\nScripts must depend on:\n\n`data`\n\n- stable diagnostic codes\n- diagnostic parameters\n\nThey must never depend on localized `display`\n\nprose.\n\n[User guide](https://github.com/arka-squad/arka-norn/blob/main/docs/user-guide.md)[CLI reference](https://github.com/arka-squad/arka-norn/blob/main/docs/cli.md)[TUI guide](https://github.com/arka-squad/arka-norn/blob/main/docs/tui.md)[Project Web guide](https://github.com/arka-squad/arka-norn/blob/main/docs/web.md)[Essential workflow](https://github.com/arka-squad/arka-norn/blob/main/docs/essential.md)[FastDev workflow](https://github.com/arka-squad/arka-norn/blob/main/docs/fastdev.md)[Agent guide](https://github.com/arka-squad/arka-norn/blob/main/docs/agent-guide.md)[Agent orchestration](https://github.com/arka-squad/arka-norn/blob/main/docs/agent-orchestration.md)[Developer guide](https://github.com/arka-squad/arka-norn/blob/main/docs/developer-guide.md)[Architecture](https://github.com/arka-squad/arka-norn/blob/main/docs/architecture.md)[Security](https://github.com/arka-squad/arka-norn/blob/main/docs/security.md)[Troubleshooting](https://github.com/arka-squad/arka-norn/blob/main/docs/troubleshooting.md)[Live framing contract](https://github.com/arka-squad/arka-norn/blob/main/docs/norn-framing-contract-proposal.md)[Framing Product and UX method](https://github.com/arka-squad/arka-norn/blob/main/docs/norn-framing-method-research.md)[Migration to live framing](https://github.com/arka-squad/arka-norn/blob/main/docs/migration-2.3.2.md)[Stability contract 2.3](https://github.com/arka-squad/arka-norn/blob/main/docs/stability-2.3.md)\n\nCanonical examples are under:\n\n`examples/feature-complete`\n\n`examples/feature-essential`\n\n`examples/feature-fastdev`\n\n`examples/project-audit-v5`\n\n```\nnpm run lint\nnpm run typecheck\nnpm test\nnpm run selftest\nnpm run release:verify\nnpm run metrics:adoption\n```\n\nSource files are limited to 700 lines.\n\nCanonical code and public documentation are checked for French text. Generated skills, examples, and Web locale catalogs come from shared canonical sources. Production Web assets are built into `dist/web/`\n\nand shipped in the npm package.\n\n`metrics:adoption`\n\nis a maintainer-only, read-only report. It combines public npm download counts with the authenticated GitHub clone-traffic window exposed by `gh`\n\n.\n\nUse:\n\n```\nnpm run metrics:adoption -- --json\n```\n\nfor automation.\n\nNorn itself includes no installation telemetry. npm downloads are not unique installations, and GitHub clone traffic covers only the rolling 14-day window.\n\n`.input/`\n\nis an ignored internal workspace. It is not packaged, published, or included in public CI.", "url": "https://wpnews.pro/news/show-hn-arka-norn-local-governance-and-delivery-for-coding-agents", "canonical_source": "https://github.com/arka-squad/arka-norn", "published_at": "2026-08-27 10:56:38+00:00", "updated_at": "2026-08-27 11:19:47.781593+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["Arka.norn", "Codex CLI", "Claude CLI", "Gemini", "Node.js", "Docker", "Podman"], "alternates": {"html": "https://wpnews.pro/news/show-hn-arka-norn-local-governance-and-delivery-for-coding-agents", "markdown": "https://wpnews.pro/news/show-hn-arka-norn-local-governance-and-delivery-for-coding-agents.md", "text": "https://wpnews.pro/news/show-hn-arka-norn-local-governance-and-delivery-for-coding-agents.txt", "jsonld": "https://wpnews.pro/news/show-hn-arka-norn-local-governance-and-delivery-for-coding-agents.jsonld"}}