@kontourai/flow-agents 3.2.0 → 3.3.0

package/kits/builder/skills/continue-work/SKILL.md

@@ -49,6 +49,8 @@ Before doing anything else, restore the item's durable record into context throu
 
 If no durable record exists for the item, record that gap and rely on the issue body plus merged PRs/commits as the authoritative history.
 
+If the item was taken over from a stale incumbent (a `reclaimable` selection resumed via pull-work's **Takeover Protocol**, #294 / ADR 0021 §5), restoring the durable record IS the resumption: the deterministic slug points at the incumbent's existing `.kontourai/flow-agents/<slug>/`, and you continue the incumbent's branch (the `resume_branch` from `takeover-preflight`/the supersede output) — never a new branch, never a restarted plan. Takeover is resumption, not restart.
+
 ### 2. Determine the next undone slice
 
 From the issue body plus the merged PRs and commits referencing the issue, determine which slices have **landed** and which is the **next undone slice**.

package/kits/builder/skills/deliver/SKILL.md

@@ -247,6 +247,25 @@ After review, verification, evidence, and Goal Fit are clean for the same diff:
    npm run workflow:sidecar -- publish-delivery .kontourai/flow-agents/<slug>
    ```
 
+   **#356 — local reconcile-shape preflight.** `publish-delivery`/`record-release` now run a
+   local, pre-push **reconcile-shape preflight** on the session's `trust.bundle` before
+   copying anything into `delivery/`. It reuses the exact same claim-shape classification
+   `scripts/ci/trust-reconcile.js` enforces in CI (`scripts/lib/reconcile-shape.js`), so it
+   can never silently drift from what the required Trust Reconcile check actually does. If
+   the bundle is ADR-0020-invalid (e.g. a command-backed claim whose command isn't in the
+   reconcile manifest, an unwaived `assumed` claim, or an un-superseded disputed critique),
+   publish is **refused, fail-closed** — non-zero exit, a loud `REFUSING to publish` message
+   naming each invalid claim and its fix, and nothing is written to `delivery/`. This is
+   distinct from the existing fail-**soft** behavior when no `trust.bundle` exists yet at all
+   (still a silent no-op). When refused: fix the named claim (re-record evidence, add a
+   missing waiver, or supersede the disputed critique), then retry — do not attempt to push
+   past the refusal. You can also run the same check manually, any time before publish, to
+   catch a shape issue locally instead of discovering it minutes later in CI:
+
+   ```bash
+   npm run workflow:sidecar -- reconcile-preflight .kontourai/flow-agents/<slug>
+   ```
+
    **#379 — per-session delivery paths.** `publishDelivery()` writes to a PER-SESSION path
    `delivery/<slug>/trust.bundle` (+ `trust.checkpoint.json` companions), where `<slug>` is
    your session artifact dir's basename — NOT the old shared flat `delivery/trust.bundle`.
@@ -274,6 +293,60 @@ After review, verification, evidence, and Goal Fit are clean for the same diff:
    too — `git add -A delivery/` after the force-add. Do NOT hand-delete the flat
    `delivery/trust.bundle` in a delivery PR while other PRs may still seal to it.)
 
+   **#293 — verify-hold gate. HARD STOP.** Before committing/pushing/opening a PR/merging,
+   run the verify-hold check (it also runs automatically inside `publish-delivery` /
+   `record-release` / `advance-state --status delivered`, but run it explicitly here BEFORE
+   committing/pushing, since by the time `record-release` runs the branch may already be
+   pushed). **The command differs by this repo's configured assignment provider kind — a bare
+   `verify-hold <slug>` with no provider flag always defaults to `--assignment-provider
+   local-file` (`runVerifyHold`'s documented default), so on a `github`-provider repo it reads
+   no local claim record and silently resolves `free`/PASS regardless of the real GitHub hold
+   state. The local-file-only invocation below is NOT sufficient for a `github`-provider repo —
+   the github branch is MANDATORY for that provider kind:**
+
+   - **local-file provider** (this repo's configured assignment provider, from
+     `effective-assignment-provider-settings`, is `local-file`):
+
+     ```bash
+     npm run workflow:sidecar -- verify-hold .kontourai/flow-agents/<slug>
+     ```
+
+   - **github provider**: render-then-execute, mirroring `pull-work`'s SKILL.md claim-side
+     pattern for the same ADR 0021 §1 join — first read the effective state (no live `gh` call
+     happens inside `workflow-sidecar.ts`; the skill renders it here), then pass the rendered
+     `.effective` JSON into `verify-hold` via `--effective-state-json`:
+
+     ```bash
+     gh issue view <issue-number> --json assignees,labels,comments > /tmp/issue.json
+     npm run assignment-provider -- status \
+       --provider github \
+       --subject-id <slug> \
+       --issue-json /tmp/issue.json \
+       --liveness-stream <path-to-events.jsonl> \
+       --self-actor <actor> \
+       > /tmp/assignment-status.json
+     npm run workflow:sidecar -- verify-hold .kontourai/flow-agents/<slug> \
+       --assignment-provider github \
+       --effective-state-json /tmp/assignment-status.json
+     ```
+
+     (`/tmp/assignment-status.json`'s top-level shape is `{ role, provider, assignment,
+     effective }`; `verify-hold --effective-state-json` reads the `.effective` field, matching
+     `assignment-provider status`'s own output shape directly — no reshaping needed.)
+
+   This is the ONE point in the whole workflow that BLOCKS instead of warns (ADR 0021 §3). It
+   asks exactly one question: is this actor still the fresh, non-superseded holder of this
+   subject (or is the subject free/self-held)? **If the check reports not-fresh-holder (exit
+   non-zero, `ok:false` in the JSON result): DO NOT commit, push, open a PR, or merge.** This
+   is a different failure mode from the `publish-delivery`/reconcile-shape preflight paragraph
+   above — that one is about the trust *bundle's shape* being invalid; this one is about
+   *actor hold* — another actor holds a fresh claim on this subject, your own claim has gone
+   stale, or the subject is assigned to a human. Do not conflate the two "REFUSING to publish"
+   messages. When refused, follow the reconcile guidance (the CLI's own `guidance` field, or
+   verbatim): re-run `pull-work`/`pickup-probe` to discover the current holder and hand off
+   cleanly (`learning-review`/handoff), or, if a human confirms this session should resume
+   ownership, run `ensure-session --supersede-stale` before retrying.
+
 3. Commit the verified diff, including the force-added `delivery/<slug>/` trust artifacts.
 4. Push the branch.
 

package/kits/builder/skills/pull-work/SKILL.md

@@ -167,14 +167,24 @@ Read the returned `.effective.effective_state` and `.effective.reason` and class
 
 1. `effective_state: "held"` with `reason: "self_is_holder"` ⇒ `mine`: hand to `### 2. Enforce WIP And Shepherding`'s existing personal-WIP logic; do not re-offer as new, do not exclude as held-by-other.
 2. else `effective_state: "held"` (`reason: "fresh_liveness_heartbeat"` or `"liveness_claim_present_assignment_lagging"`) ⇒ excluded from the ready set by default.
-3. else `effective_state: "reclaimable"` ⇒ offered, flagged, with a warning; selecting it requires an explicit recorded opt-in (record in `reclaimable_override`, and/or `alignment_questions`), never a silent normal pick. This issue does not implement takeover — offering a `reclaimable` candidate, never auto-reclaiming it, is the correct scope boundary (Design Decision 2; full takeover protocol is ADR 0021 §5 / #294).
+3. else `effective_state: "reclaimable"` ⇒ offered, flagged, with a warning; selecting it requires an explicit recorded opt-in (record in `reclaimable_override`, and/or `alignment_questions`), never a silent normal pick. On selecting a `reclaimable` candidate, run the **Takeover Protocol** (#294, ADR 0021 §5) below — takeover is resumption, not restart: grace-beat, supersede, then continue the incumbent's branch. Never auto-reclaim without the recorded opt-in.
 4. else `effective_state: "human-held"` ⇒ surfaced, never auto-reclaimed (Design Decision 3 / ADR 0021 §6): record the assignee identity and idle duration (`effective.holder.assignee`, `effective.holder.idle_days`) in `alignment_questions` with a recommended answer (e.g. "assigned to `<assignee>`, idle `<idle_days>` days — reclaim?" recommending confirmation before proceeding), and select only on the user's explicit confirmation.
-5. else `effective_state: "free"` ⇒ offered normally — except a `superseded` liveness row (no active assignment, no fresh liveness) is surfaced but never auto-selected (full takeover semantics are #294; this is an accepted gap, not silently ignored), exactly as before this join upgrade.
+5. else `effective_state: "free"` ⇒ offered normally — including a `superseded` liveness row (no active assignment, no fresh liveness): now select-able via the **Takeover Protocol** below once the reclaimable/opt-in gate is satisfied (#294 implements the takeover semantics previously deferred here).
 
 An explicit user instruction to proceed despite a `held` or `reclaimable` classification (`--force`, "take it anyway", equivalent) overrides the exclusion/opt-in requirement; the override and its stated reason must be recorded in the artifact (`liveness_preflight`, `reclaimable_override`, and/or `priority_rationale`). A `human-held` classification is never overridden by `--force` alone — only the user's explicit answer to the recorded `alignment_questions` entry authorizes selecting it.
 
 This preflight now computes the **full** ADR 0021 §1 `assignment ⋈ liveness` join (previously liveness-only, pending #290): the assignment dimension is `#290`'s `AssignmentProvider` `status()` (`context/contracts/assignment-provider-contract.md`), joined against the same liveness stream this preflight already reads.
 
+#### Takeover Protocol (#294, ADR 0021 §5) — resumption, not restart
+
+When a `reclaimable` (or `superseded`-liveness) candidate is selected WITH the recorded opt-in, take it over by resuming the incumbent's work — never by starting a parallel branch or replanning. This is render-don't-execute: the CLI computes the decision and emits the exact steps; you run them.
+
+1. **Preflight:** `npm run workflow:sidecar -- takeover-preflight .kontourai/flow-agents/<slug>`. It returns `{action, effective_state, holder, resume_branch, grace_seconds, next_steps}`. Only `action: "grace-then-supersede"` proceeds; `back-off` (incumbent live/revived) ⇒ STOP and reselect; `ask-first` (human-held) ⇒ do not proceed without the user's explicit answer.
+2. **Grace beat:** wait `grace_seconds` (one heartbeat interval), then **re-run `takeover-preflight`**. If it now returns `back-off`, the incumbent revived — concede and reselect (this is the AC2 race guard). Proceed only if it is still `grace-then-supersede`.
+3. **Supersede:** `npm run workflow:sidecar -- ensure-session … --supersede-stale`. It re-checks the state and REFUSES if the incumbent revived in the meantime (a live `held` is never superseded), records the audit trail ("superseded actor X, last seen T, resuming from trust bundle"), and prints `resumed_branch`.
+4. **Resume the incumbent's branch — never a new one:** `git fetch origin <resume_branch> && git checkout <resume_branch>` (the `resume_branch` from step 1/3). Re-enter the existing artifact dir (the deterministic slug points at the same `.kontourai/flow-agents/<slug>/`); restore the durable record via the resume surface (#153) and continue from `handoff.json`/plan — do NOT re-plan or restart.
+5. **Record** the takeover (superseded actor, `resume_branch`, grace outcome) in `reclaimable_override`. If the superseded incumbent later wakes, it is blocked at publish by the verify-hold gate (#293) — the takeover is authoritative.
+
 `liveness claim`/`status`/`whoami` read/write the local runtime liveness stream, never GitHub issue/label/assignee state — this is not a provider mutation, and the two-provider-writes-only invariant in `## Contract` is unchanged by this slice. `#290` adds the one narrow, audited durable assignment claim that pairs with this liveness emit — see "Assignment Claim On Selection" below.
 
 ### 2. Enforce WIP And Shepherding

package/kits/veritas-governance/docs/README.md

@@ -1,8 +1,10 @@
 # Veritas Governance Kit
 
 Turns a repo's **Veritas-governed Repo Standards** into deterministic, agentless **gate
-evidence**. Slice 1 ships the thinnest useful surface: one flow, one gate, that gates a real
-`veritas readiness` verdict.
+evidence**, and gives operators a documented, gated path to **issue** the human-approval
+exemptions ADR 0022 §2/§3 lets `delivery/DECLARED` carry. Slice 1 shipped the thinnest useful
+surface: one flow, one gate, that gates a real `veritas readiness` verdict. This slice adds a
+second, agentless flow for exemption issuance.
 
 This kit **wraps** [`@kontourai/veritas`](https://www.npmjs.com/package/@kontourai/veritas) via
 CLI invocation plus a small kit-local trust.bundle adapter. It does **not** fork, vendor, or
@@ -16,6 +18,7 @@ only projects Veritas's own recorded verdict into the Flow trust.bundle vocabula
 | Flow | `flows/readiness-check.flow.json` | Single-gate agentless flow `readiness -> gate-check`. The gate requires a **verified** `software-readiness-verdict` trust.bundle claim. |
 | Adapter | `adapter/readiness-to-trust-bundle.mjs` | Projects a `veritas readiness --check evidence --working-tree` evidence report into a Hachure `trust.bundle` (via `@kontourai/surface`), deriving the claim status from Veritas's own blocking-failure signal. |
 | Fixtures | `fixtures/readiness/*.readiness-report.json` | Captured **real** Veritas readiness reports (a ready clean tree, and a not-ready tree with a required CLI artifact deleted) used by the eval. |
+| Flow | `flows/exemption-issuance.flow.json` | Single-gate agentless flow `request -> human-approval-gate -> issue`. The gate requires a **verified** `no-agent-delivery-exemption-approval` trust.bundle claim (`subjectType: "delivery-scope"`) before the `issue` step's write is flow-sanctioned. Issues a `delivery/DECLARED` exemption entry per ADR 0022 §2/§3. |
 
 The gate uses provider-neutral Flow vocabulary (`kind: "trust.bundle"`, `bundle_claim`) — the
 same vocabulary `kits/builder/flows/build.flow.json` uses. Veritas is simply the producer that
@@ -42,6 +45,79 @@ flow evaluate readiness --gate gate-check-gate --exit-code
 #    exit 0 when readiness is ready (claim verified); exit 1 (block) otherwise.
 ```
 
+## How to issue a no-agent-delivery exemption
+
+`flows/exemption-issuance.flow.json` (ADR 0022 §3, "the kit issues, the anchor enforces") gives
+an operator who needs to declare a `no-agent-delivery` exemption — e.g. dependabot,
+release-please, or another non-agent actor class — a documented, gated path instead of
+hand-writing `delivery/DECLARED` JSON blind. See `delivery/README.md` for how `delivery/`
+itself is used by CI, and ADR 0022 §3 for why issuance/audit live in this kit while enforcement
+stays anchor-side (`scripts/ci/trust-reconcile.js`, unmodified and unaware of this kit).
+
+```bash
+# 1. A human approver authors a Hachure trust.bundle asserting the exemption approval.
+#    (No adapter script exists for this slice -- the bundle is hand-authored or produced
+#    by whatever approval tooling records the decision; see "Human-approval evidence: what
+#    is and is not enforced" below for why this is convention, not a structural human-only
+#    guarantee.)
+#    Minimal bundle shape: {schemaVersion, source, claims:[{claimType:
+#    "no-agent-delivery-exemption-approval", subjectType: "delivery-scope",
+#    status: "verified", ...}], evidence:[...], policies:[...], events:[...]}
+
+# 2. Gate it (agentless, CI-callable).
+flow init
+flow start kits/veritas-governance/flows/exemption-issuance.flow.json --run-id exemption
+flow attach-evidence exemption --gate human-approval-gate --file approval.bundle --bundle
+flow evaluate exemption --gate human-approval-gate --exit-code
+#    exit 0 once the approval claim is verified; exit 1 (block) otherwise.
+
+# 3. Once the gate passes, append the approved entry to delivery/DECLARED (append, do NOT
+#    overwrite an existing array -- see delivery/DECLARED's current 2-entry file on main).
+#    All four fields are required: scope, reason, approved_by, declared_at. Compound scope
+#    forms (space-separated, ANDed -- e.g. "author:github-actions[bot]
+#    branch-prefix:release-please--") are supported by the reconciler's scope matcher; see
+#    ADR 0022's compound-scope addendum.
+```
+
+Example appended entry (third element of the existing `delivery/DECLARED` array — never a
+replacement of it):
+
+```json
+{
+  "scope": "author:some-bot[bot]",
+  "reason": "why this actor class needs the exemption",
+  "approved_by": "<human approver identity/decision reference>",
+  "declared_at": "<ISO 8601 timestamp>"
+}
+```
+
+## Human-approval evidence: what is and is not enforced
+
+The `human-approval-gate`'s `expects[]` entry only requires a **verified** trust.bundle claim
+of the right `claimType` (`no-agent-delivery-exemption-approval`) and `subjectType`
+(`delivery-scope`). **Flow's schema and CLI do not distinguish a human-authored bundle from an
+agent-authored one** — `trust-bundle.schema.json`'s `source` and `producerId` fields are
+free-text, with no enum, no cryptographic binding, and no CLI-side identity check.
+"Human-attached" is an **operating convention** this flow's `description`/`explore_hint` text
+encode (the gate's own copy tells an operator this evidence is meant to be authored by a human
+approver out-of-band), not a mechanism the gate itself enforces. Anyone who can run `flow
+attach-evidence --bundle` with a conforming bundle can satisfy this gate, exactly as anyone with
+commit access could already hand-author `delivery/DECLARED` directly.
+
+This is the same class of residual ADR 0022 already carries honestly for the marker file
+itself: `approved_by` on `delivery/DECLARED` is free text, not bound to an authenticated
+identity, mitigated by the loud, un-suppressible DECLARED line plus CODEOWNERS review on
+`/delivery/DECLARED` — not by identity attestation. This flow adds **guidance and an audit
+trail** (a named gate, a named claim type, a documented sequence) on top of that same
+mitigation, not a new authentication boundary. Structural producer authentication — binding
+gate satisfaction to an authenticated producer identity, rather than to a schema-valid claim
+attached by anyone with CLI access — is upstream **Flow trusted-producer** work
+(`docs/operating-layers.md`, `docs/flow-kit-repository-contract.md` in this repo describe the
+config surface; the config itself is Flow-core, tracked at #225/#293-family), not something
+this kit's `.flow.json` can itself express. Do not read a passing `human-approval-gate` as a
+structural guarantee that a human attached the evidence — read it as "a verified claim of the
+right shape was attached," full stop.
+
 ## Semantics
 
 **Settled** (owner-ratified + investigation-confirmed; see
@@ -72,4 +148,6 @@ decision deferred to a later slice (see the WS5 shaping's open decisions).
 
 Skills (`consult-standards`, `governance-evidence`), the fuller `merge-readiness` flow, the
 `standards-authoring` flow, and the `knowledge` dependency are later slices — see the WS5
-backlog.
+backlog. The `exemption-usage-review` periodic audit flow/skill named in ADR 0022 §3 (walks
+`delivery/DECLARED` history and surfaces standing exemptions for owner re-confirmation —
+process visibility, not enforcement) is also a separate, later slice, not shipped here.

package/kits/veritas-governance/fixtures/exemption/approved.trust-bundle.json

@@ -0,0 +1,74 @@
+{
+  "schemaVersion": 5,
+  "source": "veritas-governance-kit/exemption-fixture",
+  "claims": [
+    {
+      "id": "exemption-fixture.no-agent-delivery-exemption-approval.author-test-bot",
+      "subjectType": "delivery-scope",
+      "subjectId": "author:test-bot[bot]",
+      "facet": "veritas-governance.exemption",
+      "claimType": "no-agent-delivery-exemption-approval",
+      "fieldOrBehavior": "exemptionApproval",
+      "value": {
+        "scope": "author:test-bot[bot]",
+        "reason": "test-bot automation PR; no agent delivery involved",
+        "approved_by": "eval-fixture-approver"
+      },
+      "createdAt": "2026-07-01T00:00:00Z",
+      "updatedAt": "2026-07-01T00:00:00Z",
+      "impactLevel": "high",
+      "verificationPolicyId": "policy:no-agent-delivery-exemption-approval",
+      "metadata": {
+        "producer": "human-approver",
+        "source": "exemption-issuance-fixture"
+      },
+      "status": "verified"
+    }
+  ],
+  "evidence": [
+    {
+      "id": "ev:exemption-fixture.no-agent-delivery-exemption-approval.author-test-bot",
+      "claimId": "exemption-fixture.no-agent-delivery-exemption-approval.author-test-bot",
+      "evidenceType": "policy_rule",
+      "method": "auditability",
+      "sourceRef": "human-approver:exemption-issuance-fixture",
+      "excerptOrSummary": "A human maintainer approved a no-agent-delivery exemption for scope author:test-bot[bot].",
+      "observedAt": "2026-07-01T00:00:00Z",
+      "collectedBy": "veritas-governance-kit/exemption-fixture",
+      "passing": true
+    }
+  ],
+  "events": [
+    {
+      "id": "evt:exemption-fixture.no-agent-delivery-exemption-approval.author-test-bot",
+      "claimId": "exemption-fixture.no-agent-delivery-exemption-approval.author-test-bot",
+      "status": "verified",
+      "actor": "veritas-governance-kit/exemption-fixture",
+      "method": "auditability",
+      "evidenceIds": [
+        "ev:exemption-fixture.no-agent-delivery-exemption-approval.author-test-bot"
+      ],
+      "createdAt": "2026-07-01T00:00:00Z",
+      "verifiedAt": "2026-07-01T00:00:00Z"
+    }
+  ],
+  "policies": [
+    {
+      "id": "policy:no-agent-delivery-exemption-approval",
+      "claimType": "no-agent-delivery-exemption-approval",
+      "requiredEvidence": [
+        "policy_rule"
+      ],
+      "acceptanceCriteria": [
+        "A human maintainer has approved this delivery-scope exemption from Trust Reconcile's bundle-required enforcement."
+      ],
+      "reviewAuthority": "human",
+      "validityRule": {
+        "kind": "manual"
+      },
+      "stalenessTriggers": [],
+      "conflictRules": [],
+      "impactLevel": "high"
+    }
+  ]
+}

package/kits/veritas-governance/fixtures/exemption/not-approved.trust-bundle.json

@@ -0,0 +1,74 @@
+{
+  "schemaVersion": 5,
+  "source": "veritas-governance-kit/exemption-fixture",
+  "claims": [
+    {
+      "id": "exemption-fixture.no-agent-delivery-exemption-approval.author-test-bot",
+      "subjectType": "delivery-scope",
+      "subjectId": "author:test-bot[bot]",
+      "facet": "veritas-governance.exemption",
+      "claimType": "no-agent-delivery-exemption-approval",
+      "fieldOrBehavior": "exemptionApproval",
+      "value": {
+        "scope": "author:test-bot[bot]",
+        "reason": "test-bot automation PR; no agent delivery involved",
+        "approved_by": "eval-fixture-approver"
+      },
+      "createdAt": "2026-07-01T00:00:00Z",
+      "updatedAt": "2026-07-01T00:00:00Z",
+      "impactLevel": "high",
+      "verificationPolicyId": "policy:no-agent-delivery-exemption-approval",
+      "metadata": {
+        "producer": "human-approver",
+        "source": "exemption-issuance-fixture"
+      },
+      "status": "disputed"
+    }
+  ],
+  "evidence": [
+    {
+      "id": "ev:exemption-fixture.no-agent-delivery-exemption-approval.author-test-bot",
+      "claimId": "exemption-fixture.no-agent-delivery-exemption-approval.author-test-bot",
+      "evidenceType": "policy_rule",
+      "method": "auditability",
+      "sourceRef": "human-approver:exemption-issuance-fixture",
+      "excerptOrSummary": "A no-agent-delivery exemption approval claim was attached but is not (yet) verified for scope author:test-bot[bot].",
+      "observedAt": "2026-07-01T00:00:00Z",
+      "collectedBy": "veritas-governance-kit/exemption-fixture",
+      "passing": false
+    }
+  ],
+  "events": [
+    {
+      "id": "evt:exemption-fixture.no-agent-delivery-exemption-approval.author-test-bot",
+      "claimId": "exemption-fixture.no-agent-delivery-exemption-approval.author-test-bot",
+      "status": "disputed",
+      "actor": "veritas-governance-kit/exemption-fixture",
+      "method": "auditability",
+      "evidenceIds": [
+        "ev:exemption-fixture.no-agent-delivery-exemption-approval.author-test-bot"
+      ],
+      "createdAt": "2026-07-01T00:00:00Z",
+      "verifiedAt": "2026-07-01T00:00:00Z"
+    }
+  ],
+  "policies": [
+    {
+      "id": "policy:no-agent-delivery-exemption-approval",
+      "claimType": "no-agent-delivery-exemption-approval",
+      "requiredEvidence": [
+        "policy_rule"
+      ],
+      "acceptanceCriteria": [
+        "A human maintainer has approved this delivery-scope exemption from Trust Reconcile's bundle-required enforcement."
+      ],
+      "reviewAuthority": "human",
+      "validityRule": {
+        "kind": "manual"
+      },
+      "stalenessTriggers": [],
+      "conflictRules": [],
+      "impactLevel": "high"
+    }
+  ]
+}

package/kits/veritas-governance/flows/exemption-issuance.flow.json

@@ -0,0 +1,35 @@
+{
+  "id": "veritas-governance.exemption-issuance",
+  "version": "1.0",
+  "steps": [
+    { "id": "request", "next": "issue" },
+    { "id": "issue", "next": null }
+  ],
+  "gates": {
+    "human-approval-gate": {
+      "step": "issue",
+      "expects": [
+        {
+          "id": "exemption-approval",
+          "kind": "trust.bundle",
+          "required": true,
+          "description": "A human maintainer has approved this delivery-scope exemption from Trust Reconcile's bundle-required enforcement (ADR 0022 §1/§2), recorded as a verified no-agent-delivery-exemption-approval trust.bundle claim.",
+          "explore_hint": "A human approver authors a Hachure trust.bundle carrying a no-agent-delivery-exemption-approval / delivery-scope claim with status verified, then `flow attach-evidence <run> --gate human-approval-gate --file <bundle> --bundle`.",
+          "bundle_claim": {
+            "claimType": "no-agent-delivery-exemption-approval",
+            "subjectType": "delivery-scope",
+            "accepted_statuses": ["verified"]
+          }
+        }
+      ],
+      "on_route_back": {
+        "missing_evidence": "issue",
+        "default": "issue"
+      },
+      "route_back_policy": {
+        "max_attempts": 3,
+        "on_exceeded": "block"
+      }
+    }
+  }
+}

package/kits/veritas-governance/kit.json

@@ -8,6 +8,11 @@
       "id": "veritas-governance.readiness-check",
       "path": "flows/readiness-check.flow.json",
       "description": "Single-gate agentless flow: requires a verified software-readiness-verdict trust.bundle claim (projected from `veritas readiness --check evidence --working-tree`) before the gate-check step can pass. CI-callable, K0."
+    },
+    {
+      "id": "veritas-governance.exemption-issuance",
+      "path": "flows/exemption-issuance.flow.json",
+      "description": "Agentless K0 flow issuing a delivery/DECLARED no-agent-delivery exemption (ADR 0022 §2/§3): step request -> gate human-approval-gate (requires a verified no-agent-delivery-exemption-approval trust.bundle claim, satisfiable only by a human-authored approval bundle by convention -- see docs/README.md) -> step issue, which appends the approved entry to delivery/DECLARED. CI-callable."
     }
   ],
   "docs": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kontourai/flow-agents",
-  "version": "3.2.0",
+  "version": "3.3.0",
   "description": "Flow Agents — a Kontour product that applies Flow and Veritas discipline as a portable process layer inside the agent tools you already use: Claude Code, Codex, Kiro, opencode, pi, and GitHub Actions — with framework adapters (AWS Strands preview) on the same policy-engine contract.",
   "keywords": [
     "agents",