Add repository grant v2 publish scope and adopt daily security flow
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 4s
Build and Publish Container Image / build-and-push (push) Successful in 1m30s

ACTIVITY-WP-0046: grant v2 carries a publish scope (remote, branch, path
prefixes inside allowed_paths, fast-forward only) in its canonical grant id;
v1 stays local-only with unchanged ids.

ACTIVITY-WP-0047: disabled daily-security-flow definition dispatching the
the-custodian runner as an ops_run (CUST-WP-0079-T03).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 296847@bnt-lap001
Assistant-Session: 4f997d46-1b9d-4131-9699-0c353a215155
This commit is contained in:
tegwick 2026-10-13 21:08:15 +02:00
parent f9f2640f38
commit 9737577f0b
9 changed files with 372 additions and 29 deletions

View file

@ -267,6 +267,32 @@ types, unknown fields, and publication are rejected at definition sync and
again across the full emission batch. The admitted mapping is copied unchanged
to the queue claim/read response and never merged into `execution_refs`.
Repository-grant v2 (ACTIVITY-WP-0046) is the publish-capable form. It keeps
the v1 fields, requires `publish: true`, and adds a mandatory `publish_scope`:
```yaml
repository_grant:
version: "2"
allowed_paths: [checkpoints/]
commit_count: {min: 1, max: 1}
publish: true
publish_scope:
remote: origin # plain remote name, never a URL
branch: main # plain branch name, no refs/, no ..
path_prefixes: [checkpoints/]
fast_forward_only: true # the only accepted value; no force push
```
Every publish path prefix must lie inside `allowed_paths`. A v1 grant with
`publish: true` or a `publish_scope`, and a v2 grant without one, are
rejected. The grant id is the first 32 hex characters of SHA-256 over the
canonical JSON (sorted keys, compact separators) of `allowed_paths` (sorted),
`commit_count`, `publish`, `version` and, for v2, `publish_scope` with sorted
`path_prefixes`. v1 grant ids are unchanged. The rein echoes the grant id in
completion evidence and must refuse any push the grant does not cover;
normalized evidence may add `remote`, `branch`, `pushed_head`,
`fast_forward_only` and `published`.
`ACTIVITY_CORE_REQUIRE_HARNESS_PROFILE=true` makes a missing profile ref an
error both during file sync and emission. Deterministic report-only
instructions are exempt because they create no execution request. The flag