docs: preserve reviewed NetKingdom session artifacts
This commit is contained in:
codex
parent
6d14339f24
commit
00c586a806
50 changed files with 7826 additions and 0 deletions
|
|
@ -0,0 +1,354 @@
|
|||
---
|
||||
id: WARDEN-WP-0034
|
||||
type: workplan
|
||||
title: "Layer model v0.7 conformance — state the deadline, bind the agent boundary, steward the estate's newest rule"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: active
|
||||
flavor: residual
|
||||
depends_on:
|
||||
- WARDEN-WP-0030
|
||||
owner: ops-warden
|
||||
topic_slug: netkingdom
|
||||
planning_priority: P1
|
||||
depends_on_workplans:
|
||||
- WARDEN-WP-0030
|
||||
created: "2026-08-29"
|
||||
updated: "2026-09-28"
|
||||
state_hub_workstream_id: "ae3ff76f-883d-5e2f-b6aa-144d61e8fdef"
|
||||
---
|
||||
|
||||
# WARDEN-WP-0034 — Layer model v0.7 conformance
|
||||
|
||||
`security-layer-model_v0.7` is **accepted**. ops-warden declared Staff and PEP-shaped,
|
||||
shipped the two declaration artifacts the standard now cites as estate reference forms,
|
||||
and had four findings adopted into the text between v0.4 and v0.7.
|
||||
|
||||
The assessment in `history/2026-08-29-v07-scope-intent-assessment.md` checked every
|
||||
v0.7 obligation against shipped code rather than intent. Three gaps survive, plus a
|
||||
role the companion assigns that no conformance check will ever catch.
|
||||
|
||||
## Why a workplan and not an adhoc
|
||||
|
||||
T01 is a `MUST` that is currently unstated. T02 changes an enforcement boundary and
|
||||
touches `ADR-0004`. T04 is a cross-repo stewardship commitment against a standard eight
|
||||
repositories have yet to adopt. The convention reserves adhocs for low-risk work
|
||||
completed directly; none of these qualify.
|
||||
|
||||
## Tasks
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0034-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "8b3bdb9f-d2c2-5b3e-89e2-417bf3e37484"
|
||||
```
|
||||
|
||||
**State the revocation visibility deadline (§9.7.2, a MUST).**
|
||||
|
||||
ops-warden states none, and the honest value is the certificate TTL: **up to 48 hours**.
|
||||
A cert issued under an allow remains valid for its full TTL even if the authorizing
|
||||
decision is revoked the next minute. There is no CRL, no KRL distribution, and host-side
|
||||
`auth_principals` belongs to `railiance-infra`.
|
||||
|
||||
Add the deadline to `pep-stance.yaml` as what it is — `adm` 48h / `agt` 24h / `atm` 8h —
|
||||
with the mechanism named (TTL expiry, no revocation channel) rather than implied. Assert
|
||||
it against the shipped `ActorType` TTL policy by test, the same way the stance map is
|
||||
asserted equal to shipped behaviour: a stated deadline free to drift from the code has
|
||||
the same defect as a stated stance free to drift.
|
||||
|
||||
**Done when:** the deadline is published, test-bound to the TTL policy, and the absence
|
||||
of a revocation channel is stated rather than left to inference.
|
||||
|
||||
**Not in scope:** shortening it. Whether 48h is acceptable is a joint question with
|
||||
`railiance-infra` (KRL distribution) and is T05's to raise, not this task's to decide.
|
||||
|
||||
Completed 2026-09-04. `pep-stance.yaml` now publishes TTL expiry as the only
|
||||
revocation mechanism, explicitly records that no CRL/KRL channel exists, and
|
||||
states `adm=48h`, `agt=24h`, and `atm=8h`. The conformance test derives the
|
||||
expected map from `ActorType`/`MAX_TTL_HOURS`, so declaration and issuance
|
||||
policy cannot drift independently. The layer and stance declarations now name
|
||||
the accepted v0.7 standard.
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0034-T02
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "3318ee1a-b5d9-5d39-baf7-9c42a8bc7b55"
|
||||
```
|
||||
|
||||
**Bind the agent read-boundary to an issued identity (§3.4 rule 1).**
|
||||
|
||||
`ADR-0004`'s boundary triggers on `WARDEN_AGENT_ID` — a variable the agent sets about
|
||||
itself. An agent that omits it is not recognised as one. §3.4 rule 1 now requires
|
||||
authority to be *issued* per task and attributable to the principal acted for.
|
||||
|
||||
The identity exists as of `KEY-WP-0009-T03`: `codex-railiance-platform`, subject
|
||||
`service:codex:railiance-platform`, role `coding-agent`, 15-minute lifetime, with
|
||||
`railiance-platform` enforcing the OpenBao-side policy.
|
||||
|
||||
Key the boundary on the issued identity where one is present; keep `WARDEN_AGENT_ID` as
|
||||
a fallback that fails **toward** the boundary, never away from it. State plainly in the
|
||||
ADR trail which half is enforced and which is advisory: the OpenBao-side deny is real,
|
||||
the ops-warden-side refusal is a courtesy that a determined caller can decline.
|
||||
|
||||
**Done when:** an agent presenting the issued identity is recognised without setting
|
||||
`WARDEN_AGENT_ID`, the fallback still refuses on `risk: high` lanes, and the
|
||||
enforced/advisory split is written down.
|
||||
|
||||
**Watch:** do not turn this into ops-warden validating a token — that is verifying an
|
||||
identity claim, adjacent to deciding, and `ADR-0002`/§6 both point away from it. Read
|
||||
the identity; do not adjudicate it.
|
||||
|
||||
Completed 2026-09-04. The advisory CLI guard now prefers the exact issued
|
||||
KeyCape subject `service:codex:railiance-platform` from
|
||||
`WARDEN_POLICY_SUBJECT`, then falls back to `WARDEN_AGENT_ID`. Tests prove the
|
||||
issued subject triggers exit 7 without the legacy marker, the fallback remains,
|
||||
and an operator subject does not manufacture an agent identity. ADR-0004
|
||||
revision 2 records the enforced/advisory split: Warden reads the marker and
|
||||
does not validate a token; OpenBao's `agent-high-risk-boundary` is the real
|
||||
enforcement.
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0034-T03
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "a891b32c-b0a7-59f6-a5cd-977be65c09ca"
|
||||
```
|
||||
|
||||
**Derive an emission cadence, or defer it with a reason (§9.6).**
|
||||
|
||||
ops-warden's trail is attributive, so cadence is a SHOULD rather than v0.7's MUST for
|
||||
load-bearing sources. It has been silent through two reviews, which is the one outcome
|
||||
that is not defensible.
|
||||
|
||||
Derive a baseline from the existing `audit.jsonl` and signatures log. If the signal is
|
||||
too bursty to support a threshold — plausible, since volume is operator-driven — record
|
||||
that as the finding with the distribution that shows it, and declare the deferral in
|
||||
`pep-stance.yaml`. A measured "no useful baseline" is a result; silence is not.
|
||||
|
||||
**Done when:** either a declared cadence with its derivation, or a declared deferral
|
||||
carrying the data that justifies it.
|
||||
|
||||
Completed 2026-09-04 with an explicit measured deferral. The signatures log
|
||||
contains three issuances across the 79-day observation window, on only two
|
||||
active days: one on 2026-06-17 and two within 40 minutes on 2026-08-22. The
|
||||
unified audit carries the latter two events. `pep-stance.yaml` records the
|
||||
counts, dates, attributive classification, and reason that this sparse,
|
||||
operator-driven burst cannot support a meaningful rate threshold.
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0034-T04
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "94e73daa-f74d-51fd-8639-68896a4066ee"
|
||||
```
|
||||
|
||||
**Answer the question the companion sends the estate here to ask.**
|
||||
|
||||
> *"For how to get something done — which lane, which credential, which route — ask
|
||||
> `ops-warden`."*
|
||||
|
||||
Today the repo answers credential questions and no others. `warden route` and
|
||||
`warden plan` cover lanes, owners and acts. Nothing answers *"which layer am I"*, *"how
|
||||
do I declare"*, *"I am PEP-shaped, what do I owe"* — and eight of fifteen catalogued
|
||||
repositories have yet to declare.
|
||||
|
||||
Provide the path, not the doctrine (that boundary is `ADR-0010`'s and does not move):
|
||||
a routing entry and a short playbook that carry a reader from the companion to the files
|
||||
to copy — `layer.yaml`, `pep-stance.yaml`, `check_layer_conformance.py`,
|
||||
`test_layer_conformance.py` — and the check to run. The standard already names these in
|
||||
§11 and §6.4; what is missing is the route to them.
|
||||
|
||||
**Done when:** `warden route find "how do I declare my layer"` resolves, and the
|
||||
playbook is reachable from the catalog. **Not** a restatement of the companion — a
|
||||
pointer layer, per `ADR-0001`.
|
||||
|
||||
Completed 2026-09-04. Catalog entry `netkingdom-layer-declaration` resolves the
|
||||
exact query to `wiki/playbooks/netkingdom-layer-declaration.md`. The short
|
||||
playbook points at the accepted companion/statute, the four reference artifacts
|
||||
and checks, and the gate-house review path while explicitly leaving doctrine
|
||||
with gate-house and declaration truth with each repository.
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0034-T05
|
||||
status: wait
|
||||
blocked_on: message-from:ops-mason
|
||||
blocking_reason: "Two items to route, not absorb: ops-mason has published no stance map; the second is another repository's to own."
|
||||
priority: low
|
||||
state_hub_task_id: "7d1b3c82-9b96-5087-a53a-496212909029"
|
||||
```
|
||||
|
||||
**Two things to raise rather than absorb.**
|
||||
|
||||
Both are other repositories' to own; ops-warden's obligation is to route them, not to
|
||||
fix them (`ADR-0003`, `ADR-0005`).
|
||||
|
||||
1. **`ops-mason` has published no stance map.** §13.1's register has one row and the
|
||||
standard says that is itself the finding. `ops-mason` is catalogued PEP-shaped in
|
||||
the same paragraph and is ops-warden's peer lane owner. Offer the reference form;
|
||||
do not write their map.
|
||||
2. **The 48-hour replay window from T01.** Once stated, raise with `railiance-infra`
|
||||
whether KRL distribution is worth building, and with `access-engine` whether a
|
||||
decision lifetime shorter than the cert TTL is meaningful when nothing can recall
|
||||
the cert. State the question; let the owners answer.
|
||||
|
||||
**Done when:** both are routed with reasoning, and the answers recorded either way —
|
||||
including a refusal, which is an equally good answer.
|
||||
|
||||
Raised 2026-09-04 and waiting for answers. Ops-mason received the stance-map
|
||||
reference and classification question (message `6ddd6cc7`). Railiance-infra
|
||||
received the KRL-versus-TTL question (message `3bfa306e`). Flex-auth, as the
|
||||
current access-engine implementation, received the decision-lifetime semantics
|
||||
question (message `02c99a74`). No implementation or policy decision was assigned
|
||||
to another owner by these messages.
|
||||
|
||||
**One of three answered, 2026-09-09.** `flex-auth` answered the decision-lifetime
|
||||
question as `FLEX-DEC-2026-004` (flex-auth commit `6a6464f`), and answered it
|
||||
rather than declining it: a decision lifetime shorter than the certificate TTL is
|
||||
meaningful, but only as authority to **issue**, never as authority to **use** an
|
||||
already-issued certificate. The action is `sign` and it completes at issuance, so
|
||||
the decision is consumed once the certificate exists and no field in the decision
|
||||
record reaches the artifact. 15m against a 48h `adm` certificate was never an
|
||||
inconsistency to reconcile — the question mistook a decision lifetime for a
|
||||
credential lifetime.
|
||||
|
||||
Two obligations land on this side and are accepted: no replay of an allow past
|
||||
`expires_at`, and a fresh Check per sign. The second is where the value is, and it
|
||||
is real rather than nominal because claims are not cached PDP-side (deadline 0 for
|
||||
the claim class), so a revoked principal stops obtaining *new* certificates
|
||||
immediately.
|
||||
|
||||
`pep-stance.yaml` §9.7.2 is unchanged and stays here: flex-auth explicitly declined
|
||||
to move the residue to their side, on the ground that a PDP recalling an issued
|
||||
credential would be "the same shape of lie as fail-open". Declining it was the
|
||||
right call even though absorbing it would have made their record look tidier.
|
||||
|
||||
The TTL lever they named — capping requested TTL per actor class or zone, already a
|
||||
policy input since `ttl_out_of_bounds` is denied before OpenBao is reached — is
|
||||
noted and deliberately not requested. Shortening `adm` from 48h has an operator
|
||||
cost, and issuance on this lane is too sparse (3 signature records across 79 days,
|
||||
`pep-stance.yaml` `emission_cadence`) to price it from intuition.
|
||||
|
||||
T05 stays `wait` on the remaining two: `ops-mason` (no stance map published) and
|
||||
`railiance-infra` (KRL distribution versus TTL expiry). Neither has replied.
|
||||
|
||||
## Await gate-house's §11 precedence and case-sensitivity ruling
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0034-T06
|
||||
status: done
|
||||
priority: low
|
||||
state_hub_task_id: "b3b573df-2d2d-5a2c-9662-a13e435be57b"
|
||||
```
|
||||
|
||||
ops-warden declares `layer: Staff` in `INTENT.md` frontmatter and `layer: staff`
|
||||
in `layer.yaml`. §11 permits both forms and is silent on which governs when both
|
||||
exist and disagree, so two conformance runs over this repository can disagree
|
||||
while both follow the standard. Nine of nine repositories carrying both forms do
|
||||
the same thing (flex-auth `tools/survey_layer_declarations.go`, receipt
|
||||
`docs/evidence/2026-09-21-layer-declaration-survey.json`).
|
||||
|
||||
**RULED 2026-09-21, APPLIED 2026-09-21.** `GH-DEC-2026-017`
|
||||
(`gate-house@def0af2`, amendments A9-A13) answers both questions, and the answer
|
||||
to the second dissolves the first's consequence:
|
||||
|
||||
- **`INTENT.md` governs**; `layer.yaml` is a derived artifact that must be marked
|
||||
derived, must name `INTENT.md` as its source, and must agree with it.
|
||||
- **The §3 vocabulary is case-insensitive**, closed, and has four tokens
|
||||
(`Taxonomy`, `Tooling`, `Engine`, `Staff`). A conformance run MUST ASCII-fold
|
||||
case before comparing, and **no repository was asked to re-spell anything**.
|
||||
`Staff` and `staff` are one value.
|
||||
- **A declaration MUST NOT carry a standard version** — and that field is the
|
||||
*reference form's*, not this repository's habit, so ops-warden was asked to
|
||||
remove it here rather than each of seven adopters deciding.
|
||||
|
||||
Verified before editing against gate-house's own committed files rather than the
|
||||
inbox message: the decision at `gate-house@def0af2`, amendments A9-A13 in
|
||||
`docs/amendments/v0.8-section-11-declaration-amendments.md`, and §3/§4/§11 of
|
||||
`net-kingdom/canon/standards/security-layer-model_v0.8.md`.
|
||||
|
||||
**What was applied.** `standard_version` removed from `layer.yaml` **and** from
|
||||
`INTENT.md` frontmatter (the ruling's subject is the declaration, and `INTENT.md`
|
||||
is the declaration), with the version-pinned `standard:` path de-versioned for the
|
||||
same reason; `derived: true` / `derived_from: INTENT.md` added; **no layer value
|
||||
changed**; `scripts/check_layer_conformance.py` rewritten to read `INTENT.md` as
|
||||
governing, fold case, validate the closed four-token vocabulary, require the
|
||||
derived marking, and reject a returning `standard_version` — it previously
|
||||
*required* that field and so would have rejected the conforming declaration this
|
||||
ruling produces; `tests/test_layer_conformance.py` asserts the **fold** rather
|
||||
than equality, because an equality assertion would perform the re-spelling the
|
||||
ruling declined to order. `pep-stance.yaml` untouched: a stance map is not a layer
|
||||
declaration, and the schema beyond the derived marking and the version is
|
||||
explicitly not ruled.
|
||||
|
||||
**Evidence.** `python3 scripts/check_layer_conformance.py --report` exits 0 and
|
||||
prints the governing form and the derived one separately; `pytest
|
||||
tests/test_layer_conformance.py` green; full suite and `ruff` green. Reasoning
|
||||
and the adopter change set: `docs/layer-declaration-precedence.md` and
|
||||
`wiki/playbooks/netkingdom-layer-declaration.md`.
|
||||
|
||||
**Left open, and not decided here.** Where the removed version now lives. A12
|
||||
says version-scoped state belongs in the derived conformance record, which
|
||||
"already MUST" carry the version it was derived at; ops-warden has a re-runnable
|
||||
checker that emits nothing durable, not an emitted record. Whether §11 expects an
|
||||
emitted artifact or a re-runnable check discharges it is asked of gate-house in
|
||||
message `4220413a` and unanswered. Nothing applied above depends on the answer.
|
||||
**Closed 2026-09-21 by `GH-DEC-2026-020` §4 (gate-house@104f3fc):** §5 was wrong
|
||||
that the record exists; a re-runnable checker is sufficient if every run prints
|
||||
the version it checks against and its scope. Applied: the checker now prints
|
||||
`VALIDATED_AGAINST` and `SCOPE` on every run and enforces A12 r2 by content, not
|
||||
key name (versioned `standard:` path, `companion_version`); `pep-stance.yaml`
|
||||
untouched per §3; the playbook carries the adopter change set.
|
||||
|
||||
**Ruled the same day, and still `wait` — deliberately.** `GH-DEC-2026-017`
|
||||
(message `3715e247`) landed hours later: `INTENT.md` governs, the sidecar is a
|
||||
derived artifact that must be marked as such, §3's vocabulary is case-insensitive
|
||||
so **nobody re-spells anything**, and `standard_version` must come out of the
|
||||
declaration. Two asks land on ops-warden specifically because `layer.yaml` is the
|
||||
form seven repositories copied.
|
||||
|
||||
This task stays `wait` rather than flipping to `progress`, because applying it
|
||||
edits this repository's security-layer declaration — and the estate's reference
|
||||
shape — on the strength of an instruction delivered in an inbox message. The
|
||||
session that applies it should be mandated to, and should verify the decision at
|
||||
`gate-house@def0af2` and amendments A9–A13 in the repository rather than from the
|
||||
message text. The exact change set and its four conditions are written down in
|
||||
`docs/layer-declaration-precedence.md`; the casing half of the original "done
|
||||
when" above is moot rather than outstanding, since the ruling folds case.
|
||||
|
||||
Raised by flex-auth's corrected B1 (message `719b3e9e`, 2026-09-21), which
|
||||
withdrew an earlier claim that the estate disagreed *across* repositories. The
|
||||
withdrawal matters to this task: the original finding would have had ops-warden
|
||||
changing a file to match an estate consensus that did not exist.
|
||||
|
||||
## Related
|
||||
|
||||
Review 2026-09-05: reviewed the pending implementation and fixed the identity
|
||||
helper so an explicitly empty environment does not inherit the process identity.
|
||||
Regression coverage also proves an operator subject cannot override the legacy
|
||||
agent marker. Refreshed the generated high-risk path artifact after the catalog
|
||||
changes. T05 remains waiting: no corresponding reply was present in the inbox,
|
||||
and the checked owner workplans contained no resolution of these questions.
|
||||
Validation: 415 unit tests and four SSH integration tests pass; Ruff, the
|
||||
layer-conformance script, and the declaration-route CLI smoke check pass.
|
||||
|
||||
- `history/2026-08-29-v07-scope-intent-assessment.md` — the gap analysis behind this plan
|
||||
- `history/2026-08-29-layer-model-v04-review.md`, `-v06-review.md` — the two prior reviews
|
||||
- `security-layer-model_v0.7.md` §3.4, §6.4, §9.6, §9.7, §11, §13.1
|
||||
- `net-kingdom/SECURITY-COMPANION.md` v0.2
|
||||
- `ADR-0002`, `ADR-0003`, `ADR-0004`, `ADR-0005`, `ADR-0009`, `ADR-0010`
|
||||
|
||||
### 2026-09-28 loose-end review
|
||||
|
||||
T05 remains wait; the workplan is blocked on the two outstanding owner answers.
|
||||
The local ops-mason checkout still has no published stance map, and the available
|
||||
railiance-infra workplans/docs contain no KRL-versus-TTL acceptance or refusal.
|
||||
The flex-auth decision-lifetime answer remains accepted. Warden's declaration,
|
||||
TTL-bound tests and fresh-check behavior are complete; inventing an owner answer
|
||||
would not satisfy T05. No certificate lifetime or revocation policy was changed.
|
||||
|
||||
> 2026-10-11: demoted to `flavor: residual` / `backlog` by founder-authorized triage — off the
|
||||
> critical path (identity → authz → secrets → SecurityCase execution). Tasks are unchanged;
|
||||
> promote back when demand or risk appears. See the-custodian
|
||||
> `history/20261011-netkingdom-security-progress-assessment.md`.
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
---
|
||||
id: WARDEN-WP-0035
|
||||
type: workplan
|
||||
title: "Register the Policy Nexus Forgejo source-read route"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: finished
|
||||
owner: codex
|
||||
topic_slug: policy-nexus-forgejo-source-read
|
||||
created: "2026-09-01"
|
||||
updated: "2026-09-01"
|
||||
state_hub_workstream_id: "45aec8d3-94b3-586e-b019-a47e656efafa"
|
||||
---
|
||||
|
||||
## Register the exact high-risk lane
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0035-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "dd84f2be-0143-540c-9c16-74f0fd129260"
|
||||
```
|
||||
|
||||
Add the exact OpenBao path, field, OIDC role, owner pointer, and rotation
|
||||
boundary from railiance-platform CCR-2026-0014. The entry must be concrete and
|
||||
resolvable while remaining subject to Warden's high-risk agent read boundary.
|
||||
|
||||
## Verify routing and governed use
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0035-T02
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "1fa8f778-3e46-5f44-86c4-cab8628b7e60"
|
||||
```
|
||||
|
||||
Pass catalog, route-selection, proxy, and policy tests; reinstall the CLI; prove
|
||||
the installed route resolves and can hand the value only to a sanctioned child
|
||||
transport without printing or persisting it.
|
||||
|
||||
Completed 2026-09-01. All 406 selected tests passed, including the generated
|
||||
high-risk data-path boundary. The no-cache installed CLI resolves the exact
|
||||
lane, and `warden plan` returns only sanctioned `--exec`, `--out`, and `--wrap`
|
||||
transports for an agent caller. Policy Nexus Actions run 32 separately proved
|
||||
the installed credential against the complete private-source fetch and release
|
||||
path without exposing the value.
|
||||
|
|
@ -0,0 +1,131 @@
|
|||
---
|
||||
id: WARDEN-WP-0036
|
||||
type: workplan
|
||||
title: "Accept contained OpenBao login output only after helper persistence"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: finished
|
||||
owner: codex
|
||||
topic_slug: attended-login-openbao-output
|
||||
created: "2026-09-01"
|
||||
updated: "2026-10-15"
|
||||
state_hub_workstream_id: "d844c96e-152d-53fa-bff6-e072125ef66c"
|
||||
---
|
||||
|
||||
## Repair attended-login handoff
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0036-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "7eb8b9c9-1285-5ada-a17b-1d5bfbb8ba59"
|
||||
```
|
||||
|
||||
Allow a successful OpenBao login to proceed when its output is fully contained
|
||||
and the private mode-0600 token helper is populated. Continue failing closed on
|
||||
non-zero login, missing persistence, child output, revocation failure, or cleanup
|
||||
failure.
|
||||
|
||||
## Verify live contained operation
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0036-T02
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "d22bab05-c38b-561f-95de-6c146ce7c6cf"
|
||||
```
|
||||
|
||||
Run the proxy regression suite, reinstall the CLI, and complete one governed
|
||||
OpenBao platform-admin operation with deterministic self-revocation.
|
||||
|
||||
Completed 2026-09-01. The installed CLI completed the governed Policy Nexus
|
||||
Forgejo source bootstrap with all child output contained, then revoked and
|
||||
removed its isolated helper session.
|
||||
|
||||
### 2026-09-28 contained-result correction (existing T01/T02)
|
||||
|
||||
Addressed the September 21 attended-login failure/audit report under the existing
|
||||
handoff repair and verification tasks. Failed envelopes now use distinct
|
||||
non-zero codes 10–14 for login, child failure, child output, unconfirmed revocation
|
||||
and cleanup failure. Both audit files retain the actual Warden exit code and
|
||||
phase outcome. Any child bytes, including whitespace, fail closed; the access
|
||||
advisory now states the silent-child requirement and the playbook documents codes,
|
||||
retry limits and the WSL tunnel/browser requirements.
|
||||
|
||||
The pre-change checkout already raised exit 5 on ProxyError, so the reported
|
||||
historical exit-zero failure was not reproduced here. The actual reproduced defect
|
||||
was unconditional success auditing; the new CLI regression covers failed login
|
||||
with returncode zero but missing persistence as well as non-zero login, start
|
||||
failures, child output/failure, revocation and cleanup. Revocation still checks
|
||||
revoke-self's exit status; it does not misinterpret an arbitrary failed lookup as
|
||||
proof. The September 23 platform return confirms revoke-self is already granted.
|
||||
|
||||
Validation: focused proxy suite 48 passed; full suite 483 passed, 4 integration
|
||||
tests deselected by repository default; changed Python files pass Ruff. No live
|
||||
OIDC, credential read or production operation was used. The earlier September 1
|
||||
live operation remains historical evidence, not a live validation of this change.
|
||||
Automated endpoint/browser preflight and OIDC URL presentation remain optional
|
||||
inbox suggestions, outside these completed handoff acceptance criteria.
|
||||
|
||||
### 2026-10-14 login-output fail-closed regression and fix (existing T01)
|
||||
|
||||
railiance-platform's RPF-WP-0017 re-acceptance review
|
||||
(`railiance-platform/reviews/RPF-WP-0017-ops-warden-reacceptance-2026-10-14.json`,
|
||||
decision `reject`) found that T01's commit `b4c1d39` (2026-09-01) dropped
|
||||
`login_output.strip()` from the login fail-closed condition. From then until this
|
||||
fix, a login that exited 0 with a populated helper proceeded to the child whatever
|
||||
it wrote to stdout/stderr. Output stayed contained (criterion 3 held) but
|
||||
criterion 4 (non-allowlisted output fails closed with self-revocation) and the
|
||||
criterion 5 unexpected-output coverage regressed; the existing unexpected-output
|
||||
test passed only through the empty-helper persistence path.
|
||||
|
||||
Fix: login output is still captured and never forwarded, and is now accepted only
|
||||
when allowlisted by structure (values are never logged, returned, stored, or put
|
||||
in exceptions/audit):
|
||||
|
||||
- stdout: empty, or exactly one JSON object with an `auth` object containing
|
||||
`client_token`; top-level keys limited to `request_id, lease_id,
|
||||
lease_duration, renewable, data, warnings, wrap_info, mount_type, auth`, auth
|
||||
keys to `client_token, accessor, policies, token_policies, identity_policies,
|
||||
metadata, orphan, entity_id, lease_duration, renewable, mfa_requirement,
|
||||
num_uses`, each type-checked; duplicate keys rejected.
|
||||
- stderr: empty, or exactly the OpenBao OIDC CLI prompt ("Complete the login via
|
||||
your OIDC provider. Launching browser to:" or "... Open the following link in
|
||||
your browser:", one `https://` URL, optional "Waiting for OIDC authentication to
|
||||
complete..."). These prompt strings were confirmed present in the local `bao`
|
||||
binary; this stderr allowlist entry is an ops-warden proposal pending
|
||||
railiance-platform review under RPF-WP-0017.
|
||||
|
||||
Anything else (extra text, other stderr, multiple objects, unexpected keys or
|
||||
types, parse/decoding failure) fails closed: self-revocation through the existing
|
||||
path, helper cleanup, exit 10 / `login_failed`, no retry. Added a parametrized
|
||||
populated-helper test for 13 non-allowlisted shapes and an allowlisted hand-off
|
||||
test; the success test now uses a full JSON shape plus the OIDC prompt. The
|
||||
September 1 T02 live operation was recorded in `9770d6a` (00:51 +0200), after
|
||||
`b4c1d39` (00:13 +0200) and `8f01eef` (00:24 +0200); `proxy.py` at that time
|
||||
contained the relaxed check (the installed CLI's exact revision was not recorded). No live OIDC, OpenBao call, or credential read was used for this fix.
|
||||
|
||||
Tightened the same day after an independent re-review (containment gap): stdout
|
||||
`wrap_info` must be null or absent (a wrapping token would survive `token revoke
|
||||
-self`), `data` null, absent or `{}`, and `auth.client_token` a non-empty string;
|
||||
the stderr OIDC prompt must start at the first byte (no leading whitespace;
|
||||
trailing newlines remain fine). The fail-closed and hand-off tests now run through
|
||||
the CLI and assert sentinel absence from both `access-audit.log` and `audit.jsonl`.
|
||||
|
||||
### 2026-10-15 CUST81 dependency correction (existing T01/T02)
|
||||
|
||||
Prepared source correction after the two CUST81 attended platform-admin attempts
|
||||
failed before child handoff. The strict login-output allowlist remains unchanged.
|
||||
Synthesized format flags now precede auth data; the recovery-only matcher handles
|
||||
OpenBao `s.` tokens; failure messages expose only fixed categories, client exit
|
||||
code and helper/output-shape booleans. No credential bytes or URLs are surfaced.
|
||||
|
||||
Do not attribute the observed 121-second failure to the argv order: Bao 2.5.5
|
||||
scans global format throughout argv. Actual callback/auth failure remains unknown.
|
||||
Browser profile initialization was verified from metadata only; server revocation
|
||||
remains unconfirmed and the failed attempts are retained. No login, admin token
|
||||
read, policy application or provisioning was performed by this correction.
|
||||
|
||||
Source verification is distinct from live verification. The already-approved
|
||||
CUST81 execution scope and its open attended gate remain with CUST-WP-0081-T02.
|
||||
Owner evidence: `docs/evidence/2026-10-15-cust81-attended-dependency-repair-r1.json`.
|
||||
|
|
@ -0,0 +1,191 @@
|
|||
---
|
||||
id: WARDEN-WP-0037
|
||||
type: workplan
|
||||
title: "Repoint the whynot-design npm lane to Forgejo"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: blocked
|
||||
flavor: planning
|
||||
owner: codex
|
||||
topic_slug: whynot-design-forgejo-npm-lane
|
||||
created: "2026-09-04"
|
||||
updated: "2026-10-03"
|
||||
state_hub_workstream_id: "42a097db-1c24-558e-a724-030bb2b4443e"
|
||||
---
|
||||
|
||||
## Verify the existing credential against Forgejo
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0037-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "afc4d325-1c6d-5c25-aaf7-2118aa8f86c6"
|
||||
```
|
||||
|
||||
Use only the governed execution transport to test the existing publish identity
|
||||
against the canonical Forgejo npm endpoint. Do not print or persist the token.
|
||||
|
||||
2026-09-04: `warden plan` classified the exact verification as autonomous and
|
||||
selected this lane. A contained login using the documented
|
||||
`whynot-design-workload-kv-read` role proved `read` on the exact OpenBao data
|
||||
path, and the governed child proved the secret is present. A real 0.4.2 publish
|
||||
through that credential then failed. No value was printed or persisted and each
|
||||
contained session self-revoked. The lane therefore needs token rotation, not an
|
||||
OpenBao policy repair.
|
||||
|
||||
## Repoint the catalog and playbook
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0037-T02
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "7ceb2f74-496c-54e8-bf5a-3c49f994ff23"
|
||||
```
|
||||
|
||||
Replace the retired Gitea endpoint and discovery language with Forgejo while
|
||||
preserving the established OpenBao path, field, and least-privilege boundary.
|
||||
This delivers the npm facet of routed intake
|
||||
`01a06e07-f2f9-7586-9745-b359eb0025b6`; its inter-hub SSH facet remains separate.
|
||||
|
||||
Completed 2026-09-04. The catalog title, discovery keywords, rotation guidance,
|
||||
and worker playbook now name the canonical Forgejo registry at
|
||||
`https://forgejo.coulomb.social/api/packages/coulomb/npm/`. The OpenBao path,
|
||||
field, owner, native-exec pointer, and high-risk boundary are unchanged. A
|
||||
regression assertion prevents the retired Gitea discovery term and guidance
|
||||
from returning.
|
||||
|
||||
## Prove routing and publication
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0037-T03
|
||||
status: wait
|
||||
priority: high
|
||||
decision_id: 1591daa1-6e85-4dfd-aadd-5a9fe1ef47fa
|
||||
depends_on: [SECRETS-WP-0006-T06]
|
||||
blocking_reason: "Hold kept by D3 until SECRETS-WP-0006-T06 moves publishing off the legacy whynot-design npm path; then rotate and prove a fresh publish."
|
||||
intervention_note: "HOLD (founder, 2026-09-21): do not rotate yet. secrets-engine exec reads the ungoverned legacy path secret/coulomb/whynot-design/npm/publish (field npm_token); this runbook writes the governed path platform/workloads/coulomb/whynot-design/npm-publish (NPM_AUTH_TOKEN). A rotation now would not reach the live publish path. Resume after SECRETS-WP-0006-T06 moves the lane. Then: rotate the dedicated Forgejo package token, and prove a fresh publish and exact npm view through this lane."
|
||||
state_hub_task_id: "a8b1b855-ab34-5835-b9fd-5f48bc0b6817"
|
||||
```
|
||||
|
||||
2026-10-11: requalified after founder decision D3 (trust root, build-mode default) resolved — see the-custodian docs/decisions/2026-10-11-security-unblock-decisions.md.
|
||||
|
||||
Pass catalog and routing tests, verify the checkout route, and record the exact
|
||||
Forgejo package release proven through the lane.
|
||||
|
||||
2026-09-04: repo-local verification is complete: the checkout route ranks
|
||||
`whynot-design-npm-publish` first for a Forgejo npm publish need, reports the
|
||||
canonical Forgejo title and verification command, all focused
|
||||
routing/access/proxy tests pass (`145 passed`).
|
||||
|
||||
The sibling repo's `@whynot/design@0.4.2` release (105 files; IR
|
||||
`designVersion` 0.4.2; five visual tests pass) was published through the
|
||||
plan-authorized `forgejo-admin-api-token` one-time recovery lane. An
|
||||
authenticated exact-version lookup proved that Forgejo's remote integrity
|
||||
matches the local dry-run. T03 waits only on rotating the dedicated package
|
||||
token and proving the next fresh version through `whynot-design-npm-publish`;
|
||||
the package migration itself is complete.
|
||||
|
||||
**2026-09-09 — field claim corrected, path routed.** `secrets-engine` (msg
|
||||
`15f0c0ca`) corrected two things and declined a third, all correctly.
|
||||
|
||||
The KV field is `npm_token`. `NPM_AUTH_TOKEN` is the environment variable their
|
||||
publication-scope policy injects, and ops-warden had copied the env var in as the
|
||||
field name — so the catalog's `fetch_command` named a field that does not exist
|
||||
and could only ever have failed. Corrected in `registry/routing/catalog.yaml` and
|
||||
`wiki/playbooks/whynot-design-npm-publish.md` from the owner's statement rather
|
||||
than re-derived here. This was `ADR-0001`'s failure mode rather than a typo: a
|
||||
pointer layer restating an owner's procedure and getting a detail wrong.
|
||||
|
||||
The endpoint claim already agreed; `delivery_config.npm.registry` has been the
|
||||
Forgejo URL throughout.
|
||||
|
||||
The **path** is routed to `railiance-platform` and the catalog is unchanged pending
|
||||
their answer. Which location backs the lane for reads is custody state they own;
|
||||
`secrets-engine` has no lane read authority to confirm it and refused to rewrite a
|
||||
production lane pointer from a coordination message (`SECRETS-WP-0006-T06`). Their
|
||||
reasoning is right, and asserting our own pointer is authoritative because it is
|
||||
ours would route around it. The ask names a location only and flags that a
|
||||
`bao kv get` answer would be the 2026-07-16 disclosure vector on a `risk: high`
|
||||
lane.
|
||||
|
||||
`ready: false` is not being read as path evidence: a source checkout with no
|
||||
production authority reports not-ready regardless of which path the catalog names.
|
||||
|
||||
T03 still waits on the human rotation of the dedicated Forgejo package token; the
|
||||
path question does not block that, it determines whether the pointer is correct
|
||||
once it rotates.
|
||||
|
||||
**2026-09-21 — field reverted to `NPM_AUTH_TOKEN`; path confirmed; a second
|
||||
location found.** `railiance-platform`, who holds custody of the path, answered
|
||||
both halves (msgs `c6841bdb`, `79f3e047`) and the answer reverses the 2026-09-09
|
||||
change above.
|
||||
|
||||
An attended founder session enumerated the field names present at
|
||||
`platform/workloads/coulomb/whynot-design/npm-publish`: read-only, no mutation,
|
||||
no value emitted, `attended_identity` true. **Exactly one field is present, and
|
||||
it is `NPM_AUTH_TOKEN`.** Receipt: `railiance-platform
|
||||
docs/evidence/2026-09-10-npm-lane-field-resolution.json`, commit `9d24086`. The
|
||||
both-fields reconciliation offered the day before is ruled out by the same
|
||||
enumeration. `CCR-2026-0001` has carried two dated receipts naming that field
|
||||
since 2026-06-28, one of them an attended founder fetch that exited zero — which
|
||||
is itself proof the field exists.
|
||||
|
||||
So `npm_token` is wrong *for this path*, and the catalog and playbook are
|
||||
reverted to `NPM_AUTH_TOKEN`. Reverting is a correction back to the evidenced
|
||||
value, not a new lane change.
|
||||
|
||||
The lesson is the one this plan already recorded, one level in. On 2026-09-09
|
||||
this file wrote that adopting a correction from `secrets-engine` rather than
|
||||
re-deriving it was the right shape. It was the right *source* and the wrong
|
||||
*standard of evidence*: a correction adopted from a coordination message is
|
||||
still an unverified mutation, even when it is only a field name in a catalog,
|
||||
and this one would have failed at the rotation T03 is waiting for — the moment
|
||||
it is most expensive to discover. railiance-platform's phrasing, kept because it
|
||||
is better than ours: it will break "at the moment you least want it to".
|
||||
|
||||
**The second location, which is not ours to dispose of.**
|
||||
`secret/coulomb/whynot-design/npm/publish` exists — version 1, created
|
||||
2026-07-03T15:00:44Z, never updated, five days *after* the governed lane was
|
||||
verified. It sits outside this lane's exact-path policy and outside any CCR.
|
||||
railiance-platform read metadata only: field names were not enumerated, the
|
||||
value was not read, nothing was deleted, because a location holding real
|
||||
credential material is disposed of deliberately by its owner rather than tidied
|
||||
away by whoever finds it.
|
||||
|
||||
Their unconfirmed hypothesis, recorded because it changes what this lane's
|
||||
acceptance evidence means if true: `secrets-engine`'s lowercase field may belong
|
||||
to *that* path, their catalog may declare that location, and the proven pilot
|
||||
publish may have been reading the duplicate all along. If so, a working
|
||||
production lane has been running ungoverned and this lane's acceptance evidence
|
||||
describes a path its consumer does not use. Tracked as `RPF-WP-0035-T07`;
|
||||
railiance-platform has asked `secrets-engine` which location their publish
|
||||
reads, and ops-warden has asked the same about the native
|
||||
`secrets-engine exec` front door this catalog points at (`exec_owner`).
|
||||
|
||||
Recorded in the catalog and in `wiki/playbooks/whynot-design-npm-publish.md` as
|
||||
an explicit non-lane rather than deleted from the record. Not routed around: the
|
||||
governed path stays the pointer.
|
||||
|
||||
### 2026-09-27 owner follow-up
|
||||
|
||||
Consumed the September 21 secrets-engine source return: the active catalog
|
||||
still names `secret/coulomb/whynot-design/npm/publish`, field `npm_token`.
|
||||
The governed field remains `NPM_AUTH_TOKEN`; no pointer correction is needed
|
||||
in Warden. RPF-WP-0035-T07 now requires native governed-consumer proof before
|
||||
legacy destruction and no longer asks for comparison of secret values.
|
||||
|
||||
T03 remains wait and the founder's no-rotation hold remains effective.
|
||||
Resume only on the SECRETS-WP-0006-T06 migration receipt, then rotate through
|
||||
the dedicated package lane and prove a fresh publish plus exact npm view.
|
||||
Do not treat the September 16 OpenRouter key-check receipt as npm acceptance.
|
||||
|
||||
### 2026-09-28 loose-end review
|
||||
|
||||
Workplan state corrected to blocked to match T03's wait and the September 27
|
||||
owner return. The governed catalog field and path are already correct. The
|
||||
founder's no-rotation hold remains binding until SECRETS-WP-0006-T06 supplies
|
||||
native governed-consumer migration evidence; a dedicated token rotation and a
|
||||
fresh package publish/exact-version lookup then remain. No credential fetch,
|
||||
rotation or publication was attempted.
|
||||
|
||||
2026-10-03 (CUST-WP-0075): the gate was only in intervention_note. Encoded as blocking_reason, depends_on SECRETS-WP-0006-T06, and hub decision 1591daa1-6e85-4dfd-aadd-5a9fe1ef47fa (D3: trust root and secret custody), which also carries the matching RPF-WP-0035-T07 hold.
|
||||
|
|
@ -0,0 +1,149 @@
|
|||
---
|
||||
id: WARDEN-WP-0038
|
||||
type: workplan
|
||||
title: "warden plan must distinguish reading a secret from mutating one"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: finished
|
||||
owner: ops-warden
|
||||
topic_slug: netkingdom
|
||||
planning_priority: P1
|
||||
depends_on_workplans:
|
||||
- WARDEN-WP-0029
|
||||
created: "2026-09-08"
|
||||
updated: "2026-10-16"
|
||||
state_hub_workstream_id: "751ad530-e44b-52c4-b70e-cb47568a0179"
|
||||
---
|
||||
|
||||
# WARDEN-WP-0038 — Read versus mutate intent in the policy front door
|
||||
|
||||
## The defect
|
||||
|
||||
`warden plan` scores a need against catalog lanes by keyword overlap and returns
|
||||
a verdict. It has no notion of what the caller wants to *do*. So a need that
|
||||
says *generate a successor secret and CAS-write it to two custodians* matches the
|
||||
lane that **reads** that path, scores well on the shared nouns, and returns:
|
||||
|
||||
```
|
||||
verdict: autonomous
|
||||
commands: warden access <lane> --exec / --out / --wrap
|
||||
```
|
||||
|
||||
Three read transports offered as the answer to a write, under the verdict that
|
||||
means "proceed without the founder". Reproduced 2026-09-08 against
|
||||
`rapp-qonto-keycape-client` (`ADHOC-2026-09-08-T04`).
|
||||
|
||||
## Why this is worse than a bad suggestion
|
||||
|
||||
`warden plan` is the documented first step before drafting any founder credential
|
||||
step (`.claude/rules/credential-routing.md`), and `autonomous` is consumed as an
|
||||
authorization signal by agents that have no other check. `WARDEN-WP-0029` shipped
|
||||
the verdict *because* instinct was not auditable; a verdict that is confidently
|
||||
wrong in the permissive direction is worse than no verdict.
|
||||
|
||||
key-cape hit this and refused to rely on it — "we are not treating a generic
|
||||
match as authorization" — which is the only reason it surfaced as a design
|
||||
question rather than as an unadmitted custody mutation. The control that caught
|
||||
it was a counterparty's caution. That is not a control.
|
||||
|
||||
`WARDEN-WP-0033-T06` is the same shape (rapp-postgres, generic
|
||||
`openbao-api-key` match → `paste_once_provision` for an act that could not work)
|
||||
and was fixed by adding one exact lane plus one regression. That fixed the
|
||||
instance. This is the class.
|
||||
|
||||
## Shape of the fix (to be designed, not assumed)
|
||||
|
||||
- Classify need intent — read / mutate / establish — before scoring, and never
|
||||
answer a mutate need with a read lane's transports.
|
||||
- A mutate need against a lane ops-warden does not own is `unroutable` with a CCR
|
||||
stub naming the custody owner, not `autonomous`. `ADR-0003`: cover gaps, never
|
||||
silently own them; a permissive verdict on someone else's custody act is a
|
||||
silent claim of ownership.
|
||||
- Consider whether `rotation.steps` should be reachable from `plan` at all, given
|
||||
they are advisory prose and several are explicitly not automatable.
|
||||
- Regression from the reproduced case, in the manner of T06.
|
||||
|
||||
## Open question for design
|
||||
|
||||
Whether intent belongs in the matcher or in the lane. A lane could declare which
|
||||
acts it admits (`read`, `rotate`, `provision`) and `plan` could refuse any act a
|
||||
lane does not declare — stricter, and it fails closed on lanes that say nothing,
|
||||
which is the majority today. That is a catalog schema change and needs its own
|
||||
argument.
|
||||
|
||||
## Confirmed independently, then fixed — 2026-09-09
|
||||
|
||||
`railiance-platform` hit the same defect from the other side while answering the
|
||||
Qonto custody routing question (msg `7c7228ac`). Having stated that the correct
|
||||
verdict is `founder_required` — attended OIDC via `netkingdom` `role=platform-admin`,
|
||||
through the governed `openbao-platform-admin-login` lane — they added:
|
||||
|
||||
> Note this is the same verdict your `warden plan` should have returned; it
|
||||
> returning `autonomous` and offering read transports for a write is a real
|
||||
> defect and WARDEN-WP-0038 is the right place for it. Until that is fixed, do
|
||||
> not let a plan result stand in for this answer.
|
||||
|
||||
Two counterparties reporting the same wrong verdict in two days, one of whom is
|
||||
the write authority being wrongly bypassed, moved this from proposed to shipped.
|
||||
|
||||
### What shipped
|
||||
|
||||
`_need_intent()` classifies a need as `mutate` or `read` by token match, and
|
||||
`_owns_write_authority()` tests `delegation.mode == "permanent"`. A mutating need
|
||||
on a lane ops-warden does not permanently own can no longer reach any branch that
|
||||
returns `autonomous`:
|
||||
|
||||
- lane declares a `rotation` → `founder_required`, with an `approve` act naming
|
||||
the write owner, the rotation method, whether it is automatable, and
|
||||
`warden rotate-guide` as guidance;
|
||||
- lane declares none → `unroutable` with a CCR stub whose `owner_hint` names the
|
||||
write authority.
|
||||
|
||||
**Commands are empty of read transports either way.** That is the half that made
|
||||
the wrong verdict actionable rather than merely wrong: `--out`, `--exec`,
|
||||
`--wrap` and a bare `bao kv get` were being offered as the answer to a write, and
|
||||
a test now asserts none of them appears.
|
||||
|
||||
### The design question in the plan, answered by use
|
||||
|
||||
The plan asked whether intent belongs in the matcher or in the lane. It went in
|
||||
the matcher, with the *ownership* test doing the work that a verb list cannot:
|
||||
SSH certificate issuance is itself a mutating act, and `warden sign` must stay
|
||||
`autonomous`. `delegation.mode: permanent` is what separates ops-warden's own
|
||||
front door from someone else's custody — not the absence of a verb from a list.
|
||||
A regression asserts the SSH lane still proceeds, because a guard that refuses
|
||||
our own lane would be a worse defect than the one it fixes.
|
||||
|
||||
The stricter alternative — lanes declaring which acts they admit, `plan` refusing
|
||||
anything undeclared — is not built. It is a catalog schema change that would fail
|
||||
closed on the majority of lanes, which say nothing today, and it needs its own
|
||||
argument rather than arriving as a side effect of this fix.
|
||||
|
||||
## Recognize explicit attended OpenBao platform administration
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0038-T01
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
2026-10-16 source follow-up: the exact request "attended OpenBao platform
|
||||
administration for reviewed flex-auth signer custody CAS0 and fixed KV metadata"
|
||||
fell through to keyword ranking and selected `openbao-structure-survey` /
|
||||
`approve`. The configuration override required policy/auth-role nouns even
|
||||
though the caller explicitly named attended platform administration. Recognize
|
||||
that explicit intent before keyword ranking. The plan now selects
|
||||
`openbao-platform-admin-login` / `founder_required` / `oidc_login`; the governed
|
||||
reviewed-command transport and identity gate are unchanged. Survey requests
|
||||
remain metadata-only, and a missing administration lane stays unroutable.
|
||||
|
||||
Prepared and tested in an isolated checkout for independent review. This task
|
||||
records source repair only; it neither authorizes nor claims installation,
|
||||
attended login, signer provisioning or full16TSA native acceptance. Integration
|
||||
and the existing platform custody work retain those next actions.
|
||||
|
||||
### Not claimed
|
||||
|
||||
This narrows what `warden plan` will assert; it does not make the tool an
|
||||
authority on custody. railiance-platform's instruction stands and is the right
|
||||
standing posture: a plan result does not substitute for the owner's answer.
|
||||
|
|
@ -0,0 +1,159 @@
|
|||
---
|
||||
id: WARDEN-WP-0039
|
||||
type: workplan
|
||||
title: "Preserve explicit policy caller refusals before credential and CA effects"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: finished
|
||||
flavor: residual
|
||||
owner: codex
|
||||
topic_slug: custodian
|
||||
created: "2026-09-08"
|
||||
updated: "2026-10-03"
|
||||
origin: residual
|
||||
origin_ref: HFACT-WP-0001
|
||||
state_hub_workstream_id: "ae44a935-6fca-514c-a385-4550dd2b1fe8"
|
||||
---
|
||||
|
||||
The factory critical-path review reproduced a live HTTP 403 from the reachable
|
||||
PDP for the configured ops-warden caller and a railiance-platform secret read.
|
||||
`check_fetch_policy` treated it as evaluator unavailability and used unknown-zone
|
||||
fail-open. Caller-auth rejection is an explicit refusal, not a transport outage.
|
||||
|
||||
## Preserve explicit authentication and binding refusals
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0039-T01
|
||||
status: done
|
||||
flavor: residual
|
||||
priority: high
|
||||
assignee: the-custodian
|
||||
state_hub_task_id: "eaad08d9-ae47-5f50-8278-ea402a0e2869"
|
||||
```
|
||||
|
||||
HTTP 401 and 403 stop signing and credential fetch irrespective of the outage
|
||||
profile. Do not expose response bodies or alter system identity to bypass the
|
||||
refusal. Preserve configured behavior for genuine evaluator failures. Prove
|
||||
both permissive and closed outage profiles and refusal before child execution.
|
||||
|
||||
## Verify and publish the correction
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0039-T02
|
||||
status: done
|
||||
flavor: residual
|
||||
priority: high
|
||||
assignee: the-custodian
|
||||
state_hub_task_id: "ac85cf00-391c-5c63-b8f4-ed5bd57684e5"
|
||||
```
|
||||
|
||||
Run the policy and proxy suites, retain a value-free live refusal receipt,
|
||||
publish the reviewed source, and verify the installed CLI refuses before any
|
||||
credential transport. A refusal is not a successful credential-read admission.
|
||||
|
||||
The owner installer initially reused a cached wheel despite `--force`, leaving
|
||||
the pre-fix policy code installed. Both Makefile installation targets now use
|
||||
`--reinstall-package ops-warden` to refresh this package from the reviewed source.
|
||||
Verify the installed module as well as the checkout before the live refusal test.
|
||||
|
||||
## Resolve the credential proxy's admitted policy binding
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0039-T03
|
||||
status: done
|
||||
flavor: residual
|
||||
priority: high
|
||||
assignee: the-custodian
|
||||
state_hub_task_id: "8ca28b63-2e04-5333-b635-011b124c1806"
|
||||
```
|
||||
|
||||
Consume the existing native-lane handoff (WARDEN-WP-0033 / SECRETS-WP-0006)
|
||||
and flex-auth caller contract. Establish whether this interim transport needs an
|
||||
admitted dedicated policy route or must finish its native handoff. Retain the
|
||||
refusal until that contract yields positive and wrong-caller/owner/tenant
|
||||
negative evidence. No credential read, secret generation, or policy grant is
|
||||
authorized by this workplan alone. HFACT-WP-0001-T03 consumes this return.
|
||||
|
||||
Validation: 429 tests passed (4 integration tests deselected by the repository default); Ruff passed for changed Python files. Full tests used the declared phase-memory source and an isolated temporary memory store. The focused policy/proxy suite passed 69 tests. The existing authenticated SSH policy probe still returns HTTP 200/ALLOW, decision:f3f7c88f9585582a; the credential-owner request returns 403. No CA issue or credential read was performed by these probes.
|
||||
|
||||
Installed verification: source guard present after refreshed owner installation (`19bb75c`). `warden access forgejo-admin-api-token --exec --field API_TOKEN -- true` exits 4 with explicit HTTP 403 before credential transport or child execution. The previous fail-open warning is absent. The probe requested no output value; no credential was fetched. T01/T02 are complete; T03 owns the remaining exact policy-binding admission.
|
||||
|
||||
**T03 routed 2026-09-09.** Asked `flex-auth` whether an admitted contract exists
|
||||
for a delegated credential read where the caller (ops-warden) and the resource
|
||||
owner differ, since that is exactly the shape drawing the live 403. Three outcomes
|
||||
were named as equally acceptable answers, with no preference stated between the
|
||||
first two: an existing contract to conform to; no contract yet, making this a
|
||||
design question they should raise rather than one ops-warden invents a shape for;
|
||||
or that there should be **no** such contract — the interim proxy transport is
|
||||
itself the defect and the answer is to finish the native handoff
|
||||
(`WARDEN-WP-0033` / `SECRETS-WP-0006`).
|
||||
|
||||
The third is a real possibility and was not argued against. Eleven catalog lanes
|
||||
are ops-warden proxies with a named intended owner precisely because no owner
|
||||
front door exists; if delegated reads should not be made policy-admissible, that
|
||||
shortens WP-0033 rather than blocking it.
|
||||
|
||||
Two fixes were explicitly ruled out in the message rather than left unmentioned:
|
||||
broadening the ops-warden caller binding so it may read other systems' resources,
|
||||
and relabelling `resource.system` as ops-warden so the existing binding matches.
|
||||
The second is worse — it would make the audit trail assert ops-warden owns
|
||||
credentials it deliberately does not, which is the claim `ADR-0002` exists to
|
||||
prevent, achieved by editing a field instead of making an argument.
|
||||
|
||||
The refusal stays in place until an answer yields positive evidence plus
|
||||
wrong-caller, wrong-owner and wrong-tenant negatives. No grant was requested.
|
||||
`secrets-engine` was told this bears on SECRETS-WP-0007-T04 and on how many lanes
|
||||
stay proxied; `gate-house` was told it may reach how the signing lane's
|
||||
approval-consume is built (GH-DEC-2026-005).
|
||||
|
||||
### 2026-09-28 loose-end review
|
||||
|
||||
T03 remains wait and the workplan remains blocked. Re-read the owner's finished
|
||||
FLEX-WP-0026: no admitted delegated-read binding exists, and its native OpenRouter
|
||||
contract explicitly does not close WARDEN-WP-0039-T03. FLEX-DEC-2026-015 also
|
||||
confirms resource.system is runtime policy vocabulary, not a repository rename.
|
||||
Retain the explicit refusal. A native owner route's success does not grant this
|
||||
interim proxy general delegated-read authority; exact positive and caller/owner/
|
||||
tenant negative evidence is still required for the route that replaces it.
|
||||
|
||||
**T03 code side done 2026-10-03 (CUST-WP-0075, founder build-mode directive).**
|
||||
access-engine answered the contract question with a dedicated fetch evaluator:
|
||||
pin `flex-auth-ops-warden-fetch` (access-engine 02b15a7, `values/ops-warden-fetch.yaml`),
|
||||
same caller (ops-warden SA, audience flex-auth), owner systems bound per lane,
|
||||
request shape unchanged. ops-warden now sends `check_fetch_policy` only to the new
|
||||
key `policy.fetch_flex_auth_url`; signing keeps `policy.flex_auth_url`. An unset or
|
||||
unreachable fetch evaluator fails closed with a message naming it, with no fallback
|
||||
to the signing pin and no fail-open. 401/403 keep the existing refusal text.
|
||||
`warden access <need>` names the fetch evaluator on its `gate` (or `policy`) line. Tests:
|
||||
`tests/test_policy_fetch_evaluator.py`, plus updated proxy and refusal tests. Full
|
||||
suite: 494 passed, 4 deselected. Docs: `wiki/OpsWardenConfig.md` ("Two
|
||||
evaluators", tunnel example), `wiki/CredentialRouting.md`, production example.
|
||||
|
||||
Still open (founder go, `needs_human`): deploy the pin (access-engine
|
||||
ADHOC-2026-10-03-T02), add the ops-bridge tunnel (local 19091 → the pin's Service
|
||||
ClusterIP:8080), set `fetch_flex_auth_url: http://127.0.0.1:19091` in the live
|
||||
`~/.config/warden/warden.yaml`, then record exact positive evidence and
|
||||
wrong-owner/caller negative evidence before T03 closes. Until the key is set,
|
||||
every proxied fetch refuses with "secret-read evaluator not configured". Before
|
||||
that change, those fetches got a 403 from the signing pin.
|
||||
|
||||
**T03 done 2026-10-10.** access-engine reported the fetch pin
|
||||
`flex-auth-ops-warden-fetch` live since 2026-10-03 (Helm revision 1). The tunnel
|
||||
`flex-auth-ops-warden-fetch-railiance01` (127.0.0.1:19091) is connected, and the
|
||||
live `~/.config/warden/warden.yaml` carries
|
||||
`fetch_flex_auth_url: http://127.0.0.1:19091`. Receipts were taken with
|
||||
ops-warden's own caller token (SA `ops-warden/ops-warden`, audience
|
||||
`flex-auth`, 10m). The requests are access-engine's fixtures in
|
||||
`examples/ops-warden-fetch/`. Policy decisions only; no credential was read.
|
||||
|
||||
| Case | Result |
|
||||
| --- | --- |
|
||||
| Positive: `forgejo-admin-api-token`, owner railiance-platform | HTTP 200 allow `secret_read_lane_matched`, `decision:014afa428f776db5` |
|
||||
| Unknown need | HTTP 200 deny `unknown_need`, `decision:d792b0d6b1cb8122` |
|
||||
| Wrong owner: `resource.system` ops-warden | HTTP 403 |
|
||||
| Wrong tenant: `tenant:binky` on subject and resource | HTTP 200 deny `wrong_tenant`, `decision:71da3ff8b50dad74` |
|
||||
| Wrong caller: anonymous | HTTP 401 |
|
||||
|
||||
This is the exact positive evidence plus the caller, owner and tenant negatives
|
||||
this task required. The explicit refusal stays for anything the pin does not
|
||||
admit. access-engine closes its ADHOC-2026-10-03-T02 on this reply.
|
||||
|
|
@ -0,0 +1,240 @@
|
|||
---
|
||||
id: WARDEN-WP-0040
|
||||
type: workplan
|
||||
title: "Adopt unknown -> fail_closed behind signing-target classification coverage"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: active
|
||||
flavor: residual
|
||||
depends_on:
|
||||
- WARDEN-WP-0032
|
||||
- WARDEN-WP-0034
|
||||
owner: ops-warden
|
||||
topic_slug: netkingdom
|
||||
planning_priority: P1
|
||||
depends_on_workplans:
|
||||
- WARDEN-WP-0032
|
||||
- WARDEN-WP-0034
|
||||
created: "2026-09-09"
|
||||
updated: "2026-09-28"
|
||||
state_hub_workstream_id: "c8ee441e-1be1-5219-910c-e79ff23cc9ec"
|
||||
---
|
||||
|
||||
# WARDEN-WP-0040 — `unknown` → `fail_closed`, in the right order
|
||||
|
||||
security-layer-model v0.8 §6.4 obligation 3 (proposed, 2026-09-06) rules that
|
||||
`unknown` is not a zone and must resolve to `fail_closed`. ops-warden's
|
||||
`pep-stance.yaml` declares `unknown: fail_open` under `ADR-0009`.
|
||||
|
||||
**We agree with the rule.** `history/2026-09-09-layer-model-v08-review.md` records
|
||||
the assent and why our falsifier check failed: the cell governs certificate
|
||||
issuance, not a §5.1 read-only diagnostic, so nothing rescues it.
|
||||
|
||||
**We disagree with adopting it first.** Measured 2026-09-09: of four signing
|
||||
targets, zero resolve to a zone, three are `unknown`, one is `not-applicable`.
|
||||
Flipping the cell today makes flex-auth a hard dependency of essentially every
|
||||
certificate — `ADR-0006`'s rejected configuration, reached by a different route,
|
||||
including the continuity path needed to repair flex-auth itself.
|
||||
|
||||
So: coverage first, then the cell. That ordering is the whole holding of
|
||||
`ADR-0006` and the reason `ADR-0009` replaced a global switch with a zone map.
|
||||
|
||||
## Tasks
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0040-T01
|
||||
status: wait
|
||||
blocked_on: message-from:ops-bridge
|
||||
blocking_reason: "Warden's own declaration cannot classify the repair-path target workloads; the owner must declare the continuity actor/target and its z2-continuity resolution (see 2026-09-28 review)."
|
||||
priority: high
|
||||
state_hub_task_id: "611f0901-9fb5-5954-8dd0-a860c5f0cbec"
|
||||
```
|
||||
2026-09-30: gate stated. The 2026-09-28 review found the classification is not ours to make (target workloads belong to ops-bridge, the Inter-Hub execution owner and the backup owner), so T01 waits on the owner declaration, same as T02. Qualified per Task Wait Qualifiers v0.1.
|
||||
|
||||
|
||||
**Classify the continuity path before anything else changes.**
|
||||
|
||||
The deadlock is specific and worth naming before it is designed around: flex-auth
|
||||
unreachable → operator needs an SSH certificate to reach the host → target is
|
||||
`unknown` because nobody classified the repair path → `fail_closed` denies it.
|
||||
|
||||
`z2-continuity` exists for this and its stance is `fail_open`, so the fix is
|
||||
classification, not an exception. Determine which actor(s) constitute the
|
||||
repair path, establish whether the declaration is ops-warden's to make (our own
|
||||
`tenancy.yaml` covers ops-warden as a workload; the actors' target workloads may
|
||||
not be ours), and route what is not.
|
||||
|
||||
Blocks T03. Converting the cell with the repair path unclassified is the one
|
||||
outcome this workplan exists to prevent.
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0040-T02
|
||||
status: wait
|
||||
blocked_on: message-from:ops-bridge
|
||||
blocking_reason: "Owners of agt-codex-interhub-bootstrap (ops-hub) and agt-state-hub-bridge (ops-bridge) must publish authoritative workload identity declarations; atm-backup-daily declared by activity-core and compiled 2026-10-09 (z2-protected, admission unsatisfied: M1 below M2 floor)."
|
||||
priority: high
|
||||
state_hub_task_id: "54ad4864-7bcf-592e-a187-9239a81a0b11"
|
||||
```
|
||||
|
||||
**Raise signing-target coverage, by asking owners — never by inferring.**
|
||||
|
||||
Three actor resources report `workload_resolution_absent`:
|
||||
`agt-codex-interhub-bootstrap`, `agt-state-hub-bridge`, `atm-backup-daily`.
|
||||
Their owners (ops-bridge and the backup execution unit among them) have not
|
||||
published an authoritative workload identity declaration.
|
||||
|
||||
`ADR-0009` rule 3 forbids closing this with path or repository-name inference,
|
||||
and that prohibition holds under pressure from this workplan specifically —
|
||||
adopting a stricter stance is not a licence to manufacture the membership that
|
||||
makes it survivable.
|
||||
|
||||
Route to each owner with the concrete consequence: while the declaration is
|
||||
absent their actor cannot be issued a certificate during a flex-auth outage once
|
||||
the cell converts. That is a better ask than a generic request to publish a
|
||||
declaration, and it is true.
|
||||
|
||||
Report coverage with `scripts/report_workload_join.py`; this task is done when
|
||||
coverage is stated, not when it reaches a threshold — the threshold is T03's
|
||||
gate, and owners may legitimately decline.
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0040-T03
|
||||
status: wait
|
||||
depends_on: [WARDEN-WP-0040-T01]
|
||||
blocking_reason: "Gated on T01 and on layer model v0.8 (or successor) reaching accepted; never convert against a proposed standard."
|
||||
priority: high
|
||||
state_hub_task_id: "93eaf1f2-daaa-5e22-8804-85ca9433571c"
|
||||
```
|
||||
|
||||
**Convert the cell and supersede `ADR-0009`'s unknown row.**
|
||||
|
||||
Gated on T01, and on v0.8 (or its successor) reaching `accepted`. Do not convert
|
||||
against a `proposed` standard.
|
||||
|
||||
`ADR-0009` is `owner: ops-warden`, so changing it means a superseding ADR, never
|
||||
an in-place edit (`.claude/rules/architecture.md`). The superseding record should
|
||||
carry the v0.8 argument rather than restate it: unknown is not a zone, so a §9.3
|
||||
per-zone trade was never made for that request.
|
||||
|
||||
`pep-stance.yaml` is asserted equal to `PolicyConfig.failure_modes` by
|
||||
`tests/test_layer_conformance.py`, so the map and the code convert in one commit
|
||||
or the test fails — which is the property that makes the map worth publishing.
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0040-T04
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "222a8c5d-0c0f-5a1d-98d8-02be7dca3358"
|
||||
```
|
||||
|
||||
**Return findings to gate-house and track the transition ask.**
|
||||
|
||||
Sent 2026-09-09 with the review. Two asks, in preference order: obligation 3
|
||||
names a dated transitional state gated on coverage; or failing that, §13.1
|
||||
records classification coverage alongside stance, so a register row cannot read
|
||||
`unknown: fail_closed` while every target is unknown.
|
||||
|
||||
If both are declined, that is an answer and this workplan proceeds unchanged —
|
||||
the cell stays a **declared gap** under §11 with this workplan as its route,
|
||||
which is what the `declared-gap` mark (our own v0.6 finding) exists to express.
|
||||
|
||||
**Answered 2026-09-09 — GH-DEC-2026-011.** Ask 1 declined, ask 2 adopted;
|
||||
standard amended at `net-kingdom@64394e9`.
|
||||
|
||||
Ask 1's refusal is correct and we are not appealing it: a sanctioned transitional
|
||||
`fail_open` is indistinguishable at runtime from the stance the rule forbids, and
|
||||
would make the rule optional at the only moment it costs anything. Ask 2 gave us
|
||||
what we actually needed — §13.1 carries a Coverage column with this repo's
|
||||
figures as its first entries, guarded so that coverage never softens a stance,
|
||||
never gates one, and never makes a non-conformant cell conformant.
|
||||
|
||||
The reversal condition on that column binds ops-warden first, since the column
|
||||
exists because we asked: if a row is ever argued conformant *because* its coverage
|
||||
is low, the column comes out. Our row reads non-conformant and low-coverage, and
|
||||
the second is not a defence of the first.
|
||||
|
||||
gate-house confirmed explicitly that they are **not** asking for the cell to be
|
||||
flipped before coverage exists, and that this workplan's order is right. The cell
|
||||
stays a declared gap under §11 with WP-0040 recorded as its route — the outcome
|
||||
this task named as acceptable if both asks were declined, reached with one of them
|
||||
adopted.
|
||||
|
||||
T01–T03 are unchanged and still gate the conversion. Coverage is now measured
|
||||
rather than asserted (`scripts/report_coverage.py`), so T02's reporting obligation
|
||||
has a tool behind it and the published figure cannot drift from the register's.
|
||||
|
||||
### 2026-09-28 loose-end review
|
||||
|
||||
T04 is done: GH-DEC-2026-011 already answered both transition asks on September 9;
|
||||
the accepted coverage column and declared-gap disposition are recorded above.
|
||||
No additional response is required to meet that task's acceptance criterion.
|
||||
|
||||
T01/T02 now wait; the workplan is blocked. Re-ran both coverage reports:
|
||||
signing targets = 0 resolved / 3 unknown / 1 not-applicable; routing lanes =
|
||||
3 resolved / 20 unknown / 15 not-applicable. Refreshed pep-stance.yaml's measured
|
||||
date. These figures describe the checked-in registry and local owner declarations,
|
||||
not a live PDP query. No zone membership was inferred or changed.
|
||||
|
||||
The exact missing workload resolutions are `ops-bridge-tunnel` for
|
||||
`agt-state-hub-bridge`, `codex-interhub-bootstrap` for
|
||||
`agt-codex-interhub-bootstrap`, and `backup-daily` for `atm-backup-daily`.
|
||||
The seed inventory's `adm-example` is not an admitted repair actor.
|
||||
Warden's own workload declaration cannot classify those target workloads.
|
||||
T01 needs an owner-declared continuity actor/target and its authoritative
|
||||
z2-continuity resolution; T02 retains the owner-routing/declaration follow-up
|
||||
(ops-bridge, the Inter-Hub execution owner and the backup execution owner).
|
||||
Without it, changing unknown to fail_closed would deny their issuance during a
|
||||
PDP outage. Coverage reporting is complete, but owner coordination is not.
|
||||
|
||||
T03 also remains gated on standard acceptance: the local authoritative
|
||||
net-kingdom/canon/standards/security-layer-model_v0.8.md still says proposed.
|
||||
No superseding ADR or runtime stance change is warranted before these gates.
|
||||
|
||||
### 2026-09-30 owner asks sent
|
||||
|
||||
Routed the concrete-consequence ask (T01 classification + T02 declaration) to `ops-bridge` (agt-state-hub-bridge), `ops-hub` (agt-codex-interhub-bootstrap; owner unconfirmed, asked to name the owner if not theirs) and `railiance-platform` (atm-backup-daily; same caveat). Declining is an accepted answer. No membership inferred. T01/T02 stay `wait` on these replies.
|
||||
|
||||
### 2026-10-08 owner replies recorded
|
||||
|
||||
`atm-backup-daily`: railiance-platform declined in its replies of 2026-10-02
|
||||
(msgs 53234ede, a3691df9). It declares only the credential lane
|
||||
`railiance-backup-offsite-lane`, and no workload in railiance-platform has that
|
||||
name. It names activity-core as the declaring owner, because activity-core is
|
||||
the source repo of `daily-cnpg-option-a-backup`. It classifies the actor as
|
||||
**ordinary**, not z2-continuity repair-path. activity-core will not declare
|
||||
without founder confirmation (ACTIVITY-WP-0042-T03, decision 89f1058f). So this
|
||||
actor now waits on that founder decision, not on railiance-platform. No
|
||||
membership is inferred. `agt-state-hub-bridge` (ops-bridge) and
|
||||
`agt-codex-interhub-bootstrap` (ops-hub) are still unanswered.
|
||||
|
||||
2026-10-08 (later): the founder confirmed in session that activity-core's
|
||||
`daily-cnpg-option-a-backup` worker is the `atm-backup-daily` unit, and that it
|
||||
is classed as ordinary. The confirmation was relayed to activity-core for
|
||||
ACTIVITY-WP-0042-T03. Decision 89f1058f (D2) was deliberately left open,
|
||||
because it also gates production ArgoCD go-aheads. `atm-backup-daily` now waits
|
||||
only on activity-core publishing its declaration.
|
||||
|
||||
### 2026-10-09 atm-backup-daily compiled
|
||||
|
||||
activity-core published `declarations/backup-daily/tenancy.yaml` (c1533fe).
|
||||
zone-engine's `resolve_zones.py` resolves it with the
|
||||
`netkingdom-build-v0.1` profile:
|
||||
|
||||
- declared zone: `z2-protected` (ordinary, not z2-continuity)
|
||||
- admission: `unsatisfied`, reason `M1_below_M2_zone_floor`
|
||||
- effective zone: `unknown`
|
||||
|
||||
The resolved view is committed as `registry/flex-auth/zone-resolutions.json`,
|
||||
and the snapshot was rebuilt from it. Resolution is no longer absent. The actor
|
||||
stays `unknown` because the owner declared M1, below the M2 floor, which is
|
||||
accurate rather than a gap ops-warden may close. Coverage, stated as T02
|
||||
requires: signing targets 0/3 resolved, 3 unknown, 1 not-applicable. The
|
||||
figure is unchanged because `report_coverage.py` counts effective zones.
|
||||
`atm-backup-daily` now waits on owner M2 evidence. It does not wait on a
|
||||
declaration. Still unanswered: `agt-state-hub-bridge` (ops-bridge) and
|
||||
`agt-codex-interhub-bootstrap` (ops-hub).
|
||||
|
||||
> 2026-10-11: demoted to `flavor: residual` / `backlog` by founder-authorized triage — off the
|
||||
> critical path (identity → authz → secrets → SecurityCase execution). Tasks are unchanged;
|
||||
> promote back when demand or risk appears. See the-custodian
|
||||
> `history/20261011-netkingdom-security-progress-assessment.md`.
|
||||
|
|
@ -0,0 +1,100 @@
|
|||
---
|
||||
id: WARDEN-WP-0041
|
||||
type: workplan
|
||||
title: "Draft catalog lane scaffolding with platform-owned credential rendering"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: finished
|
||||
flavor: implementation
|
||||
owner: ops-warden
|
||||
topic_slug: netkingdom
|
||||
created: "2026-10-03"
|
||||
updated: "2026-10-04"
|
||||
depends_on: []
|
||||
state_hub_workstream_id: "eb42b59c-1e32-5e1b-917d-34625f7a041d"
|
||||
---
|
||||
|
||||
Accepts the ops-warden portion of P4 from CUST-WP-0075, proposal message
|
||||
`79549660-4fc8-44d5-989e-074f6c7b6f07`. The platform owns its renderer and
|
||||
CCR schema; no production act or approval is included here.
|
||||
|
||||
## Establish the catalog and platform seam
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0041-T01
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "85bfd209-d2f1-59e4-aa02-e8e374598538"
|
||||
```
|
||||
|
||||
Reviewed existing catalog validation, plan CCR stub, promotion checklist and
|
||||
platform CCR rendering. The stub does not scaffold; platform rendering already
|
||||
exists for reviewed CCRs. Proposed exact owner seam, inputs, fail-safe draft
|
||||
outputs and offline acceptance in `wiki/CatalogLaneScaffoldContract.md`.
|
||||
Platform's matching owner task is `RPF-WP-0050-T04`.
|
||||
|
||||
## Implement offline draft catalog and playbook generation
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0041-T02
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "68bf72d8-a798-5e88-bfda-79b8910f7cda"
|
||||
```
|
||||
|
||||
Implement the ops-warden portion of the seam proposal: deterministic staging
|
||||
output, validated catalog fields, draft-only defaults, collision refusal,
|
||||
explicit workload unknowns and risk, no secret inputs, no credential execution.
|
||||
Add meaningful rejection/round-trip fixtures; reuse catalog validation. Do not
|
||||
write platform-owned artifacts or invent its CLI. The local fragment generator
|
||||
can progress independently while platform contract review is pending.
|
||||
|
||||
## Verify the accepted cross-owner scaffold
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0041-T03
|
||||
status: done
|
||||
priority: medium
|
||||
depends_on:
|
||||
- WARDEN-WP-0041-T02
|
||||
- RPF-WP-0050-T04
|
||||
state_hub_task_id: "33587361-2b8a-5540-9c4f-d7b4f8ef25e0"
|
||||
```
|
||||
|
||||
Integrate through reviewed owner references and demonstrate one exact KV-v2
|
||||
workload-read fixture end to end. Record both owner commits and validation
|
||||
results. Generation success alone does not admit or activate a lane. Update
|
||||
`warden plan`'s unroutable guidance only once a real supported command exists.
|
||||
|
||||
## Report owner uptake and gates
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0041-T04
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "4bc926af-04d4-5a27-9578-d2f83c0ecf9c"
|
||||
```
|
||||
|
||||
Return the scoped P4 acceptance and this live owner record to the-custodian's
|
||||
original proposal thread. Existing admission, approval, identity confirmation,
|
||||
attended values and deployment evidence gates remain; no secret read or
|
||||
production action was taken. Source/knowledge receipt is in the seam document.
|
||||
|
||||
## Offline delivery acceptance — 2026-10-04
|
||||
|
||||
T02 and T03 completed the bounded draft-generation scope. Actual-source
|
||||
generator/routing/plan tests: 139 passed. Both actual owner CLIs staged the
|
||||
paired synthetic fixture; lane/consumer/owner/risk/CCR pointer and manifest
|
||||
digest match, unknown workload remains unknown, catalog execution is disabled,
|
||||
CCR remains proposed with empty review, auth claims unconfirmed, frontdoor
|
||||
pending/unresolvable and evidence not executed. Independent platform owner
|
||||
verification remains separately attributed in the receipt.
|
||||
|
||||
Source implementation commits: ops-warden `dfe436e4e05610cae96085dadd582e5a63525580`;
|
||||
railiance-platform `f5b7ff5118326f66be8ecd8330d4cda9e4d94520`.
|
||||
Evidence: `docs/evidence/2026-10-04-catalog-scaffold.json`.
|
||||
`warden plan` now names the supported offline command for unroutable needs.
|
||||
The workplan finishes its local draft scaffold contract; CCR approval, binding
|
||||
confirmation, attended values, deployment and actual capability receipts
|
||||
remain separate lane-activation work, never implied by fixture acceptance.
|
||||
No unfinished in-scope implementation or residual is parked by this closure.
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
---
|
||||
id: WARDEN-WP-0042
|
||||
type: workplan
|
||||
title: "Route the OpenBao existing-structure survey to ops-mason"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: finished
|
||||
flavor: implementation
|
||||
owner: claude
|
||||
topic_slug: netkingdom
|
||||
created: "2026-10-05"
|
||||
updated: "2026-10-05"
|
||||
depends_on: []
|
||||
state_hub_workstream_id: "bd5edebd-2988-5685-881e-13931464f92f"
|
||||
---
|
||||
|
||||
ops-mason construction plans need an existing-structure survey (section 2)
|
||||
built from live OpenBao metadata. Founder decision: ops-warden routes,
|
||||
ops-mason surveys. ops-mason implements `scripts/plan-survey.py` under its
|
||||
own `ops-mason-build` grant (`ops-mason/MASON-WP-0008`). ops-warden gets no
|
||||
survey code and no token, per the no-double-source rule
|
||||
(`WARDEN-WP-0010`, `docs/adr/ADR-0001-catalog-is-a-pointer-layer.md`).
|
||||
|
||||
## Add the pointer-only catalog entry
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0042-T01
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "ca8cd3e9-83ac-5732-8ec4-525e5ce1b113"
|
||||
```
|
||||
|
||||
`registry/routing/catalog.yaml` entry `openbao-structure-survey`: owner
|
||||
`ops-mason`, `warden_executes: false`, `exec_capable: false`, no `steps`,
|
||||
native delegation to ops-mason, lane `ceremony` (the grant is a founder act),
|
||||
`risk: high` (the grant can write policies and auth roles), `auth_method`
|
||||
naming the ops-mason grant, `exec_owner`/`exec_command` pointing at the
|
||||
survey script, `canon_ref` at `ops-mason/docs/construction-plan-format.md`.
|
||||
Short pointer playbook `wiki/playbooks/openbao-structure-survey.md`.
|
||||
|
||||
## Verify routing offline
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0042-T02
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "05bb75bd-2de9-55d5-8bc8-41b306ddcf16"
|
||||
```
|
||||
|
||||
`make test` passes, including catalog validation and layer conformance.
|
||||
`warden access "openbao structure survey"`, `warden access "construction
|
||||
plan section 2"` and `warden route find "existing policies auth roles
|
||||
survey"` resolve to the entry; `warden plan` returns `founder_required`
|
||||
with the survey command; `warden access ... --exec` refuses (not
|
||||
exec_capable).
|
||||
|
|
@ -0,0 +1,113 @@
|
|||
---
|
||||
id: WARDEN-WP-0043
|
||||
type: workplan
|
||||
title: "Route supplier credentials under platform/suppliers"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: finished
|
||||
flavor: implementation
|
||||
owner: grok
|
||||
topic_slug: platform-suppliers
|
||||
created: "2026-10-08"
|
||||
updated: "2026-10-09"
|
||||
depends_on: []
|
||||
related:
|
||||
- repo:railiance-platform
|
||||
- repo:llm-connect
|
||||
state_hub_workstream_id: "16aac061-977a-536b-a074-aba059f2475f"
|
||||
---
|
||||
|
||||
# WARDEN-WP-0043 — Supplier credentials under platform/suppliers
|
||||
|
||||
Founder decision 2026-10-08: account credentials we hold with a supplier
|
||||
live at `platform/suppliers/<supplier>/<account>` on the existing `platform`
|
||||
KV mount. ops-warden routes that shape. It does not store the values and it
|
||||
does not apply OpenBao. The KV write and the credential-change allowlist
|
||||
belong to railiance-platform. Tenant commercial secrets stay on `tenants/`.
|
||||
|
||||
Workload and rein paths that already have a reader stay where they are
|
||||
until that reader is retargeted:
|
||||
|
||||
| Account | Path today |
|
||||
| --- | --- |
|
||||
| OpenRouter, llm-connect | `platform/workloads/activity-core/llm-connect/llm-connect-provider-secrets` |
|
||||
| OpenRouter, rein-openweights | `reins/rein-openweights/openrouter` |
|
||||
| Scaleway bootstrap | `platform/workloads/railiance/scaleway/bootstrap` |
|
||||
| Scaleway backup space | `platform/workloads/railiance/backup/object-storage` |
|
||||
| IONOS transactional mailbox | `platform/workloads/email-connect/transactional` |
|
||||
| IONOS library mailbox | `platform/workloads/inbound-library/imap` |
|
||||
|
||||
The future homes are `platform/suppliers/openrouter/llm-connect`,
|
||||
`platform/suppliers/openrouter/rein-openweights`,
|
||||
`platform/suppliers/scaleway/bootstrap`, `platform/suppliers/scaleway/backup`,
|
||||
`platform/suppliers/ionos/email-connect-smtp`, and
|
||||
`platform/suppliers/ionos/library-imap`. Further suppliers use the same
|
||||
two-level shape. llm-connect already tries the llm-connect supplier path
|
||||
and then the live workload path before `OPENROUTER_API_KEY`.
|
||||
|
||||
## Catalog pointer
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0043-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "7a86d91a-fcbd-5dc8-b3cf-4c28ad963474"
|
||||
```
|
||||
|
||||
Add a pointer catalog entry and a short playbook for
|
||||
`platform/suppliers/<supplier>/<account>`. `warden_executes: false`. The
|
||||
owner of the KV write is railiance-platform. No secret values, no fetch
|
||||
of a live field, and no new `warden` verb.
|
||||
|
||||
Done 2026-10-08: catalog `platform-supplier-credentials` plus
|
||||
`wiki/playbooks/platform-supplier-credentials.md`.
|
||||
|
||||
## Allow the path in credential changes
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0043-T02
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "c384b228-e710-580d-a3de-a3046a86e666"
|
||||
```
|
||||
|
||||
`railiance-platform/scripts/credential-change.py` accepts `platform/workloads/`
|
||||
and `tenants/` for a delegated change. `platform/suppliers/` needs that
|
||||
allowlist widened before a CCR can create these paths. ops-warden does not
|
||||
apply the change.
|
||||
|
||||
Done 2026-10-09: railiance-platform `b77cb41` maps mount `platform` to
|
||||
`platform/workloads/` and `platform/suppliers/`. Under `suppliers/` it requires
|
||||
exactly two non-empty segments, and tests cover `platform/suppliers/ionos/main`.
|
||||
The IONOS CCR can now be drafted against this shape.
|
||||
|
||||
## Provision supplier accounts
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0043-T03
|
||||
status: done
|
||||
priority: medium
|
||||
needs_human: true
|
||||
state_hub_task_id: "87996bc7-2f7a-578d-9f7c-8bd876605a47"
|
||||
```
|
||||
|
||||
New supplier material is written from a mode-0600 file on a trusted
|
||||
terminal, into `platform/suppliers/<supplier>/<account>`. IONOS is the
|
||||
first account that still needs that home. Existing workload and rein
|
||||
readers keep their current paths until each one is retargeted. Values do
|
||||
not go into git, State Hub, workplans, logs, or chat.
|
||||
|
||||
2026-10-09: the IONOS stub exists. The founder ran the write through the
|
||||
contained `openbao-platform-admin-login` envelope:
|
||||
`bao kv put -cas=0 platform/suppliers/ionos/main` as version 1, with keys
|
||||
`CUSTOMER_NUMBER`, `LOGIN`, `PASSWORD`, `API_KEY_PREFIX` and `API_KEY_SECRET`,
|
||||
each set to the placeholder `FILL_ME`. A metadata-only check through the same
|
||||
envelope exited 0. The founder fills the real values as version 2 in the
|
||||
OpenBao UI. This task closes once that is done. No reader policy exists for the
|
||||
path; a reader is requested through a railiance-platform CCR when a workload
|
||||
needs it.
|
||||
|
||||
2026-10-09: done. The founder filled in the real values as version 2 through
|
||||
the OpenBao UI. ops-warden did not read or verify any value. Further supplier
|
||||
accounts follow the same playbook; existing workload and rein readers move only
|
||||
when each reader is retargeted.
|
||||
|
|
@ -0,0 +1,312 @@
|
|||
---
|
||||
id: WARDEN-WP-0044
|
||||
type: workplan
|
||||
title: "Follow through on KnownSecurityCases along their type's route"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: active
|
||||
flavor: implementation
|
||||
owner: claude-code
|
||||
topic_slug: netkingdom
|
||||
created: "2026-10-08"
|
||||
updated: "2026-10-11"
|
||||
depends_on: []
|
||||
related_repos:
|
||||
- net-kingdom
|
||||
- ops-mason
|
||||
- key-cape
|
||||
- railiance-platform
|
||||
state_hub_workstream_id: "f7e81013-6868-5d99-8528-ba75a442eca9"
|
||||
---
|
||||
|
||||
# WARDEN-WP-0044 — Follow through on KnownSecurityCases along their type's route
|
||||
|
||||
## Why
|
||||
|
||||
NetKingdom is introducing SecurityCaseTypes (net-kingdom `NK-WP-0048`, canon
|
||||
`security-case-types_v0.1`, proposed). Once a case of an implemented type is
|
||||
accepted and ops-mason has materialized its structure (`MASON-WP-0010`),
|
||||
ops-warden carries out the remaining steps. These are the owners' declared entry
|
||||
points, run on the authentication path the type defines, followed by the type's
|
||||
verification.
|
||||
|
||||
Today ops-warden routes needs and, for `exec_capable` lanes, proxies fetches as
|
||||
the caller. It does not yet know about cases, and each new integration ends with
|
||||
a founder running a hand-written script (for example the proposed KEY-WP-0038-T02
|
||||
rollout). This plan gives ops-warden the follow-through role, without widening
|
||||
what it may do: each step still runs under its owner's entry point and the
|
||||
caller's identity.
|
||||
|
||||
## Tasks
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0044-T01
|
||||
status: done
|
||||
depends_on: [NK-WP-0048-T03]
|
||||
priority: high
|
||||
state_hub_task_id: "ef0920fc-418e-52cb-acff-9a5c0c728bf5"
|
||||
```
|
||||
|
||||
### T01 — Define the type's follow-through section
|
||||
|
||||
Propose the `follow_through` part of the SecurityCaseType schema together with
|
||||
net-kingdom. For each step it names the owner entry point, `warden_executes`,
|
||||
the auth method and lane, whether an attended human login is unavoidable (with
|
||||
the type's justification), and the verification command. Write it for the first
|
||||
type, `oidc-browser-relying-party`, covering key-cape client registration,
|
||||
custody minting and LLDAP group membership.
|
||||
|
||||
2026-10-08: NK-WP-0048-T03/T04 landed with a drafted section. Review is in
|
||||
`history/2026-10-08-oidc-rp-follow-through-review.md`. It requires three
|
||||
changes before T02: a per-step `lane`, a narrow `warden_executes`, and
|
||||
`value_handling`. It also lists four refinements. This task is done when
|
||||
net-kingdom acknowledges the review (NK-WP-0048-T05).
|
||||
|
||||
2026-10-09: R4 was withdrawn in favour of ops-mason's per-case
|
||||
`{consuming_service}-keycape-client`, with the entry body templated in the type
|
||||
(R4′, see the addendum in the review).
|
||||
|
||||
2026-10-09: the revised 1.0 type and canon now carry R1–R3, R4′, R5–R7.
|
||||
`warden case check-type <type.yaml>` (`src/warden/case_type.py`, tests in
|
||||
`tests/test_case_type.py`) checks a type's follow-through mechanically: the
|
||||
live type is schema-conformant, with one attended session
|
||||
(`key-cape-oidc-login`). It is not yet plannable, because two lanes are not
|
||||
in the catalog: `identity-provisioner-groups` (net-kingdom) and
|
||||
`keycape-client-secret-generate` (railiance-platform). These gate T02, not
|
||||
T01. T01 still closes on net-kingdom's acknowledgement (NK-WP-0048-T05).
|
||||
|
||||
2026-10-09: ops-warden cannot add `identity-provisioner-groups` as the type
|
||||
declares it. The provisioner accepts only user-engine's runtime token and
|
||||
admits only user-engine pods, so no caller-identity path exists. R8 (review
|
||||
addendum) asks net-kingdom either to move `ensure-groups` into the existing
|
||||
attended session (recommended) or to give the provisioner an operator
|
||||
credential. `keycape-client-secret-generate` needs a generate-in-custody entry
|
||||
point from railiance-platform, and the broker does not have one yet. Both were
|
||||
sent to their owners.
|
||||
|
||||
2026-10-09: done. net-kingdom took R8 option 1, so `ensure-groups` runs attended
|
||||
in the `register-client` session and `identity-provisioner-groups` is dropped
|
||||
(net-kingdom `0e86f95`). The founder acknowledged the type with memo r4 (hub
|
||||
decision `e418263e`, NK-WP-0048-T05 done).
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0044-T02
|
||||
status: done
|
||||
depends_on: [WARDEN-WP-0044-T01]
|
||||
priority: high
|
||||
state_hub_task_id: "5f68c991-f490-58f8-a121-92f74073d272"
|
||||
```
|
||||
|
||||
### T02 — Plan a case run
|
||||
|
||||
`warden case plan <case.yaml>` checks that the case is accepted and materialized,
|
||||
resolves each step to its catalog entry and entry point, and prints the run:
|
||||
which steps warden executes, which run as the attended caller, what the
|
||||
verification is. No secret values; no execution.
|
||||
|
||||
Tests: refuse an unaccepted or unmaterialized case; refuse a step whose catalog
|
||||
entry is missing or not reviewed; show attended steps explicitly.
|
||||
|
||||
2026-10-09: done. `warden case plan <case.yaml> [--type] [--json]`
|
||||
(`src/warden/case_plan.py`, 14 tests in `tests/test_case_plan.py`). It refuses:
|
||||
- a case that is not `materialized`, or has no acceptance record
|
||||
- a type that is mismatched or not acknowledged
|
||||
- any `case check-type` finding, including a missing or unreviewed lane
|
||||
- undeclared, type-fixed or secret-sensitivity parameters
|
||||
- a placeholder the case does not set, or an unsupported `when`
|
||||
|
||||
It fills type defaults (`issuer`), evaluates `<param> == <value>` conditions,
|
||||
renders owner, entry point, auth and ready_check, groups attended steps per
|
||||
lane, and lists the applicable verification.
|
||||
|
||||
The live Forgejo case is correctly refused: it is `accepted`, not
|
||||
materialized. A materialized copy, with a stand-in lane for
|
||||
`keycape-client-secret-generate`, renders six steps: two attended steps plus
|
||||
`register-client` in one `key-cape-oidc-login` session, one warden step
|
||||
(`mint-secret`), and two owner steps. Seven checks follow.
|
||||
|
||||
Observation for net-kingdom (not blocking): `bind-env` runs before
|
||||
`register-client`, in type order. Its entry carries a literal
|
||||
`KEYCAPE_<CLIENT_ID>_CLIENT_SECRET`, which is not a `{param}` placeholder, so it
|
||||
reaches the plan unrendered.
|
||||
|
||||
2026-10-09 follow-up:
|
||||
- **Format specs.** `_render` supports net-kingdom's `{param:env}` spec (upper
|
||||
case, `-` as `_`, the same as `keycape-client.py env_name`) and refuses any
|
||||
other spec or `!conversion`.
|
||||
- **Case reference.** The plan prints `case-ref: <case_id>@sha256:<hex>` over the
|
||||
case file's exact bytes. This is the reference proposed to railiance-platform
|
||||
for `credential.py generate --case-ref` (RPF-WP-0054-T01); the broker
|
||||
re-derives it from the file.
|
||||
- 18 tests now.
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0044-T03
|
||||
status: progress
|
||||
depends_on: [WARDEN-WP-0044-T02, MASON-WP-0010-T03]
|
||||
blocking_reason: "Local durable execution kernel and injected failure harness implemented. Native acceptance still requires authenticated owner machine descriptors/adapters, actual Forgejo materialization receipt, contained session integration, ordered verification and first native run."
|
||||
priority: high
|
||||
state_hub_task_id: "bcbf6c91-2c04-5c16-ae8c-5d6c06fd6b89"
|
||||
```
|
||||
|
||||
### T03 — Run and verify a case
|
||||
|
||||
`warden case run <case.yaml>` executes the plan. Owner entry points run through
|
||||
the existing proxy as the caller; steps that need an attended login use the
|
||||
existing contained login envelope (silent command, session revoked afterwards),
|
||||
grouped into as few attended sessions as possible. Then it runs the type's
|
||||
verification and writes a receipt without values. `warden case rollback`
|
||||
reverses exactly this case's steps.
|
||||
|
||||
Acceptance: the Forgejo reference case (NK-WP-0048-T06) reaches `live` through
|
||||
this path, with no case-specific script.
|
||||
|
||||
2026-10-17: original-intent lookup/context interface for NK-WP-0048-T15, source
|
||||
and synthetic tests only. `src/warden/case_run.py`: `Executor.run` writes an
|
||||
`OriginalIntent` (schema `warden.case.original-intent.v1`: the dispatched run
|
||||
Invocation — attempt, step, owner, target, actor, principal, lane, all six pins,
|
||||
tenant, realm — plus admitted adapter source) in the same SQLite transaction as
|
||||
the pre-dispatch journal row. `Journal.original_intent(binding, current, source)`
|
||||
returns it after restart and refuses on a missing record or any
|
||||
pins/source/step/owner/target/actor/principal/lane/tenant/realm mismatch, before any
|
||||
journal write, so the step stays uncertain. An adapter's
|
||||
`reconcile_original(ReconcileContext(original, attempt))` receives the original
|
||||
intent separately from the new reconcile attempt. This is Warden's record of what
|
||||
it dispatched, not owner created-only provenance. Current Executor.admit leaves
|
||||
tenant/realm empty; the reserved coordinates establish no admitted provenance.
|
||||
Owner descriptors/adapters, contained session integration, Forgejo
|
||||
materialization and the native run remain open.
|
||||
|
||||
2026-10-17 source consistency follow-through: retained the additive intents table
|
||||
and reconcile_original callback and fixed four reproduced local defects: original
|
||||
actor mismatch, payload/SQL attempt-ID mismatch, orphan intent without its
|
||||
matching original running receipt, and arbitrary nonmetadata values accepted by
|
||||
the original-intent serializer. Exact bounded field validation, duplicate-free
|
||||
bounded decode and save-time intent/invocation/running-state equality now preserve
|
||||
the original receipt linkage before owner lookup. No new context store, native
|
||||
verifier, trust root, adapter activation or authority migration was introduced.
|
||||
|
||||
The actual canonical focused kernel and new consistency suite passes 54 checks;
|
||||
owner-installed Ruff check/format passes. The existing generated-data/synthetic
|
||||
owner fixture and a distinct interpreter prove source correspondence/refusal,
|
||||
not independent native custody or creation. Earlier comparison probes and failed
|
||||
preparation are retained. Current caller and fresh session/grant revocation checks
|
||||
remain required; original owner payload/revocation, exact native readback and
|
||||
created-only provenance still need independent authenticated owner admission.
|
||||
No JSON/SQL context, unknown tenant/realm, changed run-sheet or legacy missing
|
||||
intent supplies recovery, replay or undo authority. T03 remains progress and all
|
||||
native acceptance gates/statuses/dependencies/UUIDs remain unchanged. Evidence:
|
||||
Custodian original-context-compare-r2 and original-context-owner-followthrough-r3
|
||||
under docs/changes/netkingdom-target-2026-10-17/; publication/projection is separate.
|
||||
|
||||
Agreed with railiance-platform (RPF-WP-0054-T01, 2026-10-09):
|
||||
- `mint-secret` runs `credential.py generate --grant keycape/client-secret-generate
|
||||
--client-id <id> --case-ref <case-ref> --case-file <case.yaml>` as the caller's
|
||||
child process. The broker re-derives the case-ref and checks status and
|
||||
client_id.
|
||||
- warden refuses that step when `WARDEN_AGENT_ID` is set.
|
||||
|
||||
2026-10-10: railiance-platform implemented the command (RPF-WP-0054-T03). It is
|
||||
catalogued as draft `keycape-client-secret-generate`, with `exec_owner`
|
||||
railiance-platform and `exec_capable: false`. `warden case check-type` now
|
||||
reports the lane as LANE-UNREVIEWED rather than LANE-MISSING. Before it can be
|
||||
activated:
|
||||
- the founder binds the issuer policy to the operator OIDC role
|
||||
- key-cape confirms the secret format
|
||||
- the RPF-WP-0054-T05 probe passes
|
||||
|
||||
2026-10-10 (later):
|
||||
- **Broker lane.** The issuer role is bound (CCR-2026-0043) and the T05 probe
|
||||
passed (railiance-platform `21b8af3`). Only key-cape's format confirmation is
|
||||
left. The playbook now includes the issuer-role login, a 15m token with
|
||||
unlimited uses that `warden case run` must group with the attended session.
|
||||
- **Env spec.** net-kingdom adopted `{client_id:env}` as a 1.0 patch
|
||||
(`9a9b8e3`). The plan renders `KEYCAPE_FORGEJO_CLIENT_SECRET`.
|
||||
- **Forgejo case.** Rendered and built by ops-mason. It is not yet
|
||||
`materialized`: MASON-WP-0010-T03 waits on the railiance-platform CCRs and
|
||||
their founder apply.
|
||||
|
||||
2026-10-10: `keycape-client-secret-generate` activated on railiance-platform's
|
||||
go-ahead (message 20973a9c) after key-cape confirmed the format (4e0213b3).
|
||||
`warden case check-type` on the live type now reports `plannable=True`. The
|
||||
only thing T03 still waits on is the Forgejo case reaching `materialized`
|
||||
(MASON-WP-0010-T03).
|
||||
|
||||
2026-10-10: net-kingdom moved the type to 1.1 (`e2174ce`) and re-pinned the
|
||||
Forgejo case. 1.1 adds the verification `consumer-enforces-groups` and requires
|
||||
the hand-over to enforce `access_groups`. `check-type` on 1.1 reports
|
||||
`plannable=True`, and a materialized copy renders six steps and the new check.
|
||||
The case-ref digest covers the whole case file, including `status`, so it
|
||||
changes when the case becomes `materialized`. `warden case run` therefore takes
|
||||
it from the file at run time, and the broker re-derives it from the same file.
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0044-T04
|
||||
status: wait
|
||||
depends_on: [WARDEN-WP-0044-T03]
|
||||
blocking_reason: "Catalog integration follows a proven run."
|
||||
priority: medium
|
||||
state_hub_task_id: "4a0fa4a7-5ca9-518a-ab92-a79a5e2cf93e"
|
||||
```
|
||||
|
||||
### T04 — Catalog entries from types
|
||||
|
||||
Let a type contribute reviewed catalog entries once, so that every case of that
|
||||
type routes without a new catalog edit. Cases add parameter values, not routes.
|
||||
`warden route find` should be able to answer "which SecurityCaseType covers this
|
||||
need?" before anyone builds by hand.
|
||||
|
||||
|
||||
2026-10-10 consolidation source prototype (not an accepted owner adapter API):
|
||||
`src/warden/case_receipt_state.py` provides a pure immutable receipt reducer,
|
||||
with exact case/type/adapter/catalog/acceptance/run-sheet pins, running intent
|
||||
before dispatch, uncertain recovery after a lost result, no success replay,
|
||||
explicit retry-safe failed-before-change retry and created-only reverse undo.
|
||||
It executes nothing and accepts no command output. The caller must durably
|
||||
persist running before any future side effect; storage/authenticated owner
|
||||
receipts/live adapters are not implemented. Focused offline tests cover changed
|
||||
pins, lost receipts, retry/refusal, uncertain rollback and shared-object
|
||||
preservation. Source proposal: `docs/security-case-execution-proposal.md`.
|
||||
|
||||
T03 remains open: typed owner execution/receipt contracts require review, the
|
||||
Forgejo structural materialization needs owner receipts, and CLI dispatch,
|
||||
contained sessions, native verification and provenance remain unimplemented.
|
||||
There is a circularity to resolve with net-kingdom/ops-mason: materialization
|
||||
cannot require mint-secret if mint-secret is itself a follow-through step whose
|
||||
planning requires materialized. No case status is changed by this prototype.
|
||||
|
||||
|
||||
2026-10-11: the exact execution-design memo version1 has confirmed native human
|
||||
acceptance (approval e46b149b-ec3c-4b3b-98a7-dcb4934448ca). The approved proposal
|
||||
bytes remain unchanged. `src/warden/case_run.py` now implements a closed v1 local
|
||||
execution seam, independent admission/evidence callbacks, private transactional
|
||||
SQLite receipt storage, process locking, running-before-dispatch, crash recovery
|
||||
to uncertainty, explicit safe retry, separately required broker-grant and parent-session revocation
|
||||
proofs, native owner reconciliation and created-only
|
||||
reverse rollback. Thirty-seven kernel tests and fourteen reducer tests pass;
|
||||
ruff checks pass. See `docs/security-case-execution-kernel-v1.md` for exact scope
|
||||
and receipt provenance. No installed native adapter or live CLI execution is
|
||||
claimed. Current prose types stay plan-only; acknowledged descriptor/type machine
|
||||
seams and authenticated owner/caller receipts are still required. T03 progresses
|
||||
for implementation but cannot finish before ordered native Forgejo acceptance.
|
||||
|
||||
2026-10-16 source preparation (isolated checkout; no native acceptance):
|
||||
T03's browser parameter mismatch now has a producer-validator-backed projection
|
||||
in `case_inputs.py`, explicitly configured on the real Executor. Exact 1.1/1.2
|
||||
parameter definitions and all four reviewed producer modules are pinned; full case
|
||||
validation admits reviewed security-sensitive metadata while unknown/fixed/secret
|
||||
inputs and type/producer drift refuse. Only the reviewed descriptor target
|
||||
reaches the owner callback; no parameter journal payload is added. Actual
|
||||
Executor/producer tests cover positive versions and refusal/containment paths.
|
||||
Acknowledged machine descriptors, authenticated owner evidence, real Forgejo
|
||||
materialization and contained native sessions remain mandatory and unimplemented;
|
||||
T03 stays progress, T04 stays wait. No type or case status changed.
|
||||
|
||||
2026-10-16 producer source refresh: independently reviewed NetKingdom
|
||||
`015694ee414c802dc2ef1fa0120dfed610086e69` optional descriptor-map repair.
|
||||
Only the validator/evidence source pins change; exact parameter and transitive
|
||||
source identity remain enforced. Actual canonical producer, Executor and reducer
|
||||
suite passes 87 checks, including 14 new malformed-map integration cases; all
|
||||
four missing/changed modules still refuse. Review:
|
||||
`docs/reviews/2026-10-16-browser-producer-pin-refresh.md`. No adapter attestation,
|
||||
native acceptance, credential use or privileged dispatch. T03 remains progress.
|
||||
|
|
@ -0,0 +1,335 @@
|
|||
---
|
||||
id: WARDEN-WP-0001
|
||||
type: workplan
|
||||
title: "OpsWarden Initial Implementation"
|
||||
domain: custodian
|
||||
repo: ops-warden
|
||||
status: archived
|
||||
owner: Bernd
|
||||
topic_slug: custodian
|
||||
created: "2026-03-28"
|
||||
updated: "2026-03-28"
|
||||
state_hub_workstream_id: "c3118cc6-adfb-428c-a9c6-edd0ee152ae6"
|
||||
---
|
||||
|
||||
> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`).
|
||||
|
||||
# WARDEN-WP-0001 — OpsWarden Initial Implementation
|
||||
|
||||
> **Note:** This workplan is authored in `ops-bridge` because `ops-warden` does not yet exist.
|
||||
> Move it to `workplans/WARDEN-WP-0001-initial-implementation.md` in the new repo as the
|
||||
> first commit action.
|
||||
|
||||
**Scope:** Bootstrap the `ops-warden` repository and deliver a working `warden` CLI that
|
||||
implements the SSH CA and certificate lifecycle defined in `wiki/AccessManagementDirective.md`.
|
||||
|
||||
**Out of scope:** Vault HA/cluster setup, Ansible playbooks for host principal deployment
|
||||
(those live in `railiance-infra`), session recording, and SSO integration (trigger §6.2 of
|
||||
the directive when scale requires it).
|
||||
|
||||
---
|
||||
|
||||
## Goal
|
||||
|
||||
Create a new `ops-warden` repository that owns **credential issuance only** — the CA,
|
||||
certificate signing, actor identity registry, and scorecard tooling. Its sole public surface
|
||||
to sibling repos is a well-defined `cert_command` interface that any tool (principally
|
||||
`ops-bridge`) can call to obtain a short-lived, CA-signed SSH certificate for a named actor.
|
||||
|
||||
---
|
||||
|
||||
## Reference Documents
|
||||
|
||||
| Document | Location |
|
||||
|---|---|
|
||||
| AccessManagementDirective | `ops-bridge/wiki/AccessManagementDirective.md` |
|
||||
| ops-bridge SCOPE.md | `ops-bridge/SCOPE.md` |
|
||||
|
||||
---
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
ops-warden/
|
||||
├── SCOPE.md
|
||||
├── CLAUDE.md
|
||||
├── pyproject.toml
|
||||
├── src/warden/
|
||||
│ ├── cli.py # Typer CLI: sign / issue / status / inventory / scorecard
|
||||
│ ├── models.py # ActorType enum, CertSpec, CertRecord, PrincipalsInventory
|
||||
│ ├── ca.py # LocalCA backend (file-based, for dev / non-Vault)
|
||||
│ ├── vault.py # VaultCA backend (Vault SSH engine, for production)
|
||||
│ ├── inventory.py # YAML principals inventory read/write
|
||||
│ ├── scorecard.py # §5 compliance checks
|
||||
│ └── config.py # ~/.config/warden/warden.yaml loader
|
||||
├── tests/
|
||||
└── wiki/ # (symlink or copy of AccessManagementDirective.md)
|
||||
```
|
||||
|
||||
**Backends are swappable.** Config key `backend: local | vault` selects which CA
|
||||
implementation is used. This means the tool is fully functional without Vault for local lab
|
||||
use, and production-grade with Vault — the same CLI surface, the same `cert_command`
|
||||
interface, the same principals inventory format.
|
||||
|
||||
**cert_command interface contract:**
|
||||
```
|
||||
warden sign <actor-name> --pubkey <path>
|
||||
```
|
||||
Writes the signed certificate to stdout (the cert text). Exits non-zero on failure.
|
||||
`ops-bridge` calls this verbatim via `cert_command` in `tunnels.yaml`.
|
||||
|
||||
---
|
||||
|
||||
## Stack
|
||||
|
||||
- **Language:** Python 3.11+
|
||||
- **CLI framework:** Typer
|
||||
- **Dependencies:** typer, pyyaml, httpx, cryptography (for cert parsing / TTL reading)
|
||||
- **Vault SDK:** `hvac` (optional; only required for vault backend)
|
||||
- **Packaging:** `uv tool install`
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
### T1 — Repository bootstrap
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0001-T1
|
||||
state_hub_task_id: 6d643e9d-5e97-4224-9d82-87267b5ba6bc
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
- [x] Create `ops-warden` repo; copy CLAUDE.md template from `ops-bridge`; add
|
||||
`workplans/WARDEN-WP-0001-initial-implementation.md` (this file)
|
||||
- [x] Write `SCOPE.md` (see template in §SCOPE below)
|
||||
- [x] `pyproject.toml`: `[project.scripts] warden = "warden.cli:app"`
|
||||
- [x] Register repo with state-hub (`register_repo`)
|
||||
- [x] Create state-hub workstream for this workplan
|
||||
|
||||
### T2 — Models and config
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0001-T2
|
||||
state_hub_task_id: c66fc65a-0b16-4ba2-9e70-a83d875572ec
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
- [x] `models.py`: `ActorType` enum (`adm | agt | atm`); `CertSpec` (actor_name, pubkey_path,
|
||||
ttl_hours, principals); `CertRecord` (identity, valid_before, cert_path, signed_at)
|
||||
- [x] `config.py`: load `~/.config/warden/warden.yaml`; required fields: `backend`,
|
||||
`ca_key` (local) or `vault_addr` + `vault_role_map` (vault); optional:
|
||||
`inventory_path`, `state_dir`
|
||||
- [x] Validate actor name prefix matches `ActorType` (`adm-*`, `agt-*`, `atm-*`)
|
||||
|
||||
### T3 — LocalCA backend
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0001-T3
|
||||
state_hub_task_id: a5a41e58-1c6d-42a9-9b11-2088f17c29b5
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
- [x] `ca.py`: `LocalCA.sign(spec: CertSpec) -> CertRecord`
|
||||
- Calls `ssh-keygen -s <ca_key> -I <identity> -n <principals> -V +<ttl>h <pubkey>`
|
||||
- Parses `ssh-keygen -L -f <cert>` output to extract `Valid before`, `Key ID`,
|
||||
`Principals`
|
||||
- Returns `CertRecord`; writes cert to `~/.local/state/warden/<actor>.cert.pub`
|
||||
- [x] Default TTLs enforced per `ActorType`: adm → 48 h, agt → 24 h, atm → 8 h
|
||||
(overridable per actor in inventory)
|
||||
- [x] `LocalCA.generate_keypair(actor_name) -> (privkey_path, pubkey_path)` — for agt/atm
|
||||
actors that do not bring their own key
|
||||
|
||||
### T4 — VaultCA backend
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0001-T4
|
||||
state_hub_task_id: b2067ee6-c9ce-423b-9d60-0d28069fb304
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
- [x] `vault.py`: `VaultCA.sign(spec: CertSpec) -> CertRecord`
|
||||
- `POST /v1/ssh/sign/<role>` with `public_key`, `valid_principals`, `ttl`
|
||||
- Parse response `signed_key` field; write to state dir; extract metadata via
|
||||
`ssh-keygen -L`
|
||||
- [x] Role map in config: `vault_role_map: {adm: adm-role, agt: agt-role, atm: atm-role}`
|
||||
- [x] Graceful error message when Vault is unreachable (with `--backend local` fallback hint)
|
||||
|
||||
### T5 — Principals inventory
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0001-T5
|
||||
state_hub_task_id: 6d13f8cd-1850-44c9-b769-b21250348319
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
- [x] `inventory.py`: load/save `inventory.yaml` (format mirrors §4.1 of directive):
|
||||
```yaml
|
||||
actors:
|
||||
agt-state-hub-bridge:
|
||||
type: agt
|
||||
principals: [agt-task-bridge]
|
||||
ttl_hours: 24
|
||||
description: "ops-bridge tunnel actor"
|
||||
hosts:
|
||||
coulombcore:
|
||||
allowed_principals:
|
||||
agt: [agt-task-bridge]
|
||||
atm: [atm-backup-daily]
|
||||
```
|
||||
- [x] `warden inventory list` — print table
|
||||
- [x] `warden inventory add <actor-name> --type <adm|agt|atm> --principals <...>`
|
||||
- [x] `warden inventory remove <actor-name>`
|
||||
|
||||
### T6 — CLI commands
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0001-T6
|
||||
state_hub_task_id: 656a4615-92bb-4b5d-9406-e86d24fa15d0
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
- [x] `warden sign <actor-name> --pubkey <path>` — sign existing pubkey; write cert to
|
||||
stdout (the `cert_command` interface for ops-bridge)
|
||||
- [x] `warden issue <actor-name>` — generate keypair + sign; output JSON with
|
||||
`privkey`, `cert`, `valid_before`, `identity`
|
||||
- [x] `warden status [actor-name]` — show cert validity, identity, principals, TTL
|
||||
remaining; `--all` flag to show all actors in state dir
|
||||
- [x] `warden scorecard` — run §5 checks (see T7)
|
||||
- [x] `warden inventory <subcommand>` (list / add / remove)
|
||||
|
||||
### T7 — Scorecard runner
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0001-T7
|
||||
state_hub_task_id: 7818bcc5-f40e-4793-b117-d36f653ffeed
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
- [x] `scorecard.py`: implement each §5 row as a named check function returning
|
||||
`CheckResult(name, passed, detail)`
|
||||
- [x] Checks in scope for `ops-warden` (local checks, not host-side):
|
||||
- All certs in state dir respect TTL policy for their `ActorType`
|
||||
- No actor in inventory lacks a `principals` entry
|
||||
- Actor name prefix matches declared type
|
||||
- No cert expired by more than 5 min still present in state dir (stale cleanup)
|
||||
- [x] Host-side checks (password auth disabled, root login disabled, etc.) are out of scope
|
||||
— those live in the Ansible `ssh-access-audit.yml` playbook in `railiance-infra`
|
||||
- [x] `warden scorecard --json` for machine-readable output
|
||||
|
||||
### T8 — ops-ssh-wrapper script
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0001-T8
|
||||
state_hub_task_id: e9c28152-5785-4995-83a5-439985ed3db9
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
- [x] Ship `scripts/ops-ssh-wrapper` (the Python snippet from §4.1, hardened):
|
||||
- Reads `WARDEN_ACTOR` and `SSH_PUBKEY` env vars
|
||||
- Calls `warden sign $WARDEN_ACTOR --pubkey $SSH_PUBKEY`
|
||||
- Loads cert via `ssh-add`; execs the given command
|
||||
- [x] Install as part of `uv tool install` entry points
|
||||
|
||||
### T9 — Tests
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0001-T9
|
||||
state_hub_task_id: 950139ab-cc17-4f1d-9a17-d5744e402ddf
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
- [x] Unit tests for `LocalCA` (mock `ssh-keygen` subprocess)
|
||||
- [x] Unit tests for inventory YAML round-trip
|
||||
- [x] Unit tests for actor name prefix validation
|
||||
- [x] Integration test: `LocalCA.sign` on a real test keypair (requires `ssh-keygen` in PATH)
|
||||
- [x] Scorecard unit tests (mock cert records)
|
||||
|
||||
### T10 — Documentation
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0001-T10
|
||||
state_hub_task_id: 271d6759-e359-41ce-80e4-76c574634a87
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
- [x] `SCOPE.md` (see below)
|
||||
- [x] `wiki/AccessManagementDirective.md` — copy from `ops-bridge/wiki/`
|
||||
- [x] `wiki/OpsWardenConfig.md` — annotated `warden.yaml` reference
|
||||
- [x] `wiki/CertCommandInterface.md` — contract for `cert_command` callers (ops-bridge etc.)
|
||||
|
||||
---
|
||||
|
||||
## SCOPE.md Template
|
||||
|
||||
```
|
||||
# SCOPE
|
||||
|
||||
## One-liner
|
||||
SSH Certificate Authority and credential issuance for the ops fleet —
|
||||
signs short-lived certs for adm/agt/atm actors; provides the cert_command
|
||||
interface consumed by ops-bridge and other tooling.
|
||||
|
||||
## Core Idea
|
||||
Implements AccessManagementDirective §§1–5. Owns the CA key, actor inventory,
|
||||
signing logic, and scorecard. Does not own tunnel lifecycle, host provisioning,
|
||||
or SSH key generation for humans.
|
||||
|
||||
## In Scope
|
||||
- Local CA backend (ssh-keygen -s) for lab / non-Vault use
|
||||
- Vault SSH engine backend for production
|
||||
- Actor identity registry (inventory.yaml)
|
||||
- cert_command CLI interface: `warden sign <actor> --pubkey <path>`
|
||||
- TTL policy enforcement per ActorType (adm/agt/atm)
|
||||
- Certificate status and stale-cert cleanup
|
||||
- Scorecard checks (local / cert-side only)
|
||||
- ops-ssh-wrapper script for agt/atm startup automation
|
||||
|
||||
## Out of Scope
|
||||
- Host-side principal deployment (railiance-infra Ansible)
|
||||
- SSH key generation for human admins (self-service: ssh-keygen)
|
||||
- Vault cluster setup / HA
|
||||
- Session recording, audit forwarding to SIEM (host-side)
|
||||
- Tunnel lifecycle (ops-bridge)
|
||||
- SSO / Teleport (trigger when §6.2 scale thresholds are hit)
|
||||
|
||||
## Relevant When
|
||||
- Issuing or refreshing a cert for any adm/agt/atm actor
|
||||
- Checking cert validity / scorecard compliance
|
||||
- ops-bridge needs cert_command to be defined
|
||||
- Adding a new actor to the principals inventory
|
||||
|
||||
## Not Relevant When
|
||||
- Managing tunnel lifecycle (ops-bridge)
|
||||
- Deploying SSH config to hosts (railiance-infra)
|
||||
- All access is via static keys with no TTL (legacy mode)
|
||||
|
||||
## Current State
|
||||
Status: planned (WARDEN-WP-0001 not yet started)
|
||||
|
||||
## Related Repositories
|
||||
- ops-bridge — primary consumer of cert_command interface
|
||||
- railiance-infra — owns host-side principal deployment
|
||||
- the-custodian/state-hub — registers domain/workstreams
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [x] `warden sign agt-test-actor --pubkey /tmp/test.pub` outputs a valid cert (local backend)
|
||||
- [x] `warden status agt-test-actor` shows correct identity, principals, and time-to-expiry
|
||||
- [x] `warden scorecard` returns 5/5 on a clean test inventory
|
||||
- [x] `warden sign` called from ops-bridge `cert_command` in an integration test tunnel
|
||||
- [x] All tests pass: `uv run pytest`
|
||||
- [x] All lints pass: `uv run ruff check .`
|
||||
|
|
@ -0,0 +1,178 @@
|
|||
---
|
||||
id: WARDEN-WP-0002
|
||||
type: workplan
|
||||
title: "OpsWarden Correctness and Operational Completeness"
|
||||
domain: custodian
|
||||
repo: ops-warden
|
||||
status: archived
|
||||
owner: Bernd
|
||||
topic_slug: custodian
|
||||
planning_priority: high
|
||||
planning_order: 2
|
||||
created: "2026-05-15"
|
||||
updated: "2026-05-15"
|
||||
state_hub_workstream_id: "5a9fba2c-6161-49a4-a231-e750fa4ab572"
|
||||
---
|
||||
|
||||
> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`).
|
||||
|
||||
# WARDEN-WP-0002 — Correctness and Operational Completeness
|
||||
|
||||
**Scope:** Fix three functional gaps identified after WARDEN-WP-0001: TTL max
|
||||
enforcement (directive compliance), stale cert cleanup (SCOPE.md promises it),
|
||||
and an outgoing signatures log (audit traceability for every signing operation).
|
||||
|
||||
**Out of scope:** Test coverage improvements (WARDEN-WP-0003), Vault cluster
|
||||
setup, host-side principal deployment.
|
||||
|
||||
---
|
||||
|
||||
## Goal
|
||||
|
||||
After this workplan:
|
||||
|
||||
1. `warden sign` and `warden issue` reject TTLs that exceed the type maximum
|
||||
defined in the AccessManagementDirective — no cert can be silently issued
|
||||
with a longer-than-allowed validity window.
|
||||
2. Stale/expired certs do not accumulate in the state dir. `warden cleanup`
|
||||
provides an on-demand sweep; `LocalCA.sign()` auto-evicts the previous cert
|
||||
for the same actor before writing the new one.
|
||||
3. Every successful signing operation is recorded in an append-only
|
||||
`signatures.log` in the state dir. `warden log` provides a human-readable
|
||||
and machine-readable view of the signing history.
|
||||
|
||||
---
|
||||
|
||||
## Reference Documents
|
||||
|
||||
| Document | Location |
|
||||
|---|---|
|
||||
| AccessManagementDirective | `wiki/AccessManagementDirective.md` |
|
||||
| WARDEN-WP-0001 | `workplans/WARDEN-WP-0001-initial-implementation.md` |
|
||||
| SCOPE.md | `SCOPE.md` |
|
||||
|
||||
---
|
||||
|
||||
## Design Decisions
|
||||
|
||||
### TTL enforcement: reject, don't clamp
|
||||
|
||||
When `spec.ttl_hours > DEFAULT_TTL_HOURS[actor_type]`, raise `CAError` rather
|
||||
than silently clamping. A silent clamp would mask configuration errors and hide
|
||||
directive violations from operators. An explicit error forces a deliberate
|
||||
decision.
|
||||
|
||||
The check lives in `CABackend.sign()` before the subprocess call so it applies
|
||||
to both `LocalCA` and `VaultCA`. Vault's own role `max_ttl` provides a second
|
||||
layer; this check is the warden-side gate.
|
||||
|
||||
### Cleanup: proactive (on sign) + reactive (on demand)
|
||||
|
||||
`LocalCA.sign()` removes the previous cert for the same actor before writing the
|
||||
new one — this keeps state_dir from growing unboundedly under normal operation.
|
||||
`warden cleanup` handles the edge cases: certs whose actor is no longer in the
|
||||
inventory, certs from aborted sessions, certs left by actors that were renamed.
|
||||
|
||||
`VaultCA.sign()` also evicts before writing (same logic, same helper function).
|
||||
|
||||
### Signatures log: JSONL, append-only, in state_dir
|
||||
|
||||
One line per signing event, written after a successful `CertRecord` is produced.
|
||||
Format: `{"timestamp": ..., "actor": ..., "actor_type": ..., "identity": ...,
|
||||
"principals": [...], "ttl_hours": ..., "valid_before": ..., "backend": ...}`.
|
||||
|
||||
The log lives alongside certs in `state_dir` so a single directory backup
|
||||
captures the full operational history. No rotation at this scope — add rotation
|
||||
in a follow-up if the file grows beyond a few MB in practice.
|
||||
|
||||
`warden log` is read-only. No deletion via CLI — the log is an audit artefact.
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
### T1 — TTL max enforcement per ActorType
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0002-T1
|
||||
state_hub_task_id: b0d0b5f7-a181-4590-be26-c48ae28cd964
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
- [x] `models.py`: add `MAX_TTL_HOURS = DEFAULT_TTL_HOURS` alias (same values,
|
||||
explicit name signals policy intent); add helper
|
||||
`enforce_ttl(spec: CertSpec) -> None` that raises `CAError` when
|
||||
`spec.ttl_hours > MAX_TTL_HOURS[spec.actor_type]`
|
||||
- [x] `ca.py`: call `enforce_ttl(spec)` at the top of `CABackend.sign()` base
|
||||
(or in both `LocalCA.sign()` and `VaultCA.sign()` if no shared base call)
|
||||
- [x] `scorecard.py`: add `check_ttl_policy(state_dir, inventory)` — parse each
|
||||
cert in state_dir via `ssh-keygen -L`; compare cert validity window
|
||||
duration against `MAX_TTL_HOURS[actor_type]`; flag if exceeded
|
||||
- [x] Add `check_ttl_policy` to `run_scorecard()`
|
||||
- [x] Update tests: `test_ca.py` — assert `CAError` raised when `ttl_hours`
|
||||
exceeds max for each type; assert no error at exactly the max
|
||||
|
||||
### T2 — Stale cert cleanup command
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0002-T2
|
||||
state_hub_task_id: aeeefbad-c0bd-4ae8-a3fe-9f72321b4caa
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
- [x] `ca.py`: extract `_evict_cert(actor_name, state_dir)` — removes
|
||||
`state_dir/<actor_name>-cert.pub` if it exists; call at the top of
|
||||
`LocalCA.sign()` and `VaultCA.sign()` before writing the new cert
|
||||
- [x] `cli.py`: add `warden cleanup [actor-name]` command
|
||||
- No actor-name: iterate `state_dir/*.cert.pub`, remove any whose
|
||||
`valid_before < now - 5 min`
|
||||
- With actor-name: remove only that actor's cert if stale
|
||||
- `--dry-run`: print what would be removed without deleting
|
||||
- Exit 0 always (cleanup is idempotent; nothing to clean is not an error)
|
||||
- [x] Update `check_no_stale_certs` scorecard check detail message to suggest
|
||||
running `warden cleanup`
|
||||
- [x] Update tests: verify `_evict_cert` is called during sign; verify cleanup
|
||||
command removes stale file; verify `--dry-run` does not delete
|
||||
|
||||
### T3 — Outgoing signatures log
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0002-T3
|
||||
state_hub_task_id: 0194d24f-a8fe-4f6d-88e6-addea3542c0e
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
- [x] `ca.py`: after a successful `CertRecord` is produced in `LocalCA.sign()`
|
||||
and `VaultCA.sign()`, call `_append_signature_log(record, spec, state_dir,
|
||||
backend)` which appends a JSONL line to
|
||||
`state_dir/signatures.log`
|
||||
Fields: `timestamp` (ISO 8601 UTC), `actor`, `actor_type`, `identity`,
|
||||
`principals`, `ttl_hours`, `valid_before`, `cert_path`, `backend`
|
||||
- [x] `cli.py`: add `warden log [actor-name]` command
|
||||
- Reads `state_dir/signatures.log` (empty list if absent)
|
||||
- `--last N` (default 20): show last N entries
|
||||
- `--actor <name>`: filter by actor
|
||||
- `--json`: output newline-delimited JSON; default: Rich table
|
||||
- Exit 0 always
|
||||
- [x] Update tests: verify log entry written after sign; verify log not written
|
||||
on CAError; verify `warden log` filters correctly
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [x] `warden sign agt-test --pubkey /tmp/k.pub --ttl 100` raises `CAError`
|
||||
(agt max is 24h)
|
||||
- [x] `warden sign agt-test --pubkey /tmp/k.pub --ttl 24` succeeds
|
||||
- [x] `warden scorecard` includes TTL policy check; fails when a cert exceeds type max
|
||||
- [x] After `warden sign`, `state_dir/signatures.log` has one new line; valid JSON
|
||||
- [x] `warden log` renders a table; `warden log --json` is parseable
|
||||
- [x] `warden log --actor agt-test` returns only entries for that actor
|
||||
- [x] `warden cleanup --dry-run` lists stale certs without deleting
|
||||
- [x] `warden cleanup` removes stale certs; scorecard `no_stale_certs` passes after
|
||||
- [x] Re-signing an actor replaces its cert file (no accumulation)
|
||||
- [x] All tests pass: `uv run pytest`
|
||||
- [x] All lints pass: `uv run ruff check .`
|
||||
|
|
@ -0,0 +1,211 @@
|
|||
---
|
||||
id: WARDEN-WP-0003
|
||||
type: workplan
|
||||
title: "OpsWarden Test Coverage and Code Quality"
|
||||
domain: custodian
|
||||
repo: ops-warden
|
||||
status: archived
|
||||
owner: Bernd
|
||||
topic_slug: custodian
|
||||
planning_priority: medium
|
||||
planning_order: 3
|
||||
created: "2026-05-15"
|
||||
updated: "2026-05-15"
|
||||
state_hub_workstream_id: "cb2bbf3c-848a-4af6-ba64-8361e64cd4d7"
|
||||
---
|
||||
|
||||
> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`).
|
||||
|
||||
# WARDEN-WP-0003 — Test Coverage and Code Quality
|
||||
|
||||
**Scope:** Close the test coverage gaps left after WARDEN-WP-0001: VaultCA has
|
||||
zero tests, `generate_keypair` is untested, no CLI tests exist, and no real
|
||||
`ssh-keygen` integration test was written. Also fix file permission enforcement
|
||||
(security) and add `--state-dir` override to `warden status` (usability).
|
||||
|
||||
**Out of scope:** Functional behaviour changes (WARDEN-WP-0002), Vault cluster
|
||||
setup, host-side tooling.
|
||||
|
||||
---
|
||||
|
||||
## Goal
|
||||
|
||||
After this workplan:
|
||||
|
||||
1. VaultCA has a full unit test suite covering success, auth failure, network
|
||||
failure, and role-map misconfiguration.
|
||||
2. `generate_keypair` has direct unit tests alongside the existing `sign` tests.
|
||||
3. A `tests/test_cli.py` covers every command's exit codes and output shape.
|
||||
4. A `tests/test_integration.py` marked `@pytest.mark.integration` exercises
|
||||
`LocalCA.sign()` against a real `ssh-keygen` without any mocking.
|
||||
5. Cert and key files written by warden are always mode 600; a scorecard check
|
||||
flags world-readable files.
|
||||
6. `warden status --state-dir <path>` works without a `warden.yaml`.
|
||||
|
||||
---
|
||||
|
||||
## Reference Documents
|
||||
|
||||
| Document | Location |
|
||||
|---|---|
|
||||
| WARDEN-WP-0001 | `workplans/WARDEN-WP-0001-initial-implementation.md` |
|
||||
| WARDEN-WP-0002 | `workplans/WARDEN-WP-0002-correctness-and-completeness.md` |
|
||||
| CertCommandInterface | `wiki/CertCommandInterface.md` |
|
||||
|
||||
---
|
||||
|
||||
## Design Decisions
|
||||
|
||||
### Integration tests: separate marker, not separate directory
|
||||
|
||||
Use `@pytest.mark.integration` and skip when `ssh-keygen` is not in PATH. Tests
|
||||
live in `tests/test_integration.py`. The unit suite (`uv run pytest`) excludes
|
||||
integration tests via `pytest.ini_options addopts = "-m 'not integration'"`;
|
||||
`uv run pytest -m integration` runs them explicitly. This keeps CI fast while
|
||||
making the real-ssh-keygen path easy to invoke manually.
|
||||
|
||||
### File permissions: at write time, not at read time
|
||||
|
||||
`os.chmod(path, 0o600)` is called immediately after each `path.write_text()` or
|
||||
`shutil.copy2()` that writes a key or cert. No deferred or scheduled chmod. The
|
||||
scorecard check catches files that were written by older versions of warden or by
|
||||
external tools.
|
||||
|
||||
### `warden status --state-dir`: config bypass, not config optional
|
||||
|
||||
When `--state-dir` is provided, skip `load_config()` entirely — don't try to
|
||||
load a partial config. This makes the flag useful on remote machines that have
|
||||
received a cert via ops-bridge but have no warden installation.
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
### T1 — VaultCA tests
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0003-T1
|
||||
state_hub_task_id: eff074ce-c027-4df5-8006-0990296592ac
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
- [x] Create `tests/test_vault.py`
|
||||
- [x] Test `VaultCA.sign()` success: mock `httpx.post` returning a valid
|
||||
`signed_key`; assert `CertRecord` fields; assert cert file written to
|
||||
state_dir
|
||||
- [x] Test HTTP 403: `httpx.HTTPStatusError` → `CAError` with status code in message
|
||||
- [x] Test unreachable Vault: `httpx.RequestError` → `CAError` with fallback hint
|
||||
- [x] Test missing `VAULT_TOKEN`: `_token()` raises `CAError` before HTTP call
|
||||
- [x] Test missing role in `role_map`: `CAError` before HTTP call
|
||||
- [x] Test missing pubkey file: `CAError` before HTTP call
|
||||
|
||||
### T2 — LocalCA.generate_keypair tests
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0003-T2
|
||||
state_hub_task_id: ddfe5331-0a3b-4783-bdf4-f5ebcdf7965c
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
- [x] Add `TestGenerateKeypair` class to `tests/test_ca.py`
|
||||
- [x] Test success: mock `subprocess.run`; assert privkey and pubkey paths returned
|
||||
- [x] Test ssh-keygen called with `-t ed25519`, `-N ""`, `-C actor_name`
|
||||
- [x] Test existing files are unlinked before generation (write dummy files first)
|
||||
- [x] Test `CAError` raised on non-zero ssh-keygen exit code
|
||||
- [x] Test output files land in `state_dir/keys/`
|
||||
|
||||
### T3 — CLI tests
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0003-T3
|
||||
state_hub_task_id: 040ce3a1-0efb-4816-a2d9-357162dd1612
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
- [x] Create `tests/test_cli.py` using `typer.testing.CliRunner`
|
||||
- [x] `warden sign`: exits 0 and stdout is cert text (mock CA); exits 1 on
|
||||
unknown actor; exits 1 on config error
|
||||
- [x] `warden issue`: exits 1 on vault backend; exits 0 on local backend (mock CA)
|
||||
- [x] `warden status`: exits 0 and prints "no cert" message when state_dir empty;
|
||||
exits 1 when cert is expired (mock `parse_cert_metadata`)
|
||||
- [x] `warden scorecard`: exits 0 on clean inventory + empty state_dir;
|
||||
exits 1 when a check fails
|
||||
- [x] `warden inventory add / list / remove`: round-trip via tmp inventory file
|
||||
- [x] `warden log`: exits 0 with empty output when no log; `--json` is valid JSON
|
||||
(after WARDEN-WP-0002 T3 adds the log command)
|
||||
- [x] `warden cleanup --dry-run`: exits 0, no files deleted
|
||||
(after WARDEN-WP-0002 T2 adds cleanup)
|
||||
|
||||
### T4 — Real ssh-keygen integration test
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0003-T4
|
||||
state_hub_task_id: 434fb008-103f-410c-85fd-e77b33e61fe4
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
- [x] Create `tests/test_integration.py`
|
||||
- [x] Mark all tests `@pytest.mark.integration`
|
||||
- [x] Add `pytest.ini_options` to `pyproject.toml`:
|
||||
`addopts = "-m 'not integration'"` so unit suite skips them by default
|
||||
- [x] Test `LocalCA.sign()` end-to-end: generate a real CA keypair and actor
|
||||
keypair via subprocess ssh-keygen in tmp_path; call `LocalCA.sign()`;
|
||||
assert `CertRecord.valid_before > datetime.now(utc)`; assert cert file
|
||||
exists; assert `parse_cert_metadata()` succeeds on it without mocking
|
||||
- [x] Skip test if `shutil.which("ssh-keygen") is None`
|
||||
- [x] Document in README: `uv run pytest -m integration` to run real-CA tests
|
||||
|
||||
### T5 — File permissions enforcement (mode 600)
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0003-T5
|
||||
state_hub_task_id: ac146fe6-d1fd-4186-91bd-6f098de72449
|
||||
status: done
|
||||
priority: medium
|
||||
```
|
||||
|
||||
- [x] `ca.py` `LocalCA.sign()`: call `os.chmod(dest, 0o600)` after `shutil.copy2`
|
||||
- [x] `ca.py` `LocalCA.generate_keypair()`: call `os.chmod(privkey, 0o600)` and
|
||||
`os.chmod(pubkey, 0o644)` after generation
|
||||
- [x] `vault.py` `VaultCA.sign()`: call `os.chmod(dest, 0o600)` after `dest.write_text`
|
||||
- [x] `scorecard.py`: add `check_file_permissions(state_dir)` — flag any
|
||||
`*-cert.pub` or `keys/*` file where `stat().st_mode & 0o044 != 0`
|
||||
- [x] Add `check_file_permissions` to `run_scorecard()`
|
||||
- [x] Update `test_ca.py`: assert `os.chmod` called with correct mode after sign
|
||||
and generate_keypair (patch os.chmod or check stat on actual files in
|
||||
tmp_path)
|
||||
|
||||
### T6 — warden status --state-dir override
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0003-T6
|
||||
state_hub_task_id: 1c9f1987-7b11-43c1-a5e3-c2fd8d1c1589
|
||||
status: done
|
||||
priority: low
|
||||
```
|
||||
|
||||
- [x] `cli.py` `status()`: add
|
||||
`state_dir_override: Annotated[Optional[Path], typer.Option("--state-dir")] = None`
|
||||
- [x] When `--state-dir` is provided: use it directly, skip `_load_cfg()` entirely
|
||||
- [x] When absent: load config as today
|
||||
- [x] Add test in `test_cli.py`: invoke `warden status --state-dir <tmp_path>`
|
||||
without a config file; assert exit 0
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [x] `uv run pytest` runs unit suite only; all pass; VaultCA and generate_keypair
|
||||
covered
|
||||
- [x] `uv run pytest -m integration` succeeds (requires ssh-keygen in PATH)
|
||||
- [x] `test_cli.py` covers all commands; no mocked subprocess in CLI tests where
|
||||
avoidable (use tmp inventory files and mocked CA)
|
||||
- [x] `ls -la ~/.local/state/warden/*.pub` shows mode 600 for newly signed certs
|
||||
- [x] Scorecard `file_permissions` check passes on a clean state dir; fails on a
|
||||
world-readable cert
|
||||
- [x] `warden status --state-dir /tmp/some-dir` runs without a `warden.yaml`
|
||||
- [x] All lints pass: `uv run ruff check .`
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
---
|
||||
id: WARDEN-WP-0004
|
||||
type: workplan
|
||||
title: "OpsWarden Repo Hygiene and Hub Sync"
|
||||
domain: custodian
|
||||
repo: ops-warden
|
||||
status: archived
|
||||
owner: codex
|
||||
topic_slug: custodian
|
||||
created: "2026-06-17"
|
||||
updated: "2026-06-17"
|
||||
state_hub_workstream_id: "3c4b6e68-550a-4fc6-a804-95f1f68936c3"
|
||||
---
|
||||
|
||||
> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`).
|
||||
|
||||
# WARDEN-WP-0004 — Repo Hygiene and Hub Sync
|
||||
|
||||
**Scope:** Bring repo orientation docs and agent rules in line with the shipped
|
||||
`warden` CLI (WARDEN-WP-0001 through 0003 complete). Archive finished workplans
|
||||
and sync State Hub.
|
||||
|
||||
**Out of scope:** OpenBao doc alignment (WARDEN-WP-0005), capability registry
|
||||
publish, task-status canon migration in AGENTS.md.
|
||||
|
||||
---
|
||||
|
||||
## Goal
|
||||
|
||||
After this workplan, a new agent session can orient from accurate local files
|
||||
without reading stale "planned / scaffolding only" language, and State Hub
|
||||
reflects archived workplan status.
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
### T1 — Update orientation docs
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0004-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "f9d3926c-8637-411c-a477-2960b754704c"
|
||||
```
|
||||
|
||||
- [x] `SCOPE.md` Current State reflects shipped CLI (v0.1.0, workplans 0001–0003 done)
|
||||
- [x] `README.md` replaces repo-seed template with install, config, and dev commands
|
||||
|
||||
### T2 — Fill agent rules
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0004-T02
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "86c764a5-62fc-45fe-a8d2-332d6554a976"
|
||||
```
|
||||
|
||||
- [x] `.claude/rules/stack-and-commands.md` — stack and `uv` dev commands
|
||||
- [x] `.claude/rules/architecture.md` — module layout and data flow
|
||||
- [x] `.claude/rules/repo-boundary.md` — adjacent repo ownership
|
||||
|
||||
### T3 — Archive finished workplans
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0004-T03
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "d3e54e63-ce98-4632-bc08-0e2667f19f12"
|
||||
```
|
||||
|
||||
- [x] Move WARDEN-WP-0001/0002/0003 to `workplans/archived/` with date prefix
|
||||
- [x] Set frontmatter `status: archived` on moved files
|
||||
|
||||
### T4 — Sync State Hub
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0004-T04
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "51729695-262f-4fe4-9c38-f99ee046d32a"
|
||||
```
|
||||
|
||||
- [x] Run `make fix-consistency REPO=ops-warden` from state-hub
|
||||
- [x] Verify `.custodian-brief.md` reflects archived workstreams
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [x] `SCOPE.md` no longer says "planned" or "scaffolding only"
|
||||
- [x] `README.md` documents `uv sync`, `uv run pytest`, and `warden --help`
|
||||
- [x] Agent rules have no empty TODO blocks for stack, architecture, or boundary
|
||||
- [x] Only WARDEN-WP-0004 remains in `workplans/` root (archived plans moved)
|
||||
- [x] `make fix-consistency REPO=ops-warden` completes without error
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
---
|
||||
id: WARDEN-WP-0005
|
||||
type: workplan
|
||||
title: "OpsWarden OpenBao-First Documentation Alignment"
|
||||
domain: custodian
|
||||
repo: ops-warden
|
||||
status: archived
|
||||
owner: codex
|
||||
topic_slug: custodian
|
||||
created: "2026-06-17"
|
||||
updated: "2026-06-17"
|
||||
state_hub_workstream_id: "57f6ebf8-0ef3-4686-9a73-3f9d38288be9"
|
||||
---
|
||||
|
||||
> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`).
|
||||
|
||||
# WARDEN-WP-0005 — OpenBao-First Documentation Alignment
|
||||
|
||||
**Scope:** Update ops-warden documentation so production guidance names OpenBao
|
||||
as the platform secrets service while preserving the existing `backend: vault`
|
||||
config surface (Vault-compatible SSH secrets engine API). No code changes.
|
||||
|
||||
**Out of scope:** VaultCA backend rewrite, OpenBao SSH engine deployment in
|
||||
`railiance-platform`, AccessManagementDirective canon updates.
|
||||
|
||||
**Reference:** `RAIL-PL-WP-0002` — Railiance standardizes on OpenBao; ops-warden
|
||||
follow-up noted 2026-05-17.
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
### T1 — OpsWardenConfig.md
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0005-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "bbbc4dda-9634-4c04-86e5-94b96c021b43"
|
||||
```
|
||||
|
||||
- [x] OpenBao-first production section with Railiance URLs and `bao` CLI examples
|
||||
- [x] Explain `backend: vault` / `vault:` keys as Vault-compatible API abstraction
|
||||
- [x] Link to `railiance-platform/docs/openbao.md`
|
||||
|
||||
### T2 — Cross-reference updates
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0005-T02
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "6391cb82-896e-405a-a59b-36640e6480ba"
|
||||
```
|
||||
|
||||
- [x] `SCOPE.md` Core Idea and In Scope — OpenBao-first, Vault-compatible
|
||||
- [x] `wiki/CertCommandInterface.md` — caller-agnostic wording includes OpenBao
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [x] Production config example uses OpenBao (`bao.coulomb.social` or in-cluster URL)
|
||||
- [x] No reader is told HashiCorp Vault is the platform standard
|
||||
- [x] `backend: vault` config shape unchanged (code compatibility preserved)
|
||||
- [x] `uv run pytest` still passes (docs-only change)
|
||||
|
|
@ -0,0 +1,140 @@
|
|||
---
|
||||
id: WARDEN-WP-0006
|
||||
type: workplan
|
||||
title: "NetKingdom Alignment and Operational Access Stewardship"
|
||||
domain: custodian
|
||||
repo: ops-warden
|
||||
status: archived
|
||||
owner: codex
|
||||
topic_slug: custodian
|
||||
planning_priority: high
|
||||
planning_order: 6
|
||||
created: "2026-06-17"
|
||||
updated: "2026-06-17"
|
||||
state_hub_workstream_id: "a5c9f24b-1ad4-46da-bc8e-b99897f8e302"
|
||||
---
|
||||
|
||||
> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`).
|
||||
|
||||
# WARDEN-WP-0006 — NetKingdom Alignment and Operational Access Stewardship
|
||||
|
||||
**Scope:** Close gaps identified in `history/2026-06-17-intent-scope-assessment.md`
|
||||
between INTENT (operational access steward for NetKingdom security) and SCOPE
|
||||
(shipped SSH CLI only). Documentation and alignment first; code changes limited
|
||||
to optional CLI ergonomics.
|
||||
|
||||
**Out of scope:** flex-auth integration implementation, OpenBao cluster deploy,
|
||||
universal credential broker, net-kingdom INTENT.md rewrite.
|
||||
|
||||
---
|
||||
|
||||
## Goal
|
||||
|
||||
After this workplan, a development worker or agent can:
|
||||
|
||||
1. Read ops-warden material and know **which NetKingdom subsystem** handles each
|
||||
credential type.
|
||||
2. Obtain **SSH certs** via documented actor patterns and production OpenBao path.
|
||||
3. Find ops-warden recognized in **NetKingdom responsibility/platform** docs as
|
||||
the operational SSH credential authority.
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
### T1 — Credential routing runbook
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0006-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "ffc6a0c2-4312-4584-be7a-c8411cb01899"
|
||||
```
|
||||
|
||||
- [x] `wiki/CredentialRouting.md` with decision tree and anti-examples
|
||||
- [x] Linked from SCOPE, INTENT, README
|
||||
|
||||
### T2 — Actor inventory patterns
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0006-T02
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "3816463d-7dfd-469d-9324-fd7880b50608"
|
||||
```
|
||||
|
||||
- [x] `wiki/ActorInventoryPatterns.md`
|
||||
- [x] `examples/inventory.seed.yaml`
|
||||
|
||||
### T3 — NetKingdom cross-links (ops-warden side)
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0006-T03
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "f158366a-5746-48b8-acce-472dce8f925e"
|
||||
```
|
||||
|
||||
- [x] `wiki/NetKingdomSecurityMap.md`
|
||||
- [x] Registry capability stewardship summary
|
||||
- [x] `.claude/rules/repo-boundary.md` routing table
|
||||
|
||||
### T4 — NetKingdom canon patch (coordination)
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0006-T04
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "e40e4395-8f01-4f79-a539-d0de8e427321"
|
||||
```
|
||||
|
||||
- [x] `net-kingdom/docs/responsibility-map.md` — Operational SSH dependency
|
||||
- [x] `net-kingdom/docs/platform-identity-security-architecture.md` — Operational SSH Path
|
||||
|
||||
### T5 — OpenBao SSH engine operational checklist
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0006-T05
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "a94e20a2-970b-4a0c-bd23-8510b841b938"
|
||||
```
|
||||
|
||||
- [x] `wiki/OpenBaoSshEngineChecklist.md`
|
||||
|
||||
### T6 — Policy-gated signing design (design only)
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0006-T06
|
||||
status: done
|
||||
priority: low
|
||||
state_hub_task_id: "b10a4b4d-bfa1-4f49-b6a5-f339f1e6a2e1"
|
||||
```
|
||||
|
||||
- [x] `wiki/PolicyGatedSigning.md`
|
||||
|
||||
### T7 — Re-assess INTENT ↔ SCOPE
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0006-T07
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "ef8b5c57-2343-4cfc-9fee-48db1e56f69a"
|
||||
```
|
||||
|
||||
- [x] `history/2026-06-17-intent-scope-reassessment.md`
|
||||
- [x] SCOPE.md Current State updated
|
||||
- [x] `make fix-consistency REPO=ops-warden`
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [x] `wiki/CredentialRouting.md` exists and is linked from README/SCOPE
|
||||
- [x] `wiki/ActorInventoryPatterns.md` exists
|
||||
- [x] `wiki/NetKingdomSecurityMap.md` exists
|
||||
- [x] NetKingdom responsibility-map recognizes ops-warden SSH lane (T4)
|
||||
- [x] OpenBao SSH checklist documented (T5)
|
||||
- [x] Policy-gated signing design drafted (T6)
|
||||
- [x] INTENT ↔ SCOPE re-assessment recorded (T7)
|
||||
- [x] `reuse-surface validate --root .` passes
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
---
|
||||
id: WARDEN-WP-0007
|
||||
type: workplan
|
||||
title: "Policy Gate and Production OpenBao Verification"
|
||||
domain: custodian
|
||||
repo: ops-warden
|
||||
status: archived
|
||||
owner: codex
|
||||
topic_slug: custodian
|
||||
planning_priority: high
|
||||
planning_order: 7
|
||||
created: "2026-06-17"
|
||||
updated: "2026-06-17"
|
||||
state_hub_workstream_id: "3718ac07-2fa2-47d0-a02a-c9a7b83a5ba9"
|
||||
---
|
||||
|
||||
> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`).
|
||||
|
||||
# WARDEN-WP-0007 — Policy Gate and Production OpenBao Verification
|
||||
|
||||
**Scope:** Record production OpenBao reachability evidence; implement opt-in
|
||||
flex-auth policy gate before `warden sign` / `warden issue` per
|
||||
`wiki/PolicyGatedSigning.md`.
|
||||
|
||||
**Out of scope:** flex-auth policy package authoring, OpenBao SSH engine mount
|
||||
on Railiance (operator), identity claim requirement (v2.1).
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
### T1 — Production OpenBao verification evidence
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0007-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "344540ad-5912-4118-b406-450b96e13c40"
|
||||
```
|
||||
|
||||
- [x] Probe `https://bao.coulomb.social/v1/sys/health`
|
||||
- [x] Document results in `history/2026-06-17-openbao-production-verify.md`
|
||||
- [x] Note blockers for full `warden sign` (scoped token, SSH engine roles)
|
||||
|
||||
### T2 — Policy config and flex-auth client
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0007-T02
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "05424ddf-5fe9-43a1-a2f8-c47235a012c8"
|
||||
```
|
||||
|
||||
- [x] `PolicyConfig` in `config.py` (`policy.enabled`, `flex_auth_url`, `fail_closed`)
|
||||
- [x] `policy.py` — POST `/v1/check`, pubkey fingerprint, CAError on deny
|
||||
|
||||
### T3 — Wire policy gate into sign/issue
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0007-T03
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "f5ae8e6e-8cce-4526-b18c-0452a135af49"
|
||||
```
|
||||
|
||||
- [x] Call policy check before `ca.sign()` when enabled
|
||||
- [x] Store `policy_decision_id` in `signatures.log`
|
||||
|
||||
### T4 — Tests and docs
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0007-T04
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "ea921d56-033b-4619-8032-61af7992e610"
|
||||
```
|
||||
|
||||
- [x] `tests/test_policy.py`
|
||||
- [x] Update `wiki/OpsWardenConfig.md`, `wiki/PolicyGatedSigning.md`
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [x] Production health evidence recorded (non-secret)
|
||||
- [x] `policy.enabled: false` default — no behavior change
|
||||
- [x] `policy.enabled: true` calls flex-auth; deny blocks sign
|
||||
- [x] All unit tests pass
|
||||
|
|
@ -0,0 +1,153 @@
|
|||
---
|
||||
id: WARDEN-WP-0008
|
||||
type: workplan
|
||||
title: "Production SSH Path and Stewardship Closeout"
|
||||
domain: custodian
|
||||
repo: ops-warden
|
||||
status: finished
|
||||
owner: codex
|
||||
topic_slug: custodian
|
||||
planning_priority: high
|
||||
planning_order: 8
|
||||
created: "2026-06-17"
|
||||
updated: "2026-06-18"
|
||||
state_hub_workstream_id: "a174963a-4ff1-4565-b19f-896cd4ff14a0"
|
||||
---
|
||||
|
||||
> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`).
|
||||
|
||||
# WARDEN-WP-0008 — Production SSH Path and Stewardship Closeout
|
||||
|
||||
**Scope:** Close the reliability gap left after WARDEN-WP-0007 — prove the
|
||||
production OpenBao SSH signing path end-to-end, refresh INTENT/SCOPE canon for
|
||||
the shipped flex-auth policy gate, adapt repo docs to State Hub task-status
|
||||
canon, and archive finished workplans.
|
||||
|
||||
**Out of scope:** OpenBao cluster deploy or SSH engine bootstrap (operator /
|
||||
`railiance-platform`), flex-auth policy package authoring, NK-WP-0009 joint
|
||||
tutorial (coordinate separately), populating non-SSH secrets (e.g. OpenRouter
|
||||
API keys — route to OpenBao per `wiki/CredentialRouting.md`).
|
||||
|
||||
---
|
||||
|
||||
## Goal
|
||||
|
||||
Move ops-warden from **documented + code-shipped** (WP-0006/0007) to
|
||||
**production-verified SSH issuance** with up-to-date stewardship canon:
|
||||
|
||||
1. A scoped operator can run `warden sign` against `https://bao.coulomb.social`
|
||||
and record non-secret evidence.
|
||||
2. `SCOPE.md` and reassessment history reflect WP-0007 policy gate as implemented.
|
||||
3. Agent/workplan docs use State Hub task lifecycle (`wait` / `todo` / `progress`
|
||||
/ `done` / `cancel`).
|
||||
4. Finished workplans WP-0004–0007 are archived under `workplans/archived/`.
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
### T1 — Post-WP-0007 INTENT/SCOPE reassessment
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0008-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "05379da4-79d0-4742-8638-9e9565cccf72"
|
||||
```
|
||||
|
||||
- [x] Write `history/2026-06-17-post-wp0007-reassessment.md` (vector D5/A3/C4/R2)
|
||||
- [x] Update `SCOPE.md` — policy gate implemented, WP-0008 active
|
||||
- [x] Resolve remaining `PolicyGatedSigning.md (not implemented)` references in SCOPE/README
|
||||
|
||||
### T2 — Production OpenBao end-to-end sign verification
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0008-T02
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "b1a1831d-b2b3-4204-95f6-04dc7f29f67c"
|
||||
```
|
||||
|
||||
- [x] Operator provides scoped `VAULT_TOKEN` (warden-sign policy token)
|
||||
- [x] Confirm SSH engine mounted and roles per `wiki/OpenBaoSshEngineChecklist.md`
|
||||
- [x] Run `warden sign` + `warden status` + `warden log` against production OpenBao
|
||||
- [x] Append pass/fail evidence to `history/2026-06-17-openbao-production-verify.md`
|
||||
- [ ] Optional: cert_command smoke via ops-bridge tunnel — deferred; tunnels still
|
||||
static-key mode (`agt-claude-*`); wire when ops-bridge adopts `cert_command` for
|
||||
`agt-state-hub-bridge`
|
||||
|
||||
### T3 — State Hub task status canon migration
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0008-T03
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "876827c4-4a86-4e58-9a1f-ac87045dc903"
|
||||
```
|
||||
|
||||
- [x] Update `AGENTS.md` task status values and examples (`progress`, `wait`, `cancel`)
|
||||
- [x] Update `.claude/rules/workplan-convention.md` task block examples
|
||||
- [x] Mark state-hub interface change `649102a2-4373-4621-9848-cc257e67c262` resolved
|
||||
- [x] Reply to inbox message `c4072e5a-2afb-44ba-bfa2-7d4cb9979c6e` (read + note adaptation)
|
||||
|
||||
### T4 — Production config example and archive hygiene
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0008-T04
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "75b9f366-3d7a-419d-98ad-bc10ab90a697"
|
||||
```
|
||||
|
||||
- [x] Add `examples/warden.production.example.yaml` (no secrets; OpenBao addr + policy off)
|
||||
- [x] Archive finished workplans → `workplans/archived/260617-WARDEN-WP-000{4,5,6,7}-*.md`
|
||||
- [x] `make fix-consistency REPO=ops-warden` after archive
|
||||
|
||||
### T5 — flex-auth policy gate production readiness (coordination)
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0008-T05
|
||||
status: cancel
|
||||
priority: low
|
||||
state_hub_task_id: "03b412a5-5b99-42df-a154-733dd4156000"
|
||||
```
|
||||
|
||||
Spun out to **WARDEN-WP-0009** (flex-auth owner dependency). ops-warden gate code
|
||||
and docs shipped in WP-0007; production enablement waits on flex-auth policies.
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [x] Post-WP-0007 reassessment on file; SCOPE current
|
||||
- [x] Production `warden sign` evidence recorded (`history/2026-06-17-openbao-production-verify.md`)
|
||||
- [x] AGENTS.md uses canonical task statuses
|
||||
- [x] WP-0004–0007 archived; hub consistency pass
|
||||
- [x] Production example config committed (no secrets)
|
||||
|
||||
---
|
||||
|
||||
## Closeout (2026-06-18)
|
||||
|
||||
T1–T4 and T2 complete. T5 cancelled — continued in WARDEN-WP-0009. Optional
|
||||
ops-bridge `cert_command` smoke deferred until tunnel configs adopt warden signing.
|
||||
|
||||
---
|
||||
|
||||
## Dependencies
|
||||
|
||||
| Dependency | Owner | Blocks |
|
||||
| --- | --- | --- |
|
||||
| OpenBao SSH engine + host CA automation | NET-WP-0020 / railiance-* | T2 |
|
||||
| flex-auth ssh-certificate policies | flex-auth | T5 |
|
||||
| NK-WP-0009 SSH tutorial | net-kingdom + ops-warden | — (parallel track) |
|
||||
|
||||
---
|
||||
|
||||
## See also
|
||||
|
||||
- `history/2026-06-17-openbao-production-verify.md` — health probe (WP-0007)
|
||||
- `history/2026-06-17-post-wp0007-reassessment.md` — latest assessment
|
||||
- `examples/warden.production.example.yaml` — operator config template
|
||||
- `wiki/OpenBaoSshEngineChecklist.md`
|
||||
- `wiki/PolicyGatedSigning.md` — opt-in gate (implemented WP-0007)
|
||||
|
|
@ -0,0 +1,97 @@
|
|||
---
|
||||
id: WARDEN-WP-0009
|
||||
type: workplan
|
||||
title: "flex-auth Policy Gate Production Readiness"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: archived
|
||||
owner: codex
|
||||
topic_slug: custodian
|
||||
planning_priority: low
|
||||
planning_order: 9
|
||||
created: "2026-06-18"
|
||||
updated: "2026-06-23"
|
||||
state_hub_workstream_id: "9213b262-e2f5-480e-a5bc-56635d5eb4c9"
|
||||
---
|
||||
|
||||
> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`).
|
||||
|
||||
# WARDEN-WP-0009 — flex-auth Policy Gate Production Readiness
|
||||
|
||||
**Scope:** Enable and verify the opt-in flex-auth pre-sign gate (`policy.enabled`)
|
||||
in production after flex-auth publishes `ssh-certificate` resource policies.
|
||||
|
||||
**Out of scope:** flex-auth policy package authoring (flex-auth owner — delivered
|
||||
FLEX-WP-0006 2026-06-23); OpenBao SSH engine and host CA (complete — NET-WP-0020
|
||||
T5 / WP-0008 T2); in-cluster flex-auth deployment (continued in flex-auth
|
||||
`FLEX-WP-0007`).
|
||||
|
||||
**Spun out from:** WARDEN-WP-0008 T5 (2026-06-18 closeout).
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
### T1 — flex-auth policy package confirmation
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0009-T01
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "f988ed2e-0f63-4e89-abc4-183a7f23ddc2"
|
||||
```
|
||||
|
||||
- [x] Confirm flex-auth policies for resource type `ssh-certificate` exist
|
||||
- [x] Document tenant/subject bindings for `adm` / `agt` / `atm` sign paths
|
||||
- [x] Coordinate with flex-auth owner on deny/allow test fixtures
|
||||
|
||||
### T2 — Production enablement and smoke
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0009-T02
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "9d0fabc2-10ef-426d-a3d2-d4970d377029"
|
||||
```
|
||||
|
||||
- [x] Document operator steps to set `policy.enabled: true` (see `wiki/PolicyGatedSigning.md`)
|
||||
- [x] Local smoke — allow/deny paths with `policy_decision_id` / `ttl_out_of_bounds`
|
||||
- [x] Production registry slice from inventory (`registry/flex-auth/production_registry_snapshot.json`)
|
||||
- [x] Production registry smoke — allow `agt-state-hub-bridge` (`decision:032b096c433ad80c`)
|
||||
- [x] Production registry smoke — deny `--ttl 999` (`ttl_out_of_bounds`)
|
||||
|
||||
---
|
||||
|
||||
## Deliverables
|
||||
|
||||
| Artifact | Path |
|
||||
| --- | --- |
|
||||
| Registry builder | `scripts/build_flex_auth_registry.py` |
|
||||
| Production registry | `registry/flex-auth/production_registry_snapshot.json` |
|
||||
| Smoke runner | `scripts/policy_gate_production_smoke.sh` |
|
||||
| Local smoke evidence | `history/2026-06-23-flex-auth-policy-gate-local-smoke.md` |
|
||||
| Production smoke evidence | `history/2026-06-23-flex-auth-policy-gate-production-smoke.md` |
|
||||
| flex-auth pickup brief | `history/2026-06-23-flex-auth-production-pickup-suggestion.md` |
|
||||
|
||||
---
|
||||
|
||||
## Closeout (2026-06-23)
|
||||
|
||||
T1–T2 complete. ops-warden caller side and production-registry smoke verified.
|
||||
Production `policy.enabled: true` flip deferred until flex-auth runtime is
|
||||
reachable — tracked in flex-auth `FLEX-WP-0007`, not this workplan.
|
||||
|
||||
**Operator follow-up (FLEX-WP-0007):**
|
||||
|
||||
- Deploy registry + policy package to in-cluster flex-auth; set `policy.flex_auth_url`
|
||||
- Refresh scoped `VAULT_TOKEN` and run `SMOKE_VAULT=1 ./scripts/policy_gate_production_smoke.sh`
|
||||
- Set `policy.enabled: true` in `~/.config/warden/warden.yaml` when flex-auth is reachable
|
||||
|
||||
---
|
||||
|
||||
## See also
|
||||
|
||||
- `wiki/PolicyGatedSigning.md`
|
||||
- `~/flex-auth/docs/ops-warden-policy-gate-handoff.md`
|
||||
- `~/flex-auth/workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md`
|
||||
- `examples/warden.production.example.yaml`
|
||||
|
|
@ -0,0 +1,178 @@
|
|||
---
|
||||
id: WARDEN-WP-0010
|
||||
type: workplan
|
||||
title: "Access Routing — Charter and Pointer Catalog"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: archived
|
||||
owner: codex
|
||||
topic_slug: custodian
|
||||
planning_priority: high
|
||||
planning_order: 10
|
||||
created: "2026-06-18"
|
||||
updated: "2026-06-24"
|
||||
state_hub_workstream_id: "e93de9fd-0192-4d02-bb7c-5e859fb76b9b"
|
||||
---
|
||||
|
||||
> **Terminology note:** Historical text in this archived workplan may use the legacy term "workstream". The fleet term is **workplan** (`canon/standards/workplan-terminology-fleet_v0.1.md`).
|
||||
|
||||
# WARDEN-WP-0010 — Access Routing — Charter and Pointer Catalog
|
||||
|
||||
**Scope:** Sharpen the existing steward framing so it cannot be misread as a desk
|
||||
API that wraps every subsystem. ops-warden **issues SSH certificates** and
|
||||
**points workers to the owning subsystem** for everything else. This workplan
|
||||
updates INTENT/SCOPE wording and adds a machine-readable routing catalog that is
|
||||
a **pointer layer**, not a second copy of NetKingdom canon.
|
||||
|
||||
**Not a new security lane.** This is wording + a thin lookup surface. SSH issuance
|
||||
remains the only thing ops-warden executes. Maturity moves Availability A3 → A4
|
||||
(structured lookup for agents); Completeness and Reliability for SSH are unchanged.
|
||||
|
||||
**Out of scope:** Secret-vending, OIDC, policy PDP, tunnel, or host-hardening code
|
||||
in this repo; flex-auth policy packages (WARDEN-WP-0009); any universal broker.
|
||||
|
||||
**Depends on:** WARDEN-WP-0006 stewardship canon (routing wiki, security map) — shipped.
|
||||
|
||||
**Feeds:** WARDEN-WP-0011 (routing CLI over the catalog).
|
||||
|
||||
---
|
||||
|
||||
## Principles (target)
|
||||
|
||||
1. **Point, don't proxy** — Name the owner and the doc; do not wrap a foreign API
|
||||
unless the answer is an SSH certificate.
|
||||
2. **Direct interaction** — Workers (humans, agents, CI, operators) call OpenBao,
|
||||
key-cape, flex-auth, ops-bridge, and railiance repos themselves.
|
||||
3. **One source of truth** — Routing procedure for non-SSH needs lives in the wiki
|
||||
(aligned to net-kingdom canon) and upstream canon, **not** restated in the
|
||||
catalog. The catalog carries identifiers and pointers only. ops-warden authors
|
||||
procedure for exactly one lane: SSH certificate issuance, which it owns.
|
||||
4. **Same truth, two shapes** — Humans read the wiki; agents read the catalog. The
|
||||
catalog references wiki sections by anchor so they cannot drift apart.
|
||||
|
||||
---
|
||||
|
||||
## No-double-source rule (binding on T3)
|
||||
|
||||
The catalog must not contain step-by-step procedure for any subsystem ops-warden
|
||||
does not own. For non-SSH scenarios an entry carries:
|
||||
|
||||
- `owner_repo`, `subsystem` — who to talk to
|
||||
- `wiki_ref` — anchor into an in-repo wiki section (the authoritative restatement)
|
||||
- `canon_ref` — upstream net-kingdom doc the wiki section tracks
|
||||
- `need_keywords`, `title`, `id` — lookup metadata
|
||||
- `warden_executes: false`
|
||||
|
||||
Only `warden_executes: true` (SSH) entries may carry an authored `steps` block and
|
||||
the `cert_command` pattern — because that is the lane ops-warden owns. A CI test
|
||||
(WP-0011 T5) enforces this structurally: non-SSH entries with a `steps` block fail.
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
### T1 — INTENT wording
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0010-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "589081a6-d1f5-47b4-bec0-e82d9c3444f4"
|
||||
```
|
||||
|
||||
- [x] `INTENT.md` — keep "operational access steward"; replaced the "operational
|
||||
access **desk**" phrasing with plain "issues SSH certs and routes everything
|
||||
else to its owner." Removed metaphors implying a wrapping service.
|
||||
- [x] Non-goals: added "duplicating or restating another subsystem's procedure."
|
||||
- [x] Cross-linked this workplan from the assessment note.
|
||||
|
||||
> SCOPE.md (A3 → A4 plain statement + "issue vs route" table) is handled as a
|
||||
> deliberate manual step **after** the loop retires, not as a ralph task.
|
||||
|
||||
### T2 — Routing-role wiki page
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0010-T02
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "9ac333f7-5fc4-4fa2-82f3-d5ece8ff0d92"
|
||||
```
|
||||
|
||||
- [x] Create `wiki/AccessRouting.md` — what ops-warden answers (where + who owns
|
||||
it), what it executes (SSH only), anti-patterns (no `warden secret`,
|
||||
`warden login`, `warden policy`), and audience notes.
|
||||
- [x] Include the **issue-vs-route** matrix (subsystem × ops-warden role × who acts).
|
||||
- [x] Link from README, `CredentialRouting.md`, `NetKingdomSecurityMap.md`.
|
||||
|
||||
### T3 — Pointer catalog schema + seed
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0010-T03
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "59e0f480-694a-482a-b35e-b7bc4930aa41"
|
||||
```
|
||||
|
||||
- [x] Define `registry/routing/catalog.yaml` per the **No-double-source rule** above:
|
||||
`id`, `title`, `need_keywords`, `owner_repo`, `subsystem`, `warden_executes`,
|
||||
`wiki_ref`, `canon_ref`, `reviewed` (date), `status` (active|draft); plus
|
||||
`steps` + `cert_command` **only** when `warden_executes: true`.
|
||||
- [x] Seed from existing WP-0006 scenarios: SSH cert (executes), OpenBao API key,
|
||||
flex-auth policy, key-cape OIDC, ops-bridge tunnel, railiance-infra principals.
|
||||
- [x] Add `issue-core-ingestion-api-key` as `status: draft` (owner path TBD by
|
||||
railiance-platform) — draft entries are not surfaced by default lookup.
|
||||
- [x] Validated: 6 active + 1 draft, no non-SSH `steps`, every `wiki_ref` anchor resolves.
|
||||
|
||||
### T4 — Routing index in CredentialRouting.md
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0010-T04
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "aabd28c0-db2d-4267-be98-95be272c687d"
|
||||
```
|
||||
|
||||
- [x] Add a playbook index table to `wiki/CredentialRouting.md` keyed to catalog `id`.
|
||||
- [x] Add "what ops-warden answers vs what the worker does next on the owner system"
|
||||
examples — without restating the owner's procedure.
|
||||
- [x] Refresh the duplicate-interface anti-examples section (points at canonical
|
||||
anti-pattern table; not restated).
|
||||
|
||||
### T5 — Registry and repo-boundary alignment
|
||||
|
||||
```task
|
||||
id: WARDEN-WP-0010-T05
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "3335a689-922c-4319-98d0-4263ab13790b"
|
||||
```
|
||||
|
||||
- [x] Update `registry/capabilities/capability.security.ssh-certificate-issuance.md`
|
||||
— note routing lookup in discovery; target availability notes the routing CLI.
|
||||
- [x] Update `.claude/rules/repo-boundary.md` and `AGENTS.md` one-liner (no new
|
||||
metaphor — "issues SSH certs; routes other credential needs to their owner").
|
||||
- [x] Extend the existing capability entry rather than minting a second capability.
|
||||
|
||||
---
|
||||
|
||||
## Acceptance
|
||||
|
||||
- A reader of INTENT + `wiki/AccessRouting.md` understands ops-warden **issues** SSH
|
||||
certs and **routes** everything else, with no implication it proxies any API.
|
||||
- `registry/routing/catalog.yaml` exists with ≥6 active scenarios; every non-SSH
|
||||
entry has `wiki_ref` + `canon_ref` and **no** authored `steps`.
|
||||
- No new secret-storage or foreign-API code.
|
||||
|
||||
---
|
||||
|
||||
## See also
|
||||
|
||||
- `INTENT.md` · `SCOPE.md`
|
||||
- `history/2026-06-18-access-routing-intent-shift-assessment.md` — decision record
|
||||
- `WARDEN-WP-0011` — routing CLI
|
||||
- `WARDEN-WP-0012` — scenario playbook expansion (backlog)
|
||||
---
|
||||
|
||||
## Closeout (2026-06-24)
|
||||
|
||||
Archived during WARDEN-WP-0013 T2. All tasks complete.
|
||||
|
|
@ -0,0 +1,122 @@
|
|||
{
|
||||
"repo_slug": "access-engine",
|
||||
"repo_path": "/home/worsch/access-engine",
|
||||
"source_revision": "ca0cb75729a63c9288b7333382d0fa3eb1e8c9a3",
|
||||
"source_revision_reason": null,
|
||||
"issues": [
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-40",
|
||||
"message": "blocker satisfied, task still wait: 'FLEX-WP-ADHOC-2026-10-03-T02' in workplan 'FLEX-WP-ADHOC-2026-10-03' \u2014 every depends_on target is terminal (WARDEN-WP-0039-T03)",
|
||||
"file_path": "workplans/ADHOC-2026-10-03.md#FLEX-WP-ADHOC-2026-10-03-T02",
|
||||
"db_id": "",
|
||||
"file_value": "WARDEN-WP-0039-T03",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-40",
|
||||
"message": "blocker satisfied, task still wait: 'FLEX-WP-ADHOC-2026-10-03-T02' in workplan 'FLEX-WP-ADHOC-2026-10-03' \u2014 decision 877c268b-2089-42f1-a811-d98f549c1cb2 is resolved",
|
||||
"file_path": "workplans/ADHOC-2026-10-03.md#FLEX-WP-ADHOC-2026-10-03-T02",
|
||||
"db_id": "",
|
||||
"file_value": "877c268b-2089-42f1-a811-d98f549c1cb2",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-20",
|
||||
"message": "Workplan dependency target 'NK-WP-0024' is not linked to State Hub",
|
||||
"file_path": "workplans/FLEX-WP-0009-user-engine-production-policy-service.md",
|
||||
"db_id": "",
|
||||
"file_value": "NK-WP-0024",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-40",
|
||||
"message": "blocker satisfied, task still wait: 'FLEX-WP-0020-T11' in workplan 'FLEX-WP-0020' \u2014 decision e071b34e-c4d4-49d0-824d-2c58bb0ae496 is resolved",
|
||||
"file_path": "workplans/FLEX-WP-0020-repository-identity-migration.md#FLEX-WP-0020-T11",
|
||||
"db_id": "",
|
||||
"file_value": "e071b34e-c4d4-49d0-824d-2c58bb0ae496",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-22",
|
||||
"message": "Task description drift 'FLEX-WP-0024-T06': file content differs from DB (file wins)",
|
||||
"file_path": "workplans/FLEX-WP-0024-decision-envelope-authenticity.md#FLEX-WP-0024-T06",
|
||||
"db_id": "7f785b52-bf62-5884-8d34-670d70bc9023",
|
||||
"file_value": "Wait on Platform/OpenBao key custody, independent public-key and issuer/policy-pin\nadmission, exact image and existing-S",
|
||||
"db_value": "Wait on Platform/OpenBao key custody, independent public-key and issuer/policy-pin\nadmission, exact image and existing-S",
|
||||
"fixable": true
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-37",
|
||||
"message": "Residual workplan 'flex-wp-0031' has no origin/origin_ref provenance (not invented)",
|
||||
"file_path": "workplans/FLEX-WP-0031-decision-record-emission.md",
|
||||
"db_id": "84f5d9fe-b4c9-584a-b964-efe3e48af095",
|
||||
"file_value": "",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-39",
|
||||
"message": "Human wait task 'FLEX-WP-0036-T01' in workplan 'FLEX-WP-0036' has needs_human: true without decision_id \u2014 unrouted human gate",
|
||||
"file_path": "workplans/FLEX-WP-0036-runtime-rename-access-engine.md#FLEX-WP-0036-T01",
|
||||
"db_id": "",
|
||||
"file_value": "needs_human: true",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-39",
|
||||
"message": "Human wait task 'FLEX-WP-0036-T04' in workplan 'FLEX-WP-0036' has needs_human: true without decision_id \u2014 unrouted human gate",
|
||||
"file_path": "workplans/FLEX-WP-0036-runtime-rename-access-engine.md#FLEX-WP-0036-T04",
|
||||
"db_id": "",
|
||||
"file_value": "needs_human: true",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-28",
|
||||
"message": "5 unread inbox message(s) older than 3 day(s): ops-warden:9eab1dc9, net-kingdom:31561723, secrets-engine:fd77c280, the-custodian:23172cb2, the-custodian:51e9eace",
|
||||
"file_path": "",
|
||||
"db_id": "",
|
||||
"file_value": "",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-28",
|
||||
"message": "2 unread message(s) lack thread_id for supersession tracking: the-custodian:23172cb2, the-custodian:51e9eace",
|
||||
"file_path": "",
|
||||
"db_id": "",
|
||||
"file_value": "",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
}
|
||||
],
|
||||
"fixes_applied": [
|
||||
"bindings: synced 38/38",
|
||||
"C-17 cleared: pushed 1 backlogged commit(s)",
|
||||
"C-22 fixed: task 7f785b52\u2026 description updated",
|
||||
"brief: .custodian-brief.md updated",
|
||||
"push: pushed"
|
||||
],
|
||||
"summary": {
|
||||
"fail": 0,
|
||||
"automation_error": 0,
|
||||
"warn": 10,
|
||||
"info": 0
|
||||
},
|
||||
"result": "warn"
|
||||
}
|
||||
|
|
@ -0,0 +1 @@
|
|||
WARN: git commit failed for writeback: Generated-only commits rejected: staged
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
"""Prepare or apply the verified producer source without changing live admission."""
|
||||
from pathlib import Path
|
||||
import argparse
|
||||
import hashlib
|
||||
import json
|
||||
import re
|
||||
import subprocess
|
||||
|
||||
HERE = Path(__file__).resolve().parent
|
||||
PACKET = HERE.parents[1] / 'netkingdom-target-2026-10-17/apps-access-engine-integration-r2'
|
||||
OWNER = Path('/home/worsch/access-engine')
|
||||
BASE = 'd328a2601095686f74376d87791bff01e2a3a2a3'
|
||||
PLAN = 'workplans/FLEX-WP-0024-decision-envelope-authenticity.md'
|
||||
parser = argparse.ArgumentParser()
|
||||
parser.add_argument('action', choices=['prepare', 'apply'])
|
||||
args = parser.parse_args()
|
||||
|
||||
|
||||
def sha(raw):
|
||||
return hashlib.sha256(raw).hexdigest()
|
||||
|
||||
|
||||
def git(*argv):
|
||||
return subprocess.check_output(['git', '-C', str(OWNER), *argv], stderr=subprocess.PIPE).decode().strip()
|
||||
|
||||
|
||||
assert git('rev-parse', 'HEAD') == BASE
|
||||
files = []
|
||||
for item in sorted((PACKET / 'access-engine-source').rglob('*')):
|
||||
if not item.is_file():
|
||||
continue
|
||||
name = str(item.relative_to(PACKET / 'access-engine-source'))
|
||||
if name == 'examples/forgejo-application-access/registry.synthetic.json':
|
||||
continue # Only the recognized, tested registry snapshot is shipped.
|
||||
target = OWNER / name
|
||||
preimage = PACKET / 'preimages/access-engine' / name
|
||||
if target.exists():
|
||||
assert preimage.is_file() and target.read_bytes() == preimage.read_bytes(), name
|
||||
assert git('diff', 'HEAD', '--', name) == '', name
|
||||
files.append({'path': name, 'source': str(item), 'before_sha256': sha(target.read_bytes()) if target.exists() else None,
|
||||
'sha256': sha(item.read_bytes())})
|
||||
plan_before = (OWNER / PLAN).read_bytes()
|
||||
plan_after = plan_before.decode().replace('updated: "2026-10-16"', 'updated: "2026-10-18"', 1)
|
||||
plan_after += '''
|
||||
|
||||
2026-10-18 source implementation under CUST-WP-0080 / NK-WP-0048-T43:
|
||||
the producer-owned normal Check client now authenticates exact policy/registry/
|
||||
caller/request/lifetime bindings with a nonce and the optional lossless JSON
|
||||
profile. The default legacy decoder and unchanged signature/API contract remain
|
||||
intact. Root pkg/decisionpep is the source of truth; its Go1.24 consumer slice is
|
||||
generated by tools/export_decisionpep_adapter.py and checked by ordinary tests.
|
||||
The Forgejo example uses authoritative registry tenant/issuer facts and verified
|
||||
runtime identity in the admitted caller's request context. Actual producer
|
||||
regressions reproduce/refuse object-shaped group inputs; policy fixtures and
|
||||
Rego tests validate the original three-group contract. Full isolated root race
|
||||
suite: 494 test/subtest passes, three existing optional/fixture skips. Export
|
||||
parity and final group-shape regressions pass. Detailed source pins and retained
|
||||
failures are in Custodian apps-access-engine-integration-r2.
|
||||
|
||||
This is source delivery, not owner assent or native admission. Synthetic keys,
|
||||
registry and local callback proof establish no live signer/caller/policy grant.
|
||||
Existing rollout R2/image84 and their approvals remain frozen; they do not admit
|
||||
this source or a new image. T06 and all native custody/trust/rollout/recovery gates
|
||||
remain open. Forgejo's complete resource/operation/inverse and session-revocation
|
||||
coverage remains NK48-T43 / RAPPS16-T09 work.
|
||||
'''
|
||||
assert re.findall(r'```task\n.*?```', plan_before.decode(), re.S) == re.findall(r'```task\n.*?```', plan_after, re.S)
|
||||
files.append({'path': PLAN, 'source': str(HERE / 'workplan.postimage.md'), 'before_sha256': sha(plan_before), 'sha256': sha(plan_after.encode())})
|
||||
protected = []
|
||||
for name in ['.custodian-brief.md', 'WORK-RECORDS.md']:
|
||||
protected.append({'path': name, 'sha256': sha((OWNER / name).read_bytes()), 'index': git('ls-files', '--stage', '--', name)})
|
||||
|
||||
if args.action == 'prepare':
|
||||
assert not (HERE / 'source-manifest.json').exists()
|
||||
race = json.loads((PACKET / 'producer-race-result.json').read_text())
|
||||
assert race['returncode'] == 0
|
||||
assert json.loads((PACKET / 'shapes-after.json').read_text())['returncode'] == 0
|
||||
assert json.loads((PACKET / 'producer-layer-check.json').read_text())['returncode'] == 0
|
||||
(HERE / 'workplan.preimage.md').write_bytes(plan_before)
|
||||
(HERE / 'workplan.postimage.md').write_text(plan_after)
|
||||
(HERE / 'source-manifest.json').write_text(json.dumps({'base': BASE, 'files': files, 'protected': protected,
|
||||
'native_changes': False, 'formal_owner_assent': False}, indent=2) + '\n')
|
||||
(HERE / 'publication-inputs.json').write_text(json.dumps({'owner': 'access-engine', 'base_revision': BASE,
|
||||
'message': 'Add producer-owned authenticated Go decision client and validated Forgejo profile',
|
||||
'files': [{'path': row['path'], 'sha256': row['sha256']} for row in files]}, indent=2) + '\n')
|
||||
print(json.dumps({'status': 'prepared', 'files': len(files), 'native_changes': False}))
|
||||
else:
|
||||
manifest = json.loads((HERE / 'source-manifest.json').read_text())
|
||||
assert files == manifest['files'] and protected == manifest['protected']
|
||||
for row in files:
|
||||
assert sha(Path(row['source']).read_bytes()) == row['sha256'], row['path']
|
||||
for row in files:
|
||||
target = OWNER / row['path']
|
||||
target.parent.mkdir(parents=True, exist_ok=True)
|
||||
target.write_bytes(Path(row['source']).read_bytes())
|
||||
for row in protected:
|
||||
assert sha((OWNER / row['path']).read_bytes()) == row['sha256']
|
||||
assert git('ls-files', '--stage', '--', row['path']) == row['index']
|
||||
(HERE / 'source-application.json').write_text(json.dumps({'status': 'applied', 'files': len(files), 'base': BASE,
|
||||
'native_changes': False, 'protected_worktree_and_index_preserved': True, 'formal_owner_assent': False}, indent=2) + '\n')
|
||||
print(json.dumps({'status': 'applied', 'files': len(files), 'native_changes': False}))
|
||||
|
|
@ -0,0 +1,374 @@
|
|||
{
|
||||
"ok": true,
|
||||
"status": "applied",
|
||||
"repo_slug": "access-engine",
|
||||
"commit": "ca0cb75729a63c9288b7333382d0fa3eb1e8c9a3",
|
||||
"requests": 2,
|
||||
"elapsed_ms": 4844.8,
|
||||
"git": {
|
||||
"upstream": "origin/main",
|
||||
"behind": 0,
|
||||
"ahead": 0
|
||||
},
|
||||
"identifiers": {
|
||||
"schema": "repo-manager.identifier-assignment.v1",
|
||||
"ok": true,
|
||||
"executed": true,
|
||||
"repo": "access-engine",
|
||||
"namespace": "helixforge",
|
||||
"assignments": [],
|
||||
"historical_invalid_identifiers": [],
|
||||
"historical_identity_collisions": [],
|
||||
"files_changed": []
|
||||
},
|
||||
"receipt": {
|
||||
"schema": "state-hub.repository-projection-reconcile.v1",
|
||||
"instance_role": "primary",
|
||||
"instance_label": "railiance01",
|
||||
"expected_commit": "ca0cb75729a63c9288b7333382d0fa3eb1e8c9a3",
|
||||
"derived_commit": "ca0cb75729a63c9288b7333382d0fa3eb1e8c9a3",
|
||||
"outcome": {
|
||||
"schema": "state-hub.projection-reset.v1",
|
||||
"repo_slug": "access-engine",
|
||||
"commit": "ca0cb75729a63c9288b7333382d0fa3eb1e8c9a3",
|
||||
"status": "applied",
|
||||
"counts": {
|
||||
"created": 0,
|
||||
"updated": 38,
|
||||
"retired": 0,
|
||||
"refused": 0,
|
||||
"released": 0,
|
||||
"created_tasks": 0,
|
||||
"updated_tasks": 0,
|
||||
"cancelled_tasks": 0,
|
||||
"created_edges": 0,
|
||||
"removed_edges": 0,
|
||||
"unresolved_edges": 0,
|
||||
"external_edges": 27
|
||||
},
|
||||
"created": [],
|
||||
"updated": [
|
||||
"FLEX-WP-0001",
|
||||
"FLEX-WP-0002",
|
||||
"FLEX-WP-0003",
|
||||
"FLEX-WP-0004",
|
||||
"FLEX-WP-0005",
|
||||
"FLEX-WP-0006",
|
||||
"FLEX-WP-0007",
|
||||
"FLEX-WP-0008",
|
||||
"FLEX-WP-0009",
|
||||
"FLEX-WP-0010",
|
||||
"FLEX-WP-0011",
|
||||
"FLEX-WP-0012",
|
||||
"FLEX-WP-0013",
|
||||
"FLEX-WP-0014",
|
||||
"FLEX-WP-0015",
|
||||
"FLEX-WP-0016",
|
||||
"FLEX-WP-0017",
|
||||
"FLEX-WP-0018",
|
||||
"FLEX-WP-0019",
|
||||
"FLEX-WP-0020",
|
||||
"FLEX-WP-0021",
|
||||
"FLEX-WP-0022",
|
||||
"FLEX-WP-0023",
|
||||
"FLEX-WP-0024",
|
||||
"FLEX-WP-0025",
|
||||
"FLEX-WP-0026",
|
||||
"FLEX-WP-0027",
|
||||
"FLEX-WP-0028",
|
||||
"FLEX-WP-0029",
|
||||
"FLEX-WP-0030",
|
||||
"FLEX-WP-0031",
|
||||
"FLEX-WP-0032",
|
||||
"FLEX-WP-0033",
|
||||
"FLEX-WP-0034",
|
||||
"FLEX-WP-0035",
|
||||
"FLEX-WP-0036",
|
||||
"FLEX-WP-ADHOC-2026-10-03",
|
||||
"FLEX-WP-ADHOC-2026-10-11"
|
||||
],
|
||||
"retired": [],
|
||||
"released": [],
|
||||
"created_tasks": [],
|
||||
"updated_tasks": [],
|
||||
"cancelled_tasks": [],
|
||||
"created_edges": [],
|
||||
"removed_edges": [],
|
||||
"unresolved_edges": [],
|
||||
"external_edges": [
|
||||
{
|
||||
"workplan": "FLEX-WP-0008",
|
||||
"from": "FLEX-WP-0008",
|
||||
"target": "FLEX-WP-0007",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "1358db95-967c-5a03-8b8c-4816dc106594",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "358ce697-2611-4fe9-89ab-63e86ceb00fa",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0007",
|
||||
"from": "FLEX-WP-0007",
|
||||
"target": "FLEX-WP-0006",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "358ce697-2611-4fe9-89ab-63e86ceb00fa",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "bbea4049-8acc-4d7c-8cf5-3106c6b93f7f",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0013",
|
||||
"from": "FLEX-WP-0013",
|
||||
"target": "FLEX-WP-0011",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "6f22ded6-a69c-531b-bfa6-2f8d5c886979",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "deda35b4-f41d-559e-954e-a75f29237f68",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0013",
|
||||
"from": "FLEX-WP-0013",
|
||||
"target": "FLEX-WP-0010",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "6f22ded6-a69c-531b-bfa6-2f8d5c886979",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "fdabae84-dc9e-5ccd-81df-8ae7e66b90b8",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0014",
|
||||
"from": "FLEX-WP-0014",
|
||||
"target": "FLEX-WP-0013",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "7de17bd2-5e7c-5355-ba1d-40a051a67746",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "6f22ded6-a69c-531b-bfa6-2f8d5c886979",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0014",
|
||||
"from": "FLEX-WP-0014",
|
||||
"target": "FLEX-WP-0010",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "7de17bd2-5e7c-5355-ba1d-40a051a67746",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "fdabae84-dc9e-5ccd-81df-8ae7e66b90b8",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0022",
|
||||
"from": "FLEX-WP-0022",
|
||||
"target": "FLEX-WP-0021",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "804c588c-f47a-50c4-bdd7-51b24bbf9539",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "b01f655e-f71a-50ae-b110-178557f07c63",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0031",
|
||||
"from": "FLEX-WP-0031-T04",
|
||||
"target": "FLEX-WP-0031-T06",
|
||||
"relationship_type": "starts_after",
|
||||
"from_workplan_id": "84f5d9fe-b4c9-584a-b964-efe3e48af095",
|
||||
"from_task_id": "423b3090-1b72-58fd-9353-5c907c7683bb",
|
||||
"to_workplan_id": null,
|
||||
"to_task_id": "bf92a951-3b69-59dd-8907-f6748c91a264"
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0031",
|
||||
"from": "FLEX-WP-0031-T06",
|
||||
"target": "FLEX-WP-0031-T02",
|
||||
"relationship_type": "starts_after",
|
||||
"from_workplan_id": "84f5d9fe-b4c9-584a-b964-efe3e48af095",
|
||||
"from_task_id": "bf92a951-3b69-59dd-8907-f6748c91a264",
|
||||
"to_workplan_id": null,
|
||||
"to_task_id": "89661908-ca9a-5e4a-a0a5-62d1a9e02568"
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0024",
|
||||
"from": "FLEX-WP-0024",
|
||||
"target": "FLEX-WP-0021",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "90577acd-6910-548d-a13e-1dbfdfb8ed27",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "b01f655e-f71a-50ae-b110-178557f07c63",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0004",
|
||||
"from": "FLEX-WP-0004",
|
||||
"target": "FLEX-WP-0002",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "99a82976-d376-42b0-89cc-c44e01c0bec6",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "aa60e183-9a87-4e03-99b0-15786bfa11ae",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0002",
|
||||
"from": "FLEX-WP-0002",
|
||||
"target": "FLEX-WP-0001",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "aa60e183-9a87-4e03-99b0-15786bfa11ae",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "4dbefd19-bb7d-405c-9a50-e7dbd11cf4d9",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0002",
|
||||
"from": "FLEX-WP-0002",
|
||||
"target": "FLEX-WP-0005",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "aa60e183-9a87-4e03-99b0-15786bfa11ae",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "e37d42a9-0018-4a67-a672-ff4e9716b338",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0023",
|
||||
"from": "FLEX-WP-0023",
|
||||
"target": "FLEX-WP-0021",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "ad011f92-786c-51ad-b3f6-c06ad77e7af7",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "b01f655e-f71a-50ae-b110-178557f07c63",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0036",
|
||||
"from": "FLEX-WP-0036-T03",
|
||||
"target": "RPF-WP-0044-T07",
|
||||
"relationship_type": "starts_after",
|
||||
"from_workplan_id": "af0f8d77-af04-569b-8e79-6c47eb8f1087",
|
||||
"from_task_id": "487525e5-c89e-586e-8e9b-54ac6da0804e",
|
||||
"to_workplan_id": null,
|
||||
"to_task_id": "844ff115-def2-55ca-ab01-413ba7e6857d"
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0036",
|
||||
"from": "FLEX-WP-0036-T03",
|
||||
"target": "FLEX-WP-0036-T04",
|
||||
"relationship_type": "starts_after",
|
||||
"from_workplan_id": "af0f8d77-af04-569b-8e79-6c47eb8f1087",
|
||||
"from_task_id": "487525e5-c89e-586e-8e9b-54ac6da0804e",
|
||||
"to_workplan_id": null,
|
||||
"to_task_id": "ff7fd369-326f-5044-aaa4-96c5f45c80e9"
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0021",
|
||||
"from": "FLEX-WP-0021",
|
||||
"target": "FLEX-WP-0012",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "b01f655e-f71a-50ae-b110-178557f07c63",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "2a6b5764-1831-5305-b46e-0991d02675df",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0021",
|
||||
"from": "FLEX-WP-0021",
|
||||
"target": "FLEX-WP-0016",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "b01f655e-f71a-50ae-b110-178557f07c63",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "f29f159c-c79e-5c78-b1e8-569a5b63d231",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0006",
|
||||
"from": "FLEX-WP-0006",
|
||||
"target": "FLEX-WP-0002",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "bbea4049-8acc-4d7c-8cf5-3106c6b93f7f",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "aa60e183-9a87-4e03-99b0-15786bfa11ae",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0006",
|
||||
"from": "FLEX-WP-0006",
|
||||
"target": "FLEX-WP-0005",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "bbea4049-8acc-4d7c-8cf5-3106c6b93f7f",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "e37d42a9-0018-4a67-a672-ff4e9716b338",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0003",
|
||||
"from": "FLEX-WP-0003",
|
||||
"target": "FLEX-WP-0002",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "c0a6c9f6-bb6b-416d-b537-f30504c63d75",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "aa60e183-9a87-4e03-99b0-15786bfa11ae",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0011",
|
||||
"from": "FLEX-WP-0011",
|
||||
"target": "FLEX-WP-0009",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "deda35b4-f41d-559e-954e-a75f29237f68",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "390da58d-3c58-5102-bd3c-7133956c810e",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0005",
|
||||
"from": "FLEX-WP-0005",
|
||||
"target": "FLEX-WP-0001",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "e37d42a9-0018-4a67-a672-ff4e9716b338",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "4dbefd19-bb7d-405c-9a50-e7dbd11cf4d9",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0016",
|
||||
"from": "FLEX-WP-0016",
|
||||
"target": "FLEX-WP-0007",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "f29f159c-c79e-5c78-b1e8-569a5b63d231",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "358ce697-2611-4fe9-89ab-63e86ceb00fa",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0016",
|
||||
"from": "FLEX-WP-0016",
|
||||
"target": "FLEX-WP-0015",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "f29f159c-c79e-5c78-b1e8-569a5b63d231",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "43fe348c-02b9-5d5d-af37-a2d80cfc6e1d",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0025",
|
||||
"from": "FLEX-WP-0025",
|
||||
"target": "FLEX-WP-0021",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "f9a657ce-67b4-5d25-9933-e0fcb2c20b1c",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "b01f655e-f71a-50ae-b110-178557f07c63",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "FLEX-WP-0010",
|
||||
"from": "FLEX-WP-0010",
|
||||
"target": "FLEX-WP-0008",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "fdabae84-dc9e-5ccd-81df-8ae7e66b90b8",
|
||||
"from_task_id": null,
|
||||
"to_workplan_id": "1358db95-967c-5a03-8b8c-4816dc106594",
|
||||
"to_task_id": null
|
||||
}
|
||||
],
|
||||
"refused": [],
|
||||
"notes": []
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,67 @@
|
|||
<!-- custodian-brief: generated by fix-consistency — do not edit manually -->
|
||||
# Custodian Brief — access-engine
|
||||
|
||||
**Domain:** infotech
|
||||
**Last synced:** 2026-10-16 14:30 UTC
|
||||
**State Hub:** http://127.0.0.1:8000 *(adjust if running on a remote machine)*
|
||||
|
||||
## Active Workstreams
|
||||
|
||||
### Sign the decision envelope: the response channel is unauthenticated
|
||||
Progress: 5/6 done | workplan_id: `90577acd-6910-548d-a13e-1dbfdfb8ed27`
|
||||
|
||||
**Open tasks:**
|
||||
- ► 6. Admit custody, consumer trust, exact packages and native signed decisions `7f785b52`
|
||||
|
||||
### The decision record has a declared emission guarantee and nothing that delivers it
|
||||
Progress: 5/9 done | workplan_id: `84f5d9fe-b4c9-584a-b964-efe3e48af095`
|
||||
|
||||
**Open tasks:**
|
||||
- ! 2. Register flex-auth as an audit-core sender `89661908`
|
||||
*(wait: GH-WP-0004-T12 refused the load-bearing failure-path exception (GH-DEC-2026-024). AUDIT-IN-0006 sender rows and governed token delivery remain pending.)*
|
||||
- ! 4. Close G2 `423b3090`
|
||||
*(wait: G2 needs T08 native heartbeat/drain and silence-finding evidence plus T06 reconciliation; local tests cannot close the delivery gap.)*
|
||||
- ! 6. Reconciliation, profile check, and storage `bf92a951`
|
||||
*(wait: Receiver counts use accepted_at, while local counts use commit time; audit-core must supply compatible window semantics or durable acceptance timestamps before a valid comparator can be implemented.)*
|
||||
- ! 8. Admit and exercise native heartbeat/drain delivery `b3b52b30`
|
||||
*(wait: Needs admitted sender/token mounts, founder approval of exact image/PVC/network rollout, and audit-core observer evidence; no production delivery is enabled.)*
|
||||
|
||||
### Runtime rename: flex-auth to access-engine, run side by side, consumers switch one at a time
|
||||
Progress: 0/8 done | workplan_id: `af0f8d77-af04-569b-8e79-6c47eb8f1087`
|
||||
|
||||
**Open tasks:**
|
||||
- ! Decide the target names and supersede the retain table `4f9a796d`
|
||||
- ! Make the PDP accept both names `487525e5`
|
||||
- ! Rename the source `ff7fd369`
|
||||
- ! Stand up the access-engine namespace next to flex-auth `13b93d7a`
|
||||
- ! Consumers switch over, one at a time `f0470e5c`
|
||||
- ► Inventory every consumer reference and open handoffs `8f597899`
|
||||
- · Retire the flex-auth runtime `e46c9c8e`
|
||||
- … and 1 more open tasks
|
||||
|
||||
### Repository identity migration from flex-auth to access-engine
|
||||
Progress: 10/11 done | workplan_id: `99a661a8-b36c-5c1c-b78b-1e8930bcd0a9`
|
||||
|
||||
**Open tasks:**
|
||||
- ! 11. Soak, hand off residuals, and clean up the old checkout `46d8318b`
|
||||
*(wait: Cleanup approved conditionally (e071b34e): runs once the listed soak evidence, SBOM-IN-0001 receipt and residual handoffs exist.)*
|
||||
|
||||
### 2026-10-03 secret-read evaluator for ops-warden fetch checks
|
||||
Progress: 1/2 done | workplan_id: `60941288-d1f8-58fe-ad38-d508b7d5eac2`
|
||||
|
||||
**Open tasks:**
|
||||
- ! Deploy the pin (founder go required) `aa00b29f`
|
||||
*(wait: Install accepted retroactively (877c268b); steps 6-7 follow WARDEN-WP-0039-T03 token receipts and fetch URL.)*
|
||||
|
||||
## Inbox Hygiene
|
||||
|
||||
**Stale unread:** 5 message(s) older than 3 day(s) — triage at session start.
|
||||
**Missing thread_id:** 2 unread message(s) lack supersession chains.
|
||||
|
||||
---
|
||||
## MCP Orientation (when available)
|
||||
|
||||
If the state-hub MCP server is reachable, call:
|
||||
`get_domain_summary("infotech")`
|
||||
This provides richer cross-domain context.
|
||||
If the MCP call fails, use this file as your orientation source.
|
||||
|
|
@ -0,0 +1,236 @@
|
|||
# Work Records — access-engine
|
||||
|
||||
> Generated by `statehub fix-consistency` (CUST-WP-0061-T04, work-record
|
||||
> stage 3). Do not edit by hand — edit the source file/block listed for
|
||||
> each record and re-run fix-consistency to refresh this index. Archived
|
||||
> workplans are omitted; closed decisions/intakes/engagements stay listed
|
||||
> so recently-resolved work is still visible. [auto]
|
||||
|
||||
| Kind | ID | Status | Lane | Source |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| workplan | FLEX-WP-ADHOC-2026-10-03 | blocked | — | workplans/ADHOC-2026-10-03.md |
|
||||
| workplan | FLEX-WP-ADHOC-2026-10-11 | finished | — | workplans/ADHOC-2026-10-11.md |
|
||||
| workplan | FLEX-WP-0001 | done | — | workplans/FLEX-WP-0001-repo-intent-and-architecture-baseline.md |
|
||||
| workplan | FLEX-WP-0002 | completed | — | workplans/FLEX-WP-0002-standalone-policy-as-code-core.md |
|
||||
| workplan | FLEX-WP-0003 | completed | — | workplans/FLEX-WP-0003-markitect-consumer-integration.md |
|
||||
| workplan | FLEX-WP-0004 | completed | — | workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md |
|
||||
| workplan | FLEX-WP-0005 | done | — | workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md |
|
||||
| workplan | FLEX-WP-0006 | finished | — | workplans/FLEX-WP-0006-ops-warden-ssh-signing-policy-gate.md |
|
||||
| workplan | FLEX-WP-0007 | finished | — | workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md |
|
||||
| workplan | FLEX-WP-0008 | finished | — | workplans/FLEX-WP-0008-tenant-engine-consumer-integration.md |
|
||||
| workplan | FLEX-WP-0009 | finished | — | workplans/FLEX-WP-0009-user-engine-production-policy-service.md |
|
||||
| workplan | FLEX-WP-0010 | finished | — | workplans/FLEX-WP-0010-tenant-lifecycle-policy-actions.md |
|
||||
| workplan | FLEX-WP-0011 | finished | — | workplans/FLEX-WP-0011-railiance-staged-promotion-overlay.md |
|
||||
| workplan | FLEX-WP-0012 | finished | — | workplans/FLEX-WP-0012-credential-grant-authorization-surface.md |
|
||||
| workplan | FLEX-WP-0013 | finished | — | workplans/FLEX-WP-0013-restore-seven-action-tenant-engine-pin.md |
|
||||
| workplan | FLEX-WP-0014 | finished | — | workplans/FLEX-WP-0014-tenant-guardrail-policy-actions.md |
|
||||
| workplan | FLEX-WP-0015 | finished | — | workplans/FLEX-WP-0015-tenancy-posture-conformance.md |
|
||||
| workplan | FLEX-WP-0016 | finished | — | workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md |
|
||||
| workplan | FLEX-WP-0017 | finished | — | workplans/FLEX-WP-0017-action-bound-authorization-contract.md |
|
||||
| workplan | FLEX-WP-0018 | finished | — | workplans/FLEX-WP-0018-inbound-auth-corrections.md |
|
||||
| workplan | FLEX-WP-0019 | finished | — | workplans/FLEX-WP-0019-layer-model-conformance.md |
|
||||
| workplan | FLEX-WP-0020 | blocked | — | workplans/FLEX-WP-0020-repository-identity-migration.md |
|
||||
| workplan | FLEX-WP-0021 | finished | — | workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md |
|
||||
| workplan | FLEX-WP-0022 | finished | — | workplans/FLEX-WP-0022-tenant-scope-coverage.md |
|
||||
| workplan | FLEX-WP-0023 | finished | — | workplans/FLEX-WP-0023-operator-caller-access-path.md |
|
||||
| workplan | FLEX-WP-0024 | active | — | workplans/FLEX-WP-0024-decision-envelope-authenticity.md |
|
||||
| workplan | FLEX-WP-0025 | finished | — | workplans/FLEX-WP-0025-fact-versus-assertion.md |
|
||||
| workplan | FLEX-WP-0026 | finished | — | workplans/FLEX-WP-0026-openrouter-native-contract.md |
|
||||
| workplan | FLEX-WP-0027 | finished | — | workplans/FLEX-WP-0027-t03-human-review.md |
|
||||
| workplan | FLEX-WP-0028 | finished | — | workplans/FLEX-WP-0028-compact-sitting-review.md |
|
||||
| workplan | FLEX-WP-0029 | finished | — | workplans/FLEX-WP-0029-stance-register-second-edition.md |
|
||||
| workplan | FLEX-WP-0030 | finished | — | workplans/FLEX-WP-0030-boundary-declaration-cleanup.md |
|
||||
| workplan | FLEX-WP-0031 | active | — | workplans/FLEX-WP-0031-decision-record-emission.md |
|
||||
| workplan | FLEX-WP-0032 | finished | — | workplans/FLEX-WP-0032-informed-decision-list-action.md |
|
||||
| workplan | FLEX-WP-0033 | finished | — | workplans/FLEX-WP-0033-informed-decision-lifecycle.md |
|
||||
| workplan | FLEX-WP-0034 | finished | — | workplans/FLEX-WP-0034-informed-decision-review-discovery.md |
|
||||
| workplan | FLEX-WP-0035 | finished | — | workplans/FLEX-WP-0035-per-identity-application-readback.md |
|
||||
| workplan | FLEX-WP-0036 | active | — | workplans/FLEX-WP-0036-runtime-rename-access-engine.md |
|
||||
| task | FLEX-WP-ADHOC-2026-10-03-T01 | done | — | workplans/ADHOC-2026-10-03.md |
|
||||
| task | FLEX-WP-ADHOC-2026-10-03-T02 | wait | — | workplans/ADHOC-2026-10-03.md |
|
||||
| task | FLEX-WP-ADHOC-2026-10-11-T01 | done | — | workplans/ADHOC-2026-10-11.md |
|
||||
| task | FLEX-WP-ADHOC-2026-10-11-T02 | done | — | workplans/ADHOC-2026-10-11.md |
|
||||
| task | FLEX-WP-ADHOC-2026-10-11-T03 | done | — | workplans/ADHOC-2026-10-11.md |
|
||||
| task | FLEX-WP-ADHOC-2026-10-11-T04 | done | — | workplans/ADHOC-2026-10-11.md |
|
||||
| task | FLEX-WP-ADHOC-2026-10-11-T05 | done | — | workplans/ADHOC-2026-10-11.md |
|
||||
| task | FLEX-WP-0001-T001 | done | — | workplans/FLEX-WP-0001-repo-intent-and-architecture-baseline.md |
|
||||
| task | FLEX-WP-0001-T002 | done | — | workplans/FLEX-WP-0001-repo-intent-and-architecture-baseline.md |
|
||||
| task | FLEX-WP-0001-T003 | done | — | workplans/FLEX-WP-0001-repo-intent-and-architecture-baseline.md |
|
||||
| task | FLEX-WP-0001-T004 | done | — | workplans/FLEX-WP-0001-repo-intent-and-architecture-baseline.md |
|
||||
| task | FLEX-WP-0002-T001 | done | — | workplans/FLEX-WP-0002-standalone-policy-as-code-core.md |
|
||||
| task | FLEX-WP-0002-T002 | done | — | workplans/FLEX-WP-0002-standalone-policy-as-code-core.md |
|
||||
| task | FLEX-WP-0002-T003 | done | — | workplans/FLEX-WP-0002-standalone-policy-as-code-core.md |
|
||||
| task | FLEX-WP-0002-T004 | done | — | workplans/FLEX-WP-0002-standalone-policy-as-code-core.md |
|
||||
| task | FLEX-WP-0002-T005 | done | — | workplans/FLEX-WP-0002-standalone-policy-as-code-core.md |
|
||||
| task | FLEX-WP-0002-T006 | done | — | workplans/FLEX-WP-0002-standalone-policy-as-code-core.md |
|
||||
| task | FLEX-WP-0002-T007 | done | — | workplans/FLEX-WP-0002-standalone-policy-as-code-core.md |
|
||||
| task | FLEX-WP-0002-T008 | done | — | workplans/FLEX-WP-0002-standalone-policy-as-code-core.md |
|
||||
| task | FLEX-WP-0003-T001 | done | — | workplans/FLEX-WP-0003-markitect-consumer-integration.md |
|
||||
| task | FLEX-WP-0003-T002 | done | — | workplans/FLEX-WP-0003-markitect-consumer-integration.md |
|
||||
| task | FLEX-WP-0003-T003 | done | — | workplans/FLEX-WP-0003-markitect-consumer-integration.md |
|
||||
| task | FLEX-WP-0003-T004 | done | — | workplans/FLEX-WP-0003-markitect-consumer-integration.md |
|
||||
| task | FLEX-WP-0003-T005 | done | — | workplans/FLEX-WP-0003-markitect-consumer-integration.md |
|
||||
| task | FLEX-WP-0003-T006 | done | — | workplans/FLEX-WP-0003-markitect-consumer-integration.md |
|
||||
| task | FLEX-WP-0004-T001 | done | — | workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md |
|
||||
| task | FLEX-WP-0004-T002 | done | — | workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md |
|
||||
| task | FLEX-WP-0004-T003 | done | — | workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md |
|
||||
| task | FLEX-WP-0004-T004 | done | — | workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md |
|
||||
| task | FLEX-WP-0004-T005 | done | — | workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md |
|
||||
| task | FLEX-WP-0004-T006 | done | — | workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md |
|
||||
| task | FLEX-WP-0005-T001 | done | — | workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md |
|
||||
| task | FLEX-WP-0005-T002 | done | — | workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md |
|
||||
| task | FLEX-WP-0005-T003 | done | — | workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md |
|
||||
| task | FLEX-WP-0005-T004 | done | — | workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md |
|
||||
| task | FLEX-WP-0005-T005 | done | — | workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md |
|
||||
| task | FLEX-WP-0005-T006 | done | — | workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md |
|
||||
| task | FLEX-WP-0006-T01 | done | — | workplans/FLEX-WP-0006-ops-warden-ssh-signing-policy-gate.md |
|
||||
| task | FLEX-WP-0006-T02 | done | — | workplans/FLEX-WP-0006-ops-warden-ssh-signing-policy-gate.md |
|
||||
| task | FLEX-WP-0006-T03 | done | — | workplans/FLEX-WP-0006-ops-warden-ssh-signing-policy-gate.md |
|
||||
| task | FLEX-WP-0006-T04 | done | — | workplans/FLEX-WP-0006-ops-warden-ssh-signing-policy-gate.md |
|
||||
| task | FLEX-WP-0006-T05 | done | — | workplans/FLEX-WP-0006-ops-warden-ssh-signing-policy-gate.md |
|
||||
| task | FLEX-WP-0007-T01 | done | — | workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md |
|
||||
| task | FLEX-WP-0007-T02 | done | — | workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md |
|
||||
| task | FLEX-WP-0007-T03 | done | — | workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md |
|
||||
| task | FLEX-WP-0007-T04 | done | — | workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md |
|
||||
| task | FLEX-WP-0007-T05 | done | — | workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md |
|
||||
| task | FLEX-WP-0008-T01 | done | — | workplans/FLEX-WP-0008-tenant-engine-consumer-integration.md |
|
||||
| task | FLEX-WP-0008-T02 | done | — | workplans/FLEX-WP-0008-tenant-engine-consumer-integration.md |
|
||||
| task | FLEX-WP-0008-T03 | done | — | workplans/FLEX-WP-0008-tenant-engine-consumer-integration.md |
|
||||
| task | FLEX-WP-0008-T04 | done | — | workplans/FLEX-WP-0008-tenant-engine-consumer-integration.md |
|
||||
| task | FLEX-WP-0009-T01 | done | — | workplans/FLEX-WP-0009-user-engine-production-policy-service.md |
|
||||
| task | FLEX-WP-0009-T02 | done | — | workplans/FLEX-WP-0009-user-engine-production-policy-service.md |
|
||||
| task | FLEX-WP-0009-T03 | done | — | workplans/FLEX-WP-0009-user-engine-production-policy-service.md |
|
||||
| task | FLEX-WP-0009-T04 | done | — | workplans/FLEX-WP-0009-user-engine-production-policy-service.md |
|
||||
| task | FLEX-WP-0010-T01 | done | — | workplans/FLEX-WP-0010-tenant-lifecycle-policy-actions.md |
|
||||
| task | FLEX-WP-0010-T02 | done | — | workplans/FLEX-WP-0010-tenant-lifecycle-policy-actions.md |
|
||||
| task | FLEX-WP-0010-T03 | done | — | workplans/FLEX-WP-0010-tenant-lifecycle-policy-actions.md |
|
||||
| task | FLEX-WP-0010-T04 | done | — | workplans/FLEX-WP-0010-tenant-lifecycle-policy-actions.md |
|
||||
| task | FLEX-WP-0011-T01 | done | — | workplans/FLEX-WP-0011-railiance-staged-promotion-overlay.md |
|
||||
| task | FLEX-WP-0011-T02 | done | — | workplans/FLEX-WP-0011-railiance-staged-promotion-overlay.md |
|
||||
| task | FLEX-WP-0011-T03 | done | — | workplans/FLEX-WP-0011-railiance-staged-promotion-overlay.md |
|
||||
| task | FLEX-WP-0012-T01 | done | — | workplans/FLEX-WP-0012-credential-grant-authorization-surface.md |
|
||||
| task | FLEX-WP-0012-T02 | done | — | workplans/FLEX-WP-0012-credential-grant-authorization-surface.md |
|
||||
| task | FLEX-WP-0012-T03 | done | — | workplans/FLEX-WP-0012-credential-grant-authorization-surface.md |
|
||||
| task | FLEX-WP-0012-T04 | done | — | workplans/FLEX-WP-0012-credential-grant-authorization-surface.md |
|
||||
| task | FLEX-WP-0013-T01 | done | — | workplans/FLEX-WP-0013-restore-seven-action-tenant-engine-pin.md |
|
||||
| task | FLEX-WP-0013-T02 | done | — | workplans/FLEX-WP-0013-restore-seven-action-tenant-engine-pin.md |
|
||||
| task | FLEX-WP-0013-T03 | done | — | workplans/FLEX-WP-0013-restore-seven-action-tenant-engine-pin.md |
|
||||
| task | FLEX-WP-0014-T01 | done | — | workplans/FLEX-WP-0014-tenant-guardrail-policy-actions.md |
|
||||
| task | FLEX-WP-0014-T02 | done | — | workplans/FLEX-WP-0014-tenant-guardrail-policy-actions.md |
|
||||
| task | FLEX-WP-0014-T03 | done | — | workplans/FLEX-WP-0014-tenant-guardrail-policy-actions.md |
|
||||
| task | FLEX-WP-0014-T04 | done | — | workplans/FLEX-WP-0014-tenant-guardrail-policy-actions.md |
|
||||
| task | FLEX-WP-0015-T01 | done | — | workplans/FLEX-WP-0015-tenancy-posture-conformance.md |
|
||||
| task | FLEX-WP-0015-T02 | done | — | workplans/FLEX-WP-0015-tenancy-posture-conformance.md |
|
||||
| task | FLEX-WP-0015-T03 | done | — | workplans/FLEX-WP-0015-tenancy-posture-conformance.md |
|
||||
| task | FLEX-WP-0015-T04 | cancel | — | workplans/FLEX-WP-0015-tenancy-posture-conformance.md |
|
||||
| task | FLEX-WP-0015-T05 | done | — | workplans/FLEX-WP-0015-tenancy-posture-conformance.md |
|
||||
| task | FLEX-WP-0016-T01 | done | — | workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md |
|
||||
| task | FLEX-WP-0016-T02 | done | — | workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md |
|
||||
| task | FLEX-WP-0016-T03 | done | — | workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md |
|
||||
| task | FLEX-WP-0017-T01 | done | — | workplans/FLEX-WP-0017-action-bound-authorization-contract.md |
|
||||
| task | FLEX-WP-0017-T02 | done | — | workplans/FLEX-WP-0017-action-bound-authorization-contract.md |
|
||||
| task | FLEX-WP-0017-T03 | cancel | — | workplans/FLEX-WP-0017-action-bound-authorization-contract.md |
|
||||
| task | FLEX-WP-0017-T04 | done | — | workplans/FLEX-WP-0017-action-bound-authorization-contract.md |
|
||||
| task | FLEX-WP-0017-T05 | cancel | — | workplans/FLEX-WP-0017-action-bound-authorization-contract.md |
|
||||
| task | FLEX-WP-0018-T01 | done | — | workplans/FLEX-WP-0018-inbound-auth-corrections.md |
|
||||
| task | FLEX-WP-0018-T02 | done | — | workplans/FLEX-WP-0018-inbound-auth-corrections.md |
|
||||
| task | FLEX-WP-0019-T01 | done | — | workplans/FLEX-WP-0019-layer-model-conformance.md |
|
||||
| task | FLEX-WP-0019-T02 | done | — | workplans/FLEX-WP-0019-layer-model-conformance.md |
|
||||
| task | FLEX-WP-0019-T03 | done | — | workplans/FLEX-WP-0019-layer-model-conformance.md |
|
||||
| task | FLEX-WP-0019-T04 | done | — | workplans/FLEX-WP-0019-layer-model-conformance.md |
|
||||
| task | FLEX-WP-0019-T05 | done | — | workplans/FLEX-WP-0019-layer-model-conformance.md |
|
||||
| task | FLEX-WP-0019-T06 | done | — | workplans/FLEX-WP-0019-layer-model-conformance.md |
|
||||
| task | FLEX-WP-0020-T01 | done | — | workplans/FLEX-WP-0020-repository-identity-migration.md |
|
||||
| task | FLEX-WP-0020-T02 | done | — | workplans/FLEX-WP-0020-repository-identity-migration.md |
|
||||
| task | FLEX-WP-0020-T03 | done | — | workplans/FLEX-WP-0020-repository-identity-migration.md |
|
||||
| task | FLEX-WP-0020-T04 | done | — | workplans/FLEX-WP-0020-repository-identity-migration.md |
|
||||
| task | FLEX-WP-0020-T05 | done | — | workplans/FLEX-WP-0020-repository-identity-migration.md |
|
||||
| task | FLEX-WP-0020-T06 | done | — | workplans/FLEX-WP-0020-repository-identity-migration.md |
|
||||
| task | FLEX-WP-0020-T07 | done | — | workplans/FLEX-WP-0020-repository-identity-migration.md |
|
||||
| task | FLEX-WP-0020-T08 | done | — | workplans/FLEX-WP-0020-repository-identity-migration.md |
|
||||
| task | FLEX-WP-0020-T09 | done | — | workplans/FLEX-WP-0020-repository-identity-migration.md |
|
||||
| task | FLEX-WP-0020-T10 | done | — | workplans/FLEX-WP-0020-repository-identity-migration.md |
|
||||
| task | FLEX-WP-0020-T11 | wait | — | workplans/FLEX-WP-0020-repository-identity-migration.md |
|
||||
| task | FLEX-WP-0021-T01 | done | — | workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md |
|
||||
| task | FLEX-WP-0021-T02 | done | — | workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md |
|
||||
| task | FLEX-WP-0021-T03 | done | — | workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md |
|
||||
| task | FLEX-WP-0021-T04 | done | — | workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md |
|
||||
| task | FLEX-WP-0021-T05 | done | — | workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md |
|
||||
| task | FLEX-WP-0022-T01 | done | — | workplans/FLEX-WP-0022-tenant-scope-coverage.md |
|
||||
| task | FLEX-WP-0022-T02 | done | — | workplans/FLEX-WP-0022-tenant-scope-coverage.md |
|
||||
| task | FLEX-WP-0022-T03 | done | — | workplans/FLEX-WP-0022-tenant-scope-coverage.md |
|
||||
| task | FLEX-WP-0023-T01 | done | — | workplans/FLEX-WP-0023-operator-caller-access-path.md |
|
||||
| task | FLEX-WP-0023-T02 | done | — | workplans/FLEX-WP-0023-operator-caller-access-path.md |
|
||||
| task | FLEX-WP-0023-T03 | done | — | workplans/FLEX-WP-0023-operator-caller-access-path.md |
|
||||
| task | FLEX-WP-0023-T04 | done | — | workplans/FLEX-WP-0023-operator-caller-access-path.md |
|
||||
| task | FLEX-WP-0023-T05 | done | — | workplans/FLEX-WP-0023-operator-caller-access-path.md |
|
||||
| task | FLEX-WP-0024-T01 | done | — | workplans/FLEX-WP-0024-decision-envelope-authenticity.md |
|
||||
| task | FLEX-WP-0024-T02 | done | — | workplans/FLEX-WP-0024-decision-envelope-authenticity.md |
|
||||
| task | FLEX-WP-0024-T03 | done | — | workplans/FLEX-WP-0024-decision-envelope-authenticity.md |
|
||||
| task | FLEX-WP-0024-T04 | done | — | workplans/FLEX-WP-0024-decision-envelope-authenticity.md |
|
||||
| task | FLEX-WP-0024-T05 | done | — | workplans/FLEX-WP-0024-decision-envelope-authenticity.md |
|
||||
| task | FLEX-WP-0024-T06 | progress | — | workplans/FLEX-WP-0024-decision-envelope-authenticity.md |
|
||||
| task | FLEX-WP-0025-T01 | done | — | workplans/FLEX-WP-0025-fact-versus-assertion.md |
|
||||
| task | FLEX-WP-0025-T02 | done | — | workplans/FLEX-WP-0025-fact-versus-assertion.md |
|
||||
| task | FLEX-WP-0025-T03 | done | — | workplans/FLEX-WP-0025-fact-versus-assertion.md |
|
||||
| task | FLEX-WP-0026-T01 | done | — | workplans/FLEX-WP-0026-openrouter-native-contract.md |
|
||||
| task | FLEX-WP-0026-T02 | done | — | workplans/FLEX-WP-0026-openrouter-native-contract.md |
|
||||
| task | FLEX-WP-0027-T01 | done | — | workplans/FLEX-WP-0027-t03-human-review.md |
|
||||
| task | FLEX-WP-0027-T02 | done | — | workplans/FLEX-WP-0027-t03-human-review.md |
|
||||
| task | FLEX-WP-0027-T03 | done | — | workplans/FLEX-WP-0027-t03-human-review.md |
|
||||
| task | FLEX-WP-0028-T01 | done | — | workplans/FLEX-WP-0028-compact-sitting-review.md |
|
||||
| task | FLEX-WP-0028-T02 | done | — | workplans/FLEX-WP-0028-compact-sitting-review.md |
|
||||
| task | FLEX-WP-0029-T01 | done | — | workplans/FLEX-WP-0029-stance-register-second-edition.md |
|
||||
| task | FLEX-WP-0029-T02 | done | — | workplans/FLEX-WP-0029-stance-register-second-edition.md |
|
||||
| task | FLEX-WP-0029-T03 | done | — | workplans/FLEX-WP-0029-stance-register-second-edition.md |
|
||||
| task | FLEX-WP-0029-T04 | done | — | workplans/FLEX-WP-0029-stance-register-second-edition.md |
|
||||
| task | FLEX-WP-0030-T01 | done | — | workplans/FLEX-WP-0030-boundary-declaration-cleanup.md |
|
||||
| task | FLEX-WP-0030-T02 | done | — | workplans/FLEX-WP-0030-boundary-declaration-cleanup.md |
|
||||
| task | FLEX-WP-0030-T03 | done | — | workplans/FLEX-WP-0030-boundary-declaration-cleanup.md |
|
||||
| task | FLEX-WP-0030-T04 | done | — | workplans/FLEX-WP-0030-boundary-declaration-cleanup.md |
|
||||
| task | FLEX-WP-0030-T05 | done | — | workplans/FLEX-WP-0030-boundary-declaration-cleanup.md |
|
||||
| task | FLEX-WP-0030-T06 | done | — | workplans/FLEX-WP-0030-boundary-declaration-cleanup.md |
|
||||
| task | FLEX-WP-0030-T07 | done | — | workplans/FLEX-WP-0030-boundary-declaration-cleanup.md |
|
||||
| task | FLEX-WP-0030-T08 | done | — | workplans/FLEX-WP-0030-boundary-declaration-cleanup.md |
|
||||
| task | FLEX-WP-0031-T01 | done | — | workplans/FLEX-WP-0031-decision-record-emission.md |
|
||||
| task | FLEX-WP-0031-T02 | wait | — | workplans/FLEX-WP-0031-decision-record-emission.md |
|
||||
| task | FLEX-WP-0031-T03 | done | — | workplans/FLEX-WP-0031-decision-record-emission.md |
|
||||
| task | FLEX-WP-0031-T04 | wait | — | workplans/FLEX-WP-0031-decision-record-emission.md |
|
||||
| task | FLEX-WP-0031-T05 | done | — | workplans/FLEX-WP-0031-decision-record-emission.md |
|
||||
| task | FLEX-WP-0031-T06 | wait | — | workplans/FLEX-WP-0031-decision-record-emission.md |
|
||||
| task | FLEX-WP-0031-T07 | done | — | workplans/FLEX-WP-0031-decision-record-emission.md |
|
||||
| task | FLEX-WP-0031-T08 | wait | — | workplans/FLEX-WP-0031-decision-record-emission.md |
|
||||
| task | FLEX-WP-0031-T09 | done | — | workplans/FLEX-WP-0031-decision-record-emission.md |
|
||||
| task | FLEX-WP-0032-T01 | done | — | workplans/FLEX-WP-0032-informed-decision-list-action.md |
|
||||
| task | FLEX-WP-0032-T02 | done | — | workplans/FLEX-WP-0032-informed-decision-list-action.md |
|
||||
| task | FLEX-WP-0032-T03 | done | — | workplans/FLEX-WP-0032-informed-decision-list-action.md |
|
||||
| task | FLEX-WP-0032-T04 | done | — | workplans/FLEX-WP-0032-informed-decision-list-action.md |
|
||||
| task | FLEX-WP-0033-T01 | done | — | workplans/FLEX-WP-0033-informed-decision-lifecycle.md |
|
||||
| task | FLEX-WP-0033-T02 | done | — | workplans/FLEX-WP-0033-informed-decision-lifecycle.md |
|
||||
| task | FLEX-WP-0033-T03 | done | — | workplans/FLEX-WP-0033-informed-decision-lifecycle.md |
|
||||
| task | FLEX-WP-0033-T04 | done | — | workplans/FLEX-WP-0033-informed-decision-lifecycle.md |
|
||||
| task | FLEX-WP-0034-T01 | done | — | workplans/FLEX-WP-0034-informed-decision-review-discovery.md |
|
||||
| task | FLEX-WP-0034-T02 | done | — | workplans/FLEX-WP-0034-informed-decision-review-discovery.md |
|
||||
| task | FLEX-WP-0035-T01 | done | — | workplans/FLEX-WP-0035-per-identity-application-readback.md |
|
||||
| task | FLEX-WP-0035-T02 | done | — | workplans/FLEX-WP-0035-per-identity-application-readback.md |
|
||||
| task | FLEX-WP-0035-T03 | done | — | workplans/FLEX-WP-0035-per-identity-application-readback.md |
|
||||
| task | FLEX-WP-0035-T04 | done | — | workplans/FLEX-WP-0035-per-identity-application-readback.md |
|
||||
| task | FLEX-WP-0035-T05 | done | — | workplans/FLEX-WP-0035-per-identity-application-readback.md |
|
||||
| task | FLEX-WP-0036-T01 | wait | — | workplans/FLEX-WP-0036-runtime-rename-access-engine.md |
|
||||
| task | FLEX-WP-0036-T02 | progress | — | workplans/FLEX-WP-0036-runtime-rename-access-engine.md |
|
||||
| task | FLEX-WP-0036-T03 | wait | — | workplans/FLEX-WP-0036-runtime-rename-access-engine.md |
|
||||
| task | FLEX-WP-0036-T04 | wait | — | workplans/FLEX-WP-0036-runtime-rename-access-engine.md |
|
||||
| task | FLEX-WP-0036-T05 | wait | — | workplans/FLEX-WP-0036-runtime-rename-access-engine.md |
|
||||
| task | FLEX-WP-0036-T06 | wait | — | workplans/FLEX-WP-0036-runtime-rename-access-engine.md |
|
||||
| task | FLEX-WP-0036-T07 | todo | — | workplans/FLEX-WP-0036-runtime-rename-access-engine.md |
|
||||
| task | FLEX-WP-0036-T08 | todo | — | workplans/FLEX-WP-0036-runtime-rename-access-engine.md |
|
||||
| intake | FLEX-IN-0001 | closed | — | intakes/intakes.md |
|
||||
| intake | FLEX-IN-0002 | closed | — | intakes/intakes.md |
|
||||
| intake | FLEX-IN-0003 | open | — | intakes/intakes.md |
|
||||
| decision | FLEX-DEC-2026-001 | resolved | — | decisions/decisions.md |
|
||||
| decision | FLEX-DEC-2026-002 | resolved | — | decisions/decisions.md |
|
||||
| decision | FLEX-DEC-2026-003 | resolved | — | decisions/decisions.md |
|
||||
| decision | FLEX-DEC-2026-004 | resolved | — | decisions/decisions.md |
|
||||
| decision | FLEX-DEC-2026-005 | resolved | — | decisions/decisions.md |
|
||||
| decision | FLEX-DEC-2026-006 | resolved | — | decisions/decisions.md |
|
||||
| decision | FLEX-DEC-2026-007 | resolved | — | decisions/decisions.md |
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[
|
||||
{
|
||||
"path": ".custodian-brief.md",
|
||||
"index": "100644 5e12ebd1d7606f88c606a5cc23b2c24d1afa8a3a 0\t.custodian-brief.md"
|
||||
},
|
||||
{
|
||||
"path": "WORK-RECORDS.md",
|
||||
"index": "100644 62ffebf8500114c6080a7a15809cb3e344a555d7 0\tWORK-RECORDS.md"
|
||||
}
|
||||
]
|
||||
|
|
@ -0,0 +1,103 @@
|
|||
{
|
||||
"owner": "access-engine",
|
||||
"base_revision": "d328a2601095686f74376d87791bff01e2a3a2a3",
|
||||
"message": "Add producer-owned authenticated Go decision client and validated Forgejo profile",
|
||||
"files": [
|
||||
{
|
||||
"path": "Makefile",
|
||||
"sha256": "7ef0d92d357c18ba3237f1e52727ffa06790195c7ed63f9e774eb186b1a241d9"
|
||||
},
|
||||
{
|
||||
"path": "adapters/go/decisionpep/LICENSE",
|
||||
"sha256": "ff413f361a3b3bf44cf50f110fbcc4837064d57eefbcef89df2b43997c6262b6"
|
||||
},
|
||||
{
|
||||
"path": "adapters/go/decisionpep/go.mod",
|
||||
"sha256": "fea700810e47c1ba5638b86a168f8531c083a6e1222ca80bd2a8947b2ea6f2c3"
|
||||
},
|
||||
{
|
||||
"path": "adapters/go/decisionpep/internal/sign/sign.go",
|
||||
"sha256": "0df9515922e90775ebbfac798361dcafb20da8a4213796b44e246b8a92046cde"
|
||||
},
|
||||
{
|
||||
"path": "adapters/go/decisionpep/pkg/api/canonical.go",
|
||||
"sha256": "a122a2e8cd524333b13c5939c7a3685e41efbe47497a64e0c7297c92b7f10d19"
|
||||
},
|
||||
{
|
||||
"path": "adapters/go/decisionpep/pkg/api/caring.go",
|
||||
"sha256": "1907156f0f889e7b9e9c14970cf7a86a20d00478a496efaf92c7231f27fec5e3"
|
||||
},
|
||||
{
|
||||
"path": "adapters/go/decisionpep/pkg/api/resource_manifest.go",
|
||||
"sha256": "f0fa4080287d389ed48c2b1d6af96cc62e57ef72c902333f677f964420be133f"
|
||||
},
|
||||
{
|
||||
"path": "adapters/go/decisionpep/pkg/decisionpep/client.go",
|
||||
"sha256": "0d57f6ddaca5c3f81ce426c0e8b14ba14ea5962096d3be5909aa456eef19eeba"
|
||||
},
|
||||
{
|
||||
"path": "adapters/go/decisionpep/pkg/decisionpep/client_test.go",
|
||||
"sha256": "1a6be3485f580f95a1f1406fb76e525f2c4bf02fe04a424cfe0095bb728e3f62"
|
||||
},
|
||||
{
|
||||
"path": "adapters/go/decisionpep/producer-source.json",
|
||||
"sha256": "c1d83e3d79f9860ffaa61ec19a6b3415e914d3058b11b07cdd05a7d1182cdceb"
|
||||
},
|
||||
{
|
||||
"path": "adapters/go/decisionpep/testsupport/signfixture/sign.go",
|
||||
"sha256": "fe4aa86f444dc20145aefbaca35b24f046264b2c5c8b4e3b057a4496b77a4d29"
|
||||
},
|
||||
{
|
||||
"path": "cmd/access-engine/forgejo_application_profile_test.go",
|
||||
"sha256": "559de3fa47bdd1ad265c401f1c0645ee895001555dae1a6a5712953c85d508fe"
|
||||
},
|
||||
{
|
||||
"path": "cmd/access-engine/main.go",
|
||||
"sha256": "0bce5b48d41fce65d6deac3b81cda88e24b57e5b696143aac1f3929e1677319d"
|
||||
},
|
||||
{
|
||||
"path": "docs/decisionpep-adapter.md",
|
||||
"sha256": "48ebf9bf71e12ac09553d2ed19eb7c9fdb785a67560dd173f169c616c35e26b2"
|
||||
},
|
||||
{
|
||||
"path": "examples/forgejo-application-access/policy.md",
|
||||
"sha256": "3a5b0c348d8ee89236b3f7064bdd07afddc2613eda69ff6f4d88ba7cde3024ac"
|
||||
},
|
||||
{
|
||||
"path": "examples/forgejo-application-access/registry_snapshot.json",
|
||||
"sha256": "f83c53afad98ba72dc199ccada552c9e844d903a94a3168229d985e827fa2f0e"
|
||||
},
|
||||
{
|
||||
"path": "internal/decision/engine.go",
|
||||
"sha256": "ecbb73644d979b1f15e1df6945536c20507fb3d3f9640f755a7081a344782c7d"
|
||||
},
|
||||
{
|
||||
"path": "internal/decision/json_profile.go",
|
||||
"sha256": "5c6ff75b30372df0350bd48d6f6c77fa71665de6553dc39dc38cc1ecae07b60f"
|
||||
},
|
||||
{
|
||||
"path": "pkg/decisionpep/client.go",
|
||||
"sha256": "0d57f6ddaca5c3f81ce426c0e8b14ba14ea5962096d3be5909aa456eef19eeba"
|
||||
},
|
||||
{
|
||||
"path": "pkg/decisionpep/client_test.go",
|
||||
"sha256": "1a6be3485f580f95a1f1406fb76e525f2c4bf02fe04a424cfe0095bb728e3f62"
|
||||
},
|
||||
{
|
||||
"path": "pkg/decisionpep/export_test.go",
|
||||
"sha256": "ecf763d1b3fb8525c5a31a25825cca5dd5c5ccc26e631f3943bd60b8a441f843"
|
||||
},
|
||||
{
|
||||
"path": "testsupport/signfixture/sign.go",
|
||||
"sha256": "fe4aa86f444dc20145aefbaca35b24f046264b2c5c8b4e3b057a4496b77a4d29"
|
||||
},
|
||||
{
|
||||
"path": "tools/export_decisionpep_adapter.py",
|
||||
"sha256": "6aea657b99f55fbe87582f225fb5308f97489330a9a29cd2010844f6930d9ac1"
|
||||
},
|
||||
{
|
||||
"path": "workplans/FLEX-WP-0024-decision-envelope-authenticity.md",
|
||||
"sha256": "f578b116587bc9d269081129b78d6d4ab6a2bd14105bfa57a464f07597823ab6"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -0,0 +1,367 @@
|
|||
---
|
||||
id: FLEX-WP-0024
|
||||
type: workplan
|
||||
title: "Sign the decision envelope: the response channel is unauthenticated"
|
||||
domain: infotech
|
||||
repo: flex-auth
|
||||
status: active
|
||||
owner: claude
|
||||
topic_slug: netkingdom
|
||||
planning_priority: P1
|
||||
planning_order: 240
|
||||
depends_on_workplans:
|
||||
- FLEX-WP-0021
|
||||
related_workplans:
|
||||
- FLEX-WP-0019
|
||||
- FLEX-WP-0023
|
||||
created: "2026-09-06"
|
||||
updated: "2026-10-18"
|
||||
state_hub_workstream_id: "90577acd-6910-548d-a13e-1dbfdfb8ed27"
|
||||
---
|
||||
|
||||
# FLEX-WP-0024 — Sign the decision envelope: the response channel is unauthenticated
|
||||
|
||||
Opened by `FLEX-DEC-2026-010`, from a question `secrets-engine` asked rather
|
||||
than answering locally: **how is the response channel authenticated?** They
|
||||
declined to choose a transport control for flex-auth's service on the grounds
|
||||
that it is not a consumer's call. Correct, and it is why this is a flex-auth
|
||||
workplan and not a mitigation in their repo.
|
||||
|
||||
The stance today: pins serve plain HTTP, `flex-auth.decision-record.v1` carries
|
||||
no signature, and a responder that knows the package id and version — both
|
||||
published — can return a well-formed `effect: allow` that passes every check a
|
||||
consumer performs.
|
||||
|
||||
## The two things not to get backwards
|
||||
|
||||
**The digests do not authenticate the responder and cannot.** Every input to
|
||||
them is either sent by the caller or published, so a forger reproduces
|
||||
`request_digest`, `policy_package_digest`, and `registry_snapshot_digest`
|
||||
exactly. Publishing more digests makes a forged envelope look *more*
|
||||
authenticated, not less.
|
||||
|
||||
**Fail-closed does not cover this.** It protects against a PDP that is absent,
|
||||
not against one that lies. An unreachable PDP denies; a lying PDP allows.
|
||||
|
||||
## 1. Publish the stance and stop publishing bare Service names
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0024-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "b8fad80d-5c44-5e26-a632-5096e0c0f3c5"
|
||||
```
|
||||
|
||||
Owner: `flex-auth`.
|
||||
|
||||
**Done 2026-09-06.** `docs/decision-record-contract.md` states that digest
|
||||
recomputation is not responder verification, because the contract is the only
|
||||
document a consumer is guaranteed to read.
|
||||
`docs/operator-caller-access-path.md` carries the reproduced DNS probe and the
|
||||
channel analysis. The trailing-dot FQDN replaced the bare Service name in
|
||||
`examples/secrets-engine/README.md`, `SCOPE.md`, and the `FLEX-WP-0021-T05`
|
||||
handover note — a bare `*.svc.cluster.local` name resolves through
|
||||
`search ad.binect.de` to one unrelated public host, and a name for a service
|
||||
that does not exist resolves to the same address.
|
||||
|
||||
## 2. Choose the signature shape and key custody
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0024-T02
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "5482f3cd-36cb-55e0-8c52-0ca2340ed4d7"
|
||||
```
|
||||
|
||||
Owner: `flex-auth`; key custody is **not** ours to invent.
|
||||
|
||||
- Detached signature over the canonical envelope, preferred over transport-only
|
||||
mTLS for two reasons: it survives the transport, so a decision audited later
|
||||
is still attributable, where mTLS authenticates a connection that no longer
|
||||
exists; and it composes with `FLEX-DEC-2026-009`, since a record that names
|
||||
its authenticated caller *and* carries flex-auth's signature is an audit
|
||||
artifact where either alone is a claim.
|
||||
- Decide the canonical form to sign. The existing canonical-JSON rules from
|
||||
`docs/canonical-request-digest.md` are the obvious basis, but the signed
|
||||
material is the **envelope**, not the request, and it must exclude the
|
||||
signature field itself. Write it down before implementing: an implicit
|
||||
canonicalisation rule is what `FLEX-DEC-2026-007` had to correct.
|
||||
- **Do not mint a key in this repo.** Route custody via
|
||||
`warden route find "decision envelope signing key"` and OpenBao, per the
|
||||
estate credential-routing rule. flex-auth decides the shape; it does not own
|
||||
key material.
|
||||
- State key rotation and how a consumer discovers the current public key, since
|
||||
a consumer that cannot rotate trust has a pinned key that will one day be
|
||||
wrong.
|
||||
|
||||
Gate: the canonical form, the algorithm, and the custody path are written down
|
||||
and reviewed before any signing code exists.
|
||||
|
||||
**Done 2026-09-14.** Written in `docs/decision-envelope-signature.md`: detached
|
||||
Ed25519 over `json.Marshal` of the envelope with `signature` omitted; unsigned
|
||||
is `{mode: unsigned}`; production key lives in OpenBao, not this repo
|
||||
(proposed catalog id `flex-auth-decision-envelope-signing-key`). Test-only seed
|
||||
is documented and is not the custody path.
|
||||
|
||||
## 3. Implement signing and verification
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0024-T03
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "041612ea-1be4-5997-8c32-49f8bcc50855"
|
||||
```
|
||||
|
||||
Owner: `flex-auth`.
|
||||
|
||||
- Add the signature to `schemas/decision_envelope.schema.json` as additive, and
|
||||
state in the contract that `request_digest` is unaffected so no consumer
|
||||
re-pins — the same note that was needed for v2 and for
|
||||
`approval_binding_digest`.
|
||||
- Emit unsigned when no key is configured, and say so in the envelope rather
|
||||
than omitting the field silently. Absence stated, not implied — the
|
||||
`pdp_digest` precedent.
|
||||
- Ship a verification example and a fixture pair in
|
||||
`examples/secrets-engine/replay/`: a genuine signed envelope and one whose
|
||||
payload was altered after signing, so a consumer's verifier is tested against
|
||||
a real failure rather than only a real success. **A verifier that has never
|
||||
seen an invalid signature is untested**, which is the lesson from every
|
||||
fixture suite in `FLEX-DEC-2026-008`.
|
||||
|
||||
Gate: an altered envelope fails verification, an unaltered one passes, and a
|
||||
consumer can perform both from the fixtures alone.
|
||||
|
||||
**Done 2026-09-14.** Additive `signature` on the schema and envelope. Engine
|
||||
emits `{mode: unsigned}` when no key is configured. Fixture pair:
|
||||
`examples/secrets-engine/replay/decision_rotate_signed.json` verifies,
|
||||
`decision_rotate_signed_tampered.json` does not, same `request_digest`. Public
|
||||
key in `keys.json`. Tests in `internal/sign`.
|
||||
|
||||
## 4. Report the gap to gate-house
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0024-T04
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "82d6b75e-e2c6-5e3d-a897-fbdfb7c9094e"
|
||||
```
|
||||
|
||||
Owner: `flex-auth`.
|
||||
|
||||
§6.4 obligates the PEP to act on a decision and §9.3 splits degraded mode by
|
||||
owner, but **nothing in the standard requires a PDP's response to be
|
||||
authenticable**. So a fully conformant PEP can trust a forged allow while
|
||||
meeting every published obligation. That is a gap in the standard, not only in
|
||||
this implementation, and it belongs in the outstanding v0.8 assent round
|
||||
alongside the `FLEX-DEC-2026-009` finding.
|
||||
|
||||
## T04 closed — 2026-09-07
|
||||
|
||||
**Done.** Reported as `FLEX-DEC-2026-011` F1, ranked blocking for
|
||||
calling the §6.4 PEP obligations complete and explicitly not blocking anyone's
|
||||
adoption of v0.8 — the condition already exists under v0.7 and is not created by
|
||||
this version. §16 already carries the same observation one layer up, about the
|
||||
standard's own publication path having no digest or freeze discipline; F1 is
|
||||
that observation applied to the artifact the standard regulates.
|
||||
|
||||
## 5. Wire owner signing into the decision pin and retained deployment charts
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0024-T05
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "cfe4d275-9f02-5090-8391-06eea59d45c5"
|
||||
```
|
||||
|
||||
2026-10-16 source follow-through: NetKingdom target Secrets Engine R2 owner review
|
||||
found that the completed T03 signature package was used only by fixtures. Add
|
||||
explicit mounted seed/kid configuration for `serve`, sign the final envelope before
|
||||
recording, and expose inert existing-Secret mounts in both retained/new charts.
|
||||
The API/sign verifier sources remain byte-identical. Local source validation and
|
||||
review are in the Custodian `docs/changes/netkingdom-target-2026-10-16/access-verifier-review/`.
|
||||
This is source preparation only, not signer admission or deployed acceptance.
|
||||
|
||||
## 6. Admit custody, consumer trust, exact packages and native signed decisions
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0024-T06
|
||||
status: progress
|
||||
priority: high
|
||||
state_hub_task_id: "7f785b52-bf62-5884-8d34-670d70bc9023"
|
||||
```
|
||||
|
||||
Wait on Platform/OpenBao key custody, independent public-key and issuer/policy-pin
|
||||
admission, exact image and existing-Secret values rollout, owner-bound caller/tunnel,
|
||||
and Secrets Engine verifier installation. Follow `docs/decision-envelope-signature.md`
|
||||
for overlap/removal semantics. Retain signed producer record/consumer acceptance,
|
||||
forged/altered/unsigned/wrong-pin/expired denial and rotation-removal receipts;
|
||||
then update actual deployed status. No signer or runtime trust is admitted by the
|
||||
source review. This task owns the producer-side native gate; SECRETS-WP-0014 owns
|
||||
consumer admission/enforcement. The old fixture completion never established this
|
||||
gate, so the workplan is reopened rather than claiming it already passed.
|
||||
|
||||
|
||||
2026-10-16 owner native preparation: T06 is `progress` because Access still owns
|
||||
signer workload declaration, artifact/provenance and source/provider-join preparation;
|
||||
no unqualified cross-owner wait is claimed. Read-only actual release metadata and
|
||||
bounded proposal are in the Custodian
|
||||
`docs/changes/netkingdom-target-2026-10-16/access-native-preparation/`.
|
||||
The real Platform custody route `flex-auth-decision-envelope-signing-key` exists but
|
||||
is draft/nonresolvable; no production kid/public fingerprint, Secret projection or
|
||||
custody receipt is admitted. Coordinate that named commitment through CUST-WP-0080
|
||||
instead of inventing a Platform task/approval. SECRETS-WP-0014-T03 owns installed
|
||||
consumer native verification and must not form a circular blocking dependency.
|
||||
|
||||
The first proposed native trial only signs the unchanged lifecycle package on the
|
||||
existing retained release; `execute-ccr` remains denied. Current service-pilot
|
||||
`runtime_admission := false` remains mandatory: the source ServicePilotInputs is
|
||||
not yet wired into HTTP, and public service_actor_binding never authenticates the
|
||||
caller. Later activation needs a complete reviewed provider join, exact policy and
|
||||
operation admission, artifact digests, owner execution/rollback proposal and native
|
||||
receipts. Preparation/local synthetic success grants none of those permissions.
|
||||
|
||||
|
||||
2026-10-16 source-only native preparation adds the existing Secrets PDP ServiceAccount
|
||||
to `tenancy.yaml` with evidence in `docs/native-signer-workload.json`, makes the
|
||||
retained `flex-auth` audience explicit, pins CI archive fetch to the full source
|
||||
revision, and adds offline native signer receipt verification using the existing
|
||||
Secrets verifier. No key, trust, image publication or live activation is admitted.
|
||||
The managed workload's missing rapp declaration remains explicit migration debt;
|
||||
this source binding does not fabricate a package declaration or raise its grade.
|
||||
|
||||
|
||||
2026-10-16 separate B1 source follow-through wires ServicePilotInputs through actual
|
||||
HTTP/TokenReview into a signed-DENY-only engine entry. Generic `execute-ccr` calls
|
||||
refuse across every policy, including the old separately named positive fixture;
|
||||
that proof stays pinned to ec21518e. Original context/submitted digest stay unchanged.
|
||||
Actual disposable serve/TLS TokenReview/HTTP signed-DENY and bypass/refusal tests are
|
||||
source evidence only. B2 depends on independently reviewed Approval fact contract
|
||||
and canonical vectors; B3 additionally needs exact source/normalization numeric
|
||||
representation and full trusted provider joins. No current policy false gate,
|
||||
production trust, native deployment or protected effect is enabled by B1.
|
||||
|
||||
2026-10-16 B2/B3 source successor preparation (separate from frozen B1): the
|
||||
isolated v2 source path now joins the fixed authenticated Approval reader,
|
||||
unchanged Approval-owner canonical/fact helper, original/fresh correspondence,
|
||||
raw numeric request/registry source retention, same policy evaluator and signed
|
||||
source provenance. Disposable actual HTTP and production serve subprocess prove
|
||||
synthetic signed ALLOW and fail-closed negative joins with exact response/record
|
||||
parity. See `docs/trusted-service-task-source.md`. T06 remains `progress`: this
|
||||
source proposal requires independent cross-owner review and full consumer/Platform
|
||||
successor integration, then separately admitted runtime custody, source trust,
|
||||
image provenance and rollout. No source-only proof establishes those runtime gates.
|
||||
|
||||
|
||||
2026-10-16 B2/B3 R2 temporal correction (R1 retained): whole-stack review exposed
|
||||
that R1's 15s ALLOW and default Approval freshness30 cannot fit the declared
|
||||
minimum backendTTL30 plus existing cleanupreserve5. The v2 successor now derives
|
||||
exact ALLOW expiry from the immutable operationdeadline, requiring all original/
|
||||
fresh approval/freshness/caller bounds, a conservative source maximum120 and
|
||||
remaining declaredTTL+5 after source I/O/evaluation. No consumer/native deadline
|
||||
or cleanup guard is relaxed. Max structural budgets that cannot fit refuse.
|
||||
The fixture declares backendTTL30/deadline60 and explicit source freshness120;
|
||||
owner runtime source freshness configuration and full native integration remain
|
||||
separate reviewed gates. See docs/trusted-service-task-source.md.
|
||||
|
||||
2026-10-16 B2/B3 R3 follows actual retained-registry integration failure: subject
|
||||
enrichment changed evaluated approval-free digest from the original proposal.
|
||||
The existing signed claim-free DENY now explicitly carries v2 approvalfree digest
|
||||
(equal evaluated requestdigest), enabling producer-owned preapproval facts under
|
||||
the already published enrichment contract. The final original proposal adds only
|
||||
the issued claim; registry drift/refreshed facts cannot silently rebind it.
|
||||
Retained-registry HTTP and production serve proofs and negative joins pass.
|
||||
R3 preserves precise notbefore pending separate Approval-owner timestamp fidelity
|
||||
repair; no rounding waiver, copied registry algorithm or empty-registry workaround.
|
||||
|
||||
2026-10-16 native admission prerequisite: fresh metadata confirms no namespace
|
||||
PVC exists, and current outbox had neither OS writer exclusion nor a byte/startup
|
||||
bound. Prepared existing-outbox hardening on exact canonical R3 base2b064ee:
|
||||
nonblocking Linux flock held through Close/process lifetime before recovery,
|
||||
64MiB source journal ceiling,2MiB record/atomic-batch bounds, streaming startup,
|
||||
4KiB cursor, all-effect commit refusal and fenced unconfirmed rollback. Actual
|
||||
process contention/crash release, capacity/prefix/restart and ENOSPC/fsync failure
|
||||
proofs are part of the owner package. No new service, live mount, deletion or
|
||||
custody grant; exact published successor, new PVC/PV retention/managed-package
|
||||
owner disposition and independent consumer admission remain prerequisites.
|
||||
|
||||
2026-10-16 owner package extraction record: canonical local package
|
||||
`rapp-flex-auth-secrets-engine` now exists at commit
|
||||
`d52f811ed5ec0be27c9c367e71d476125b3228be`, tree
|
||||
`d4fbad71bdc8ef870603526ccd1f53195d0322af`; authoritative declaration
|
||||
`declarations/rapp.yaml` SHA256 `0b722431bc5162dd86f72b15f12424e149aca8f2a8790adf2c57e8511ea73b4c`.
|
||||
Repo Manager exact local resolution under `/home/worsch` returns
|
||||
`rapp-flex-auth-secrets-engine` / workload `flex-auth-secrets-engine` /
|
||||
deployable `flex-auth-secrets-engine`, ownership `access-engine`, readiness
|
||||
`draft`. The retained lifecycle PDP is the only rollback boundary claimed;
|
||||
tenant/user/canary and retired `rapp-secrets-engine` remain excluded. Normative
|
||||
focused family validation passes; existing unrelated global rapp-forgejo error
|
||||
and reef projection warning remain visible. Package extraction keeps source
|
||||
`2b064eee510640224274ccdc7cefceb1ae13162e` and current image
|
||||
`sha256:05a03a8790c2210c48ea92391441c77ddf640d0cd32f5ec09838f5393171fcbd`
|
||||
unchanged. Exact local source resolution is no central/private read-placement,
|
||||
reef binding, custody, native rollout or consumer trust admission. Future signer
|
||||
image/config adoption remains separate. T06 remains `progress`; no second work
|
||||
item duplicates this bounded dependency.
|
||||
|
||||
|
||||
2026-10-16 bounded stopped-chart source preparation (Custodian
|
||||
`access-native-admission/stopped-chart-r2`): both outbox charts admit numeric
|
||||
replicaCount exactly 0 (maintenance stop) or 1 (single writer), with Recreate,
|
||||
process flock and bounded persistence unchanged. Fractions, strings, booleans,
|
||||
negative values and 2+ refuse; Helm decodes YAML/JSON integral 0.0/1.0 as the same
|
||||
numeric values as 0/1, so lexical float spelling is not distinguished. Actual
|
||||
Helm stopped/ready renders differ only in replicas and retain the same Platform
|
||||
source-rendered deployment projection. Owner preparation and independent
|
||||
coordinator checks approve this bounded source change only; 86 Helm renders and
|
||||
the existing outbox/delivery/receiver-port suite pass. No native stop, bootstrap,
|
||||
rollout, custody, public trust, resource or protected-effect approval follows.
|
||||
The proposed immutable image remains source revision
|
||||
`84c78e072c8f3daf2bc3b90f8efc8fbeb16c3cf0`, ordinary CI402 verified digest
|
||||
`sha256:09a83b273740133518cc7e7915fb211381e06545d347d2dd1974042525ac981f`.
|
||||
This chart-only successor requires its own exact source/chart pin and reviewed
|
||||
runtime scope; it can explicitly select the unchanged verified 84 image without
|
||||
rebuilding it or claiming that its revision label names the new chart commit.
|
||||
These chart/test/workplan-only paths do not trigger the existing image workflow.
|
||||
Frozen rollout R1, Platform P2 and the package extraction2b/current05a remain
|
||||
unchanged. T06 stays `progress`; actual stopped-fence verification and all native
|
||||
admission gates remain open under the same existing task.
|
||||
|
||||
|
||||
2026-10-16 Access owner exact native plan review (Custodian
|
||||
`access-native-plan-review-next/`): approved bounded Access workload/Helm/outbox/
|
||||
stopped-only rollback plan for frozen rollout R2 manifest5be7a7f and Platform P4
|
||||
manifest9eec861, chartdc0420/image84c78e OCI09a83b/projection8ce375f. Offline
|
||||
verification checks every R2 manifest/source digest and reproduces both exact
|
||||
Helm render bytes. The mandatory execution supplement names actual repo/Helm/CI
|
||||
paths and excludes unrelated legacy rollback recipes, records the owner/founder
|
||||
manual-writer acknowledgement, supplies a verified stopped-revision rollback
|
||||
shape, and separates120-second stop/readiness gates from atomic rollback and
|
||||
the600-second recovery decision. No production source change was needed.
|
||||
Existing read-only preflight admits all7exact resources but still observes
|
||||
unsigned05a/revision4running, no installed stopped fence or held window. T06
|
||||
stays progress: actual founder entity/expiry/window/executor and five final
|
||||
external scope dispositions, custody/trust/caller, actual stopped Helm revision,
|
||||
PVC/PV Retain and native producer/consumer/restart/failure receipts remain open.
|
||||
No live mutation, credential access, new key, authority or protected effect follows.
|
||||
|
||||
|
||||
2026-10-18 source implementation under CUST-WP-0080 / NK-WP-0048-T43:
|
||||
the producer-owned normal Check client now authenticates exact policy/registry/
|
||||
caller/request/lifetime bindings with a nonce and the optional lossless JSON
|
||||
profile. The default legacy decoder and unchanged signature/API contract remain
|
||||
intact. Root pkg/decisionpep is the source of truth; its Go1.24 consumer slice is
|
||||
generated by tools/export_decisionpep_adapter.py and checked by ordinary tests.
|
||||
The Forgejo example uses authoritative registry tenant/issuer facts and verified
|
||||
runtime identity in the admitted caller's request context. Actual producer
|
||||
regressions reproduce/refuse object-shaped group inputs; policy fixtures and
|
||||
Rego tests validate the original three-group contract. Full isolated root race
|
||||
suite: 494 test/subtest passes, three existing optional/fixture skips. Export
|
||||
parity and final group-shape regressions pass. Detailed source pins and retained
|
||||
failures are in Custodian apps-access-engine-integration-r2.
|
||||
|
||||
This is source delivery, not owner assent or native admission. Synthetic keys,
|
||||
registry and local callback proof establish no live signer/caller/policy grant.
|
||||
Existing rollout R2/image84 and their approvals remain frozen; they do not admit
|
||||
this source or a new image. T06 and all native custody/trust/rollout/recovery gates
|
||||
remain open. Forgejo's complete resource/operation/inverse and session-revocation
|
||||
coverage remains NK48-T43 / RAPPS16-T09 work.
|
||||
|
|
@ -0,0 +1,345 @@
|
|||
---
|
||||
id: FLEX-WP-0024
|
||||
type: workplan
|
||||
title: "Sign the decision envelope: the response channel is unauthenticated"
|
||||
domain: infotech
|
||||
repo: flex-auth
|
||||
status: active
|
||||
owner: claude
|
||||
topic_slug: netkingdom
|
||||
planning_priority: P1
|
||||
planning_order: 240
|
||||
depends_on_workplans:
|
||||
- FLEX-WP-0021
|
||||
related_workplans:
|
||||
- FLEX-WP-0019
|
||||
- FLEX-WP-0023
|
||||
created: "2026-09-06"
|
||||
updated: "2026-10-16"
|
||||
state_hub_workstream_id: "90577acd-6910-548d-a13e-1dbfdfb8ed27"
|
||||
---
|
||||
|
||||
# FLEX-WP-0024 — Sign the decision envelope: the response channel is unauthenticated
|
||||
|
||||
Opened by `FLEX-DEC-2026-010`, from a question `secrets-engine` asked rather
|
||||
than answering locally: **how is the response channel authenticated?** They
|
||||
declined to choose a transport control for flex-auth's service on the grounds
|
||||
that it is not a consumer's call. Correct, and it is why this is a flex-auth
|
||||
workplan and not a mitigation in their repo.
|
||||
|
||||
The stance today: pins serve plain HTTP, `flex-auth.decision-record.v1` carries
|
||||
no signature, and a responder that knows the package id and version — both
|
||||
published — can return a well-formed `effect: allow` that passes every check a
|
||||
consumer performs.
|
||||
|
||||
## The two things not to get backwards
|
||||
|
||||
**The digests do not authenticate the responder and cannot.** Every input to
|
||||
them is either sent by the caller or published, so a forger reproduces
|
||||
`request_digest`, `policy_package_digest`, and `registry_snapshot_digest`
|
||||
exactly. Publishing more digests makes a forged envelope look *more*
|
||||
authenticated, not less.
|
||||
|
||||
**Fail-closed does not cover this.** It protects against a PDP that is absent,
|
||||
not against one that lies. An unreachable PDP denies; a lying PDP allows.
|
||||
|
||||
## 1. Publish the stance and stop publishing bare Service names
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0024-T01
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "b8fad80d-5c44-5e26-a632-5096e0c0f3c5"
|
||||
```
|
||||
|
||||
Owner: `flex-auth`.
|
||||
|
||||
**Done 2026-09-06.** `docs/decision-record-contract.md` states that digest
|
||||
recomputation is not responder verification, because the contract is the only
|
||||
document a consumer is guaranteed to read.
|
||||
`docs/operator-caller-access-path.md` carries the reproduced DNS probe and the
|
||||
channel analysis. The trailing-dot FQDN replaced the bare Service name in
|
||||
`examples/secrets-engine/README.md`, `SCOPE.md`, and the `FLEX-WP-0021-T05`
|
||||
handover note — a bare `*.svc.cluster.local` name resolves through
|
||||
`search ad.binect.de` to one unrelated public host, and a name for a service
|
||||
that does not exist resolves to the same address.
|
||||
|
||||
## 2. Choose the signature shape and key custody
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0024-T02
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "5482f3cd-36cb-55e0-8c52-0ca2340ed4d7"
|
||||
```
|
||||
|
||||
Owner: `flex-auth`; key custody is **not** ours to invent.
|
||||
|
||||
- Detached signature over the canonical envelope, preferred over transport-only
|
||||
mTLS for two reasons: it survives the transport, so a decision audited later
|
||||
is still attributable, where mTLS authenticates a connection that no longer
|
||||
exists; and it composes with `FLEX-DEC-2026-009`, since a record that names
|
||||
its authenticated caller *and* carries flex-auth's signature is an audit
|
||||
artifact where either alone is a claim.
|
||||
- Decide the canonical form to sign. The existing canonical-JSON rules from
|
||||
`docs/canonical-request-digest.md` are the obvious basis, but the signed
|
||||
material is the **envelope**, not the request, and it must exclude the
|
||||
signature field itself. Write it down before implementing: an implicit
|
||||
canonicalisation rule is what `FLEX-DEC-2026-007` had to correct.
|
||||
- **Do not mint a key in this repo.** Route custody via
|
||||
`warden route find "decision envelope signing key"` and OpenBao, per the
|
||||
estate credential-routing rule. flex-auth decides the shape; it does not own
|
||||
key material.
|
||||
- State key rotation and how a consumer discovers the current public key, since
|
||||
a consumer that cannot rotate trust has a pinned key that will one day be
|
||||
wrong.
|
||||
|
||||
Gate: the canonical form, the algorithm, and the custody path are written down
|
||||
and reviewed before any signing code exists.
|
||||
|
||||
**Done 2026-09-14.** Written in `docs/decision-envelope-signature.md`: detached
|
||||
Ed25519 over `json.Marshal` of the envelope with `signature` omitted; unsigned
|
||||
is `{mode: unsigned}`; production key lives in OpenBao, not this repo
|
||||
(proposed catalog id `flex-auth-decision-envelope-signing-key`). Test-only seed
|
||||
is documented and is not the custody path.
|
||||
|
||||
## 3. Implement signing and verification
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0024-T03
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "041612ea-1be4-5997-8c32-49f8bcc50855"
|
||||
```
|
||||
|
||||
Owner: `flex-auth`.
|
||||
|
||||
- Add the signature to `schemas/decision_envelope.schema.json` as additive, and
|
||||
state in the contract that `request_digest` is unaffected so no consumer
|
||||
re-pins — the same note that was needed for v2 and for
|
||||
`approval_binding_digest`.
|
||||
- Emit unsigned when no key is configured, and say so in the envelope rather
|
||||
than omitting the field silently. Absence stated, not implied — the
|
||||
`pdp_digest` precedent.
|
||||
- Ship a verification example and a fixture pair in
|
||||
`examples/secrets-engine/replay/`: a genuine signed envelope and one whose
|
||||
payload was altered after signing, so a consumer's verifier is tested against
|
||||
a real failure rather than only a real success. **A verifier that has never
|
||||
seen an invalid signature is untested**, which is the lesson from every
|
||||
fixture suite in `FLEX-DEC-2026-008`.
|
||||
|
||||
Gate: an altered envelope fails verification, an unaltered one passes, and a
|
||||
consumer can perform both from the fixtures alone.
|
||||
|
||||
**Done 2026-09-14.** Additive `signature` on the schema and envelope. Engine
|
||||
emits `{mode: unsigned}` when no key is configured. Fixture pair:
|
||||
`examples/secrets-engine/replay/decision_rotate_signed.json` verifies,
|
||||
`decision_rotate_signed_tampered.json` does not, same `request_digest`. Public
|
||||
key in `keys.json`. Tests in `internal/sign`.
|
||||
|
||||
## 4. Report the gap to gate-house
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0024-T04
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "82d6b75e-e2c6-5e3d-a897-fbdfb7c9094e"
|
||||
```
|
||||
|
||||
Owner: `flex-auth`.
|
||||
|
||||
§6.4 obligates the PEP to act on a decision and §9.3 splits degraded mode by
|
||||
owner, but **nothing in the standard requires a PDP's response to be
|
||||
authenticable**. So a fully conformant PEP can trust a forged allow while
|
||||
meeting every published obligation. That is a gap in the standard, not only in
|
||||
this implementation, and it belongs in the outstanding v0.8 assent round
|
||||
alongside the `FLEX-DEC-2026-009` finding.
|
||||
|
||||
## T04 closed — 2026-09-07
|
||||
|
||||
**Done.** Reported as `FLEX-DEC-2026-011` F1, ranked blocking for
|
||||
calling the §6.4 PEP obligations complete and explicitly not blocking anyone's
|
||||
adoption of v0.8 — the condition already exists under v0.7 and is not created by
|
||||
this version. §16 already carries the same observation one layer up, about the
|
||||
standard's own publication path having no digest or freeze discipline; F1 is
|
||||
that observation applied to the artifact the standard regulates.
|
||||
|
||||
## 5. Wire owner signing into the decision pin and retained deployment charts
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0024-T05
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "cfe4d275-9f02-5090-8391-06eea59d45c5"
|
||||
```
|
||||
|
||||
2026-10-16 source follow-through: NetKingdom target Secrets Engine R2 owner review
|
||||
found that the completed T03 signature package was used only by fixtures. Add
|
||||
explicit mounted seed/kid configuration for `serve`, sign the final envelope before
|
||||
recording, and expose inert existing-Secret mounts in both retained/new charts.
|
||||
The API/sign verifier sources remain byte-identical. Local source validation and
|
||||
review are in the Custodian `docs/changes/netkingdom-target-2026-10-16/access-verifier-review/`.
|
||||
This is source preparation only, not signer admission or deployed acceptance.
|
||||
|
||||
## 6. Admit custody, consumer trust, exact packages and native signed decisions
|
||||
|
||||
```task
|
||||
id: FLEX-WP-0024-T06
|
||||
status: progress
|
||||
priority: high
|
||||
state_hub_task_id: "7f785b52-bf62-5884-8d34-670d70bc9023"
|
||||
```
|
||||
|
||||
Wait on Platform/OpenBao key custody, independent public-key and issuer/policy-pin
|
||||
admission, exact image and existing-Secret values rollout, owner-bound caller/tunnel,
|
||||
and Secrets Engine verifier installation. Follow `docs/decision-envelope-signature.md`
|
||||
for overlap/removal semantics. Retain signed producer record/consumer acceptance,
|
||||
forged/altered/unsigned/wrong-pin/expired denial and rotation-removal receipts;
|
||||
then update actual deployed status. No signer or runtime trust is admitted by the
|
||||
source review. This task owns the producer-side native gate; SECRETS-WP-0014 owns
|
||||
consumer admission/enforcement. The old fixture completion never established this
|
||||
gate, so the workplan is reopened rather than claiming it already passed.
|
||||
|
||||
|
||||
2026-10-16 owner native preparation: T06 is `progress` because Access still owns
|
||||
signer workload declaration, artifact/provenance and source/provider-join preparation;
|
||||
no unqualified cross-owner wait is claimed. Read-only actual release metadata and
|
||||
bounded proposal are in the Custodian
|
||||
`docs/changes/netkingdom-target-2026-10-16/access-native-preparation/`.
|
||||
The real Platform custody route `flex-auth-decision-envelope-signing-key` exists but
|
||||
is draft/nonresolvable; no production kid/public fingerprint, Secret projection or
|
||||
custody receipt is admitted. Coordinate that named commitment through CUST-WP-0080
|
||||
instead of inventing a Platform task/approval. SECRETS-WP-0014-T03 owns installed
|
||||
consumer native verification and must not form a circular blocking dependency.
|
||||
|
||||
The first proposed native trial only signs the unchanged lifecycle package on the
|
||||
existing retained release; `execute-ccr` remains denied. Current service-pilot
|
||||
`runtime_admission := false` remains mandatory: the source ServicePilotInputs is
|
||||
not yet wired into HTTP, and public service_actor_binding never authenticates the
|
||||
caller. Later activation needs a complete reviewed provider join, exact policy and
|
||||
operation admission, artifact digests, owner execution/rollback proposal and native
|
||||
receipts. Preparation/local synthetic success grants none of those permissions.
|
||||
|
||||
|
||||
2026-10-16 source-only native preparation adds the existing Secrets PDP ServiceAccount
|
||||
to `tenancy.yaml` with evidence in `docs/native-signer-workload.json`, makes the
|
||||
retained `flex-auth` audience explicit, pins CI archive fetch to the full source
|
||||
revision, and adds offline native signer receipt verification using the existing
|
||||
Secrets verifier. No key, trust, image publication or live activation is admitted.
|
||||
The managed workload's missing rapp declaration remains explicit migration debt;
|
||||
this source binding does not fabricate a package declaration or raise its grade.
|
||||
|
||||
|
||||
2026-10-16 separate B1 source follow-through wires ServicePilotInputs through actual
|
||||
HTTP/TokenReview into a signed-DENY-only engine entry. Generic `execute-ccr` calls
|
||||
refuse across every policy, including the old separately named positive fixture;
|
||||
that proof stays pinned to ec21518e. Original context/submitted digest stay unchanged.
|
||||
Actual disposable serve/TLS TokenReview/HTTP signed-DENY and bypass/refusal tests are
|
||||
source evidence only. B2 depends on independently reviewed Approval fact contract
|
||||
and canonical vectors; B3 additionally needs exact source/normalization numeric
|
||||
representation and full trusted provider joins. No current policy false gate,
|
||||
production trust, native deployment or protected effect is enabled by B1.
|
||||
|
||||
2026-10-16 B2/B3 source successor preparation (separate from frozen B1): the
|
||||
isolated v2 source path now joins the fixed authenticated Approval reader,
|
||||
unchanged Approval-owner canonical/fact helper, original/fresh correspondence,
|
||||
raw numeric request/registry source retention, same policy evaluator and signed
|
||||
source provenance. Disposable actual HTTP and production serve subprocess prove
|
||||
synthetic signed ALLOW and fail-closed negative joins with exact response/record
|
||||
parity. See `docs/trusted-service-task-source.md`. T06 remains `progress`: this
|
||||
source proposal requires independent cross-owner review and full consumer/Platform
|
||||
successor integration, then separately admitted runtime custody, source trust,
|
||||
image provenance and rollout. No source-only proof establishes those runtime gates.
|
||||
|
||||
|
||||
2026-10-16 B2/B3 R2 temporal correction (R1 retained): whole-stack review exposed
|
||||
that R1's 15s ALLOW and default Approval freshness30 cannot fit the declared
|
||||
minimum backendTTL30 plus existing cleanupreserve5. The v2 successor now derives
|
||||
exact ALLOW expiry from the immutable operationdeadline, requiring all original/
|
||||
fresh approval/freshness/caller bounds, a conservative source maximum120 and
|
||||
remaining declaredTTL+5 after source I/O/evaluation. No consumer/native deadline
|
||||
or cleanup guard is relaxed. Max structural budgets that cannot fit refuse.
|
||||
The fixture declares backendTTL30/deadline60 and explicit source freshness120;
|
||||
owner runtime source freshness configuration and full native integration remain
|
||||
separate reviewed gates. See docs/trusted-service-task-source.md.
|
||||
|
||||
2026-10-16 B2/B3 R3 follows actual retained-registry integration failure: subject
|
||||
enrichment changed evaluated approval-free digest from the original proposal.
|
||||
The existing signed claim-free DENY now explicitly carries v2 approvalfree digest
|
||||
(equal evaluated requestdigest), enabling producer-owned preapproval facts under
|
||||
the already published enrichment contract. The final original proposal adds only
|
||||
the issued claim; registry drift/refreshed facts cannot silently rebind it.
|
||||
Retained-registry HTTP and production serve proofs and negative joins pass.
|
||||
R3 preserves precise notbefore pending separate Approval-owner timestamp fidelity
|
||||
repair; no rounding waiver, copied registry algorithm or empty-registry workaround.
|
||||
|
||||
2026-10-16 native admission prerequisite: fresh metadata confirms no namespace
|
||||
PVC exists, and current outbox had neither OS writer exclusion nor a byte/startup
|
||||
bound. Prepared existing-outbox hardening on exact canonical R3 base2b064ee:
|
||||
nonblocking Linux flock held through Close/process lifetime before recovery,
|
||||
64MiB source journal ceiling,2MiB record/atomic-batch bounds, streaming startup,
|
||||
4KiB cursor, all-effect commit refusal and fenced unconfirmed rollback. Actual
|
||||
process contention/crash release, capacity/prefix/restart and ENOSPC/fsync failure
|
||||
proofs are part of the owner package. No new service, live mount, deletion or
|
||||
custody grant; exact published successor, new PVC/PV retention/managed-package
|
||||
owner disposition and independent consumer admission remain prerequisites.
|
||||
|
||||
2026-10-16 owner package extraction record: canonical local package
|
||||
`rapp-flex-auth-secrets-engine` now exists at commit
|
||||
`d52f811ed5ec0be27c9c367e71d476125b3228be`, tree
|
||||
`d4fbad71bdc8ef870603526ccd1f53195d0322af`; authoritative declaration
|
||||
`declarations/rapp.yaml` SHA256 `0b722431bc5162dd86f72b15f12424e149aca8f2a8790adf2c57e8511ea73b4c`.
|
||||
Repo Manager exact local resolution under `/home/worsch` returns
|
||||
`rapp-flex-auth-secrets-engine` / workload `flex-auth-secrets-engine` /
|
||||
deployable `flex-auth-secrets-engine`, ownership `access-engine`, readiness
|
||||
`draft`. The retained lifecycle PDP is the only rollback boundary claimed;
|
||||
tenant/user/canary and retired `rapp-secrets-engine` remain excluded. Normative
|
||||
focused family validation passes; existing unrelated global rapp-forgejo error
|
||||
and reef projection warning remain visible. Package extraction keeps source
|
||||
`2b064eee510640224274ccdc7cefceb1ae13162e` and current image
|
||||
`sha256:05a03a8790c2210c48ea92391441c77ddf640d0cd32f5ec09838f5393171fcbd`
|
||||
unchanged. Exact local source resolution is no central/private read-placement,
|
||||
reef binding, custody, native rollout or consumer trust admission. Future signer
|
||||
image/config adoption remains separate. T06 remains `progress`; no second work
|
||||
item duplicates this bounded dependency.
|
||||
|
||||
|
||||
2026-10-16 bounded stopped-chart source preparation (Custodian
|
||||
`access-native-admission/stopped-chart-r2`): both outbox charts admit numeric
|
||||
replicaCount exactly 0 (maintenance stop) or 1 (single writer), with Recreate,
|
||||
process flock and bounded persistence unchanged. Fractions, strings, booleans,
|
||||
negative values and 2+ refuse; Helm decodes YAML/JSON integral 0.0/1.0 as the same
|
||||
numeric values as 0/1, so lexical float spelling is not distinguished. Actual
|
||||
Helm stopped/ready renders differ only in replicas and retain the same Platform
|
||||
source-rendered deployment projection. Owner preparation and independent
|
||||
coordinator checks approve this bounded source change only; 86 Helm renders and
|
||||
the existing outbox/delivery/receiver-port suite pass. No native stop, bootstrap,
|
||||
rollout, custody, public trust, resource or protected-effect approval follows.
|
||||
The proposed immutable image remains source revision
|
||||
`84c78e072c8f3daf2bc3b90f8efc8fbeb16c3cf0`, ordinary CI402 verified digest
|
||||
`sha256:09a83b273740133518cc7e7915fb211381e06545d347d2dd1974042525ac981f`.
|
||||
This chart-only successor requires its own exact source/chart pin and reviewed
|
||||
runtime scope; it can explicitly select the unchanged verified 84 image without
|
||||
rebuilding it or claiming that its revision label names the new chart commit.
|
||||
These chart/test/workplan-only paths do not trigger the existing image workflow.
|
||||
Frozen rollout R1, Platform P2 and the package extraction2b/current05a remain
|
||||
unchanged. T06 stays `progress`; actual stopped-fence verification and all native
|
||||
admission gates remain open under the same existing task.
|
||||
|
||||
|
||||
2026-10-16 Access owner exact native plan review (Custodian
|
||||
`access-native-plan-review-next/`): approved bounded Access workload/Helm/outbox/
|
||||
stopped-only rollback plan for frozen rollout R2 manifest5be7a7f and Platform P4
|
||||
manifest9eec861, chartdc0420/image84c78e OCI09a83b/projection8ce375f. Offline
|
||||
verification checks every R2 manifest/source digest and reproduces both exact
|
||||
Helm render bytes. The mandatory execution supplement names actual repo/Helm/CI
|
||||
paths and excludes unrelated legacy rollback recipes, records the owner/founder
|
||||
manual-writer acknowledgement, supplies a verified stopped-revision rollback
|
||||
shape, and separates120-second stop/readiness gates from atomic rollback and
|
||||
the600-second recovery decision. No production source change was needed.
|
||||
Existing read-only preflight admits all7exact resources but still observes
|
||||
unsigned05a/revision4running, no installed stopped fence or held window. T06
|
||||
stays progress: actual founder entity/expiry/window/executor and five final
|
||||
external scope dispositions, custody/trust/caller, actual stopped Helm revision,
|
||||
PVC/PV Retain and native producer/consumer/restart/failure receipts remain open.
|
||||
No live mutation, credential access, new key, authority or protected effect follows.
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
{
|
||||
"source_commit": "git:1b8dc0a8fdeabbc2d9619006e9b837ac27fc847a",
|
||||
"primary_projection_exact": true,
|
||||
"instance_role": "primary",
|
||||
"instance_label": "railiance01",
|
||||
"unrelated_worktree_files_preserved": 11,
|
||||
"original_brief_and_work_records_index_preserved": true,
|
||||
"workplan_status": "active",
|
||||
"native_gates_fully_closed": 0,
|
||||
"goal_complete": false
|
||||
}
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
{
|
||||
"prior_base": "git:aae10f5bbb6b8380fa9a8dcb955c5825c14dcaae",
|
||||
"current_base": "git:81f2f596498f431b64a9a62951b7206596bd5974",
|
||||
"intervening_paths": [
|
||||
"docs/changes/CUST-WP-0080/accept_forge_routes.py",
|
||||
"docs/changes/CUST-WP-0080/forge-routes-proposal-r2.json",
|
||||
"docs/changes/CUST-WP-0080/forge-routes-proposal.json",
|
||||
"docs/changes/CUST-WP-0080/test_forge_routes_safety.py",
|
||||
"docs/evidence/2026-10-13-netkingdom-security/forge-routes-live.json",
|
||||
"docs/evidence/2026-10-13-netkingdom-security/forge-routes-live.transport.json",
|
||||
"docs/evidence/2026-10-18-netkingdom-security/forge-routes-isolated-3.baseline.json",
|
||||
"docs/evidence/2026-10-18-netkingdom-security/forge-routes-isolated-3.json",
|
||||
"docs/evidence/2026-10-18-netkingdom-security/forge-routes-live-r3.json",
|
||||
"docs/evidence/2026-10-18-netkingdom-security/forge-routes-live-r3.transport.json"
|
||||
],
|
||||
"publication_paths_overlap": false,
|
||||
"history_rewritten": false
|
||||
}
|
||||
|
|
@ -0,0 +1,142 @@
|
|||
{
|
||||
"repo_slug": "the-custodian",
|
||||
"repo_path": "/home/worsch/the-custodian",
|
||||
"source_revision": "1b8dc0a8fdeabbc2d9619006e9b837ac27fc847a",
|
||||
"source_revision_reason": null,
|
||||
"issues": [
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-35",
|
||||
"message": "Repo Manager warning: workplans/: repository uses more than one workplan prefix: ['CUST-WP', 'THE-WP']",
|
||||
"file_path": "workplans/",
|
||||
"db_id": "",
|
||||
"file_value": "",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-35",
|
||||
"message": "Repo Manager contradictory: workplans/ADHOC-2026-08-25-retired.md: workplan id 'CUST-WP-ADHOC-2026-08-25-RETIRED' is not accepted by the canon kind registry",
|
||||
"file_path": "workplans/ADHOC-2026-08-25-retired.md",
|
||||
"db_id": "",
|
||||
"file_value": "",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-05",
|
||||
"message": "Title drift in 'cust-wp-0010': file='Domain and Repository Goals' db='Workplan Lifecycle Documentation' (file wins)",
|
||||
"file_path": "workplans/CUST-WP-0010b-domain-and-repo-goals.md",
|
||||
"db_id": "def8455a-9de4-4891-a15a-5b09ca98ab1e",
|
||||
"file_value": "Domain and Repository Goals",
|
||||
"db_value": "Workplan Lifecycle Documentation",
|
||||
"fixable": true
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-20",
|
||||
"message": "Workplan dependency target 'STATE-WP-0092' is not linked to State Hub",
|
||||
"file_path": "workplans/CUST-WP-0072-fleet-flavor-and-depends-on-backfill.md",
|
||||
"db_id": "",
|
||||
"file_value": "STATE-WP-0092",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-40",
|
||||
"message": "blocker satisfied, task still wait: 'CUST-WP-0073-T05' in workplan 'CUST-WP-0073' \u2014 decision 1591daa1-6e85-4dfd-aadd-5a9fe1ef47fa is resolved",
|
||||
"file_path": "workplans/CUST-WP-0073-agent-credential-separation.md#CUST-WP-0073-T05",
|
||||
"db_id": "",
|
||||
"file_value": "1591daa1-6e85-4dfd-aadd-5a9fe1ef47fa",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-39",
|
||||
"message": "Human wait task 'CUST-WP-0079-T06' in workplan 'CUST-WP-0079' has needs_human: true without decision_id \u2014 unrouted human gate",
|
||||
"file_path": "workplans/CUST-WP-0079-deterministic-security-flow.md#CUST-WP-0079-T06",
|
||||
"db_id": "",
|
||||
"file_value": "needs_human: true",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-22",
|
||||
"message": "Task description drift 'CUST-WP-0080-T03': file content differs from DB (file wins)",
|
||||
"file_path": "workplans/CUST-WP-0080-netkingdom-security-blueprint-and-gap-closure.md#CUST-WP-0080-T03",
|
||||
"db_id": "87637402-02f1-57c1-8fbc-4141598af8e3",
|
||||
"file_value": "Start with the reproduced DN-subject validation defect in existing KEY-WP-0040.\nReconcile G04/G07/G08/G10/G12/G13 agains",
|
||||
"db_value": "Start with the reproduced DN-subject validation defect in existing KEY-WP-0040.\nReconcile G04/G07/G08/G10/G12/G13 agains",
|
||||
"fixable": true
|
||||
},
|
||||
{
|
||||
"severity": "INFO",
|
||||
"check_id": "C-08",
|
||||
"message": "Closed DB workstream 'cust-wp-0010b' (id=416ff571\u2026, status=finished) has no backing workplan file",
|
||||
"file_path": "",
|
||||
"db_id": "416ff571-18cf-5cb2-9c8b-836f68a301b3",
|
||||
"file_value": "",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "INFO",
|
||||
"check_id": "C-08",
|
||||
"message": "Retired DB workstream 'interactive-the-custodian@retired-20260828' (id=370c2481\u2026, status=finished) has no backing workplan file \u2014 projection tombstone, not live work",
|
||||
"file_path": "",
|
||||
"db_id": "370c2481-6806-41eb-a917-f8874f03184f",
|
||||
"file_value": "",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "INFO",
|
||||
"check_id": "C-08",
|
||||
"message": "Retired DB workstream 'adhoc-2026-05-02@retired-20260827' (id=3f54ce9c\u2026, status=finished) has no backing workplan file \u2014 projection tombstone, not live work",
|
||||
"file_path": "",
|
||||
"db_id": "3f54ce9c-1f95-42de-894f-0f81a52ba2e8",
|
||||
"file_value": "",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "INFO",
|
||||
"check_id": "C-08",
|
||||
"message": "Retired DB workstream 'the-custodian-adhoc-2026-07-02@retired-20260827' (id=5c53733b\u2026, status=finished) has no backing workplan file \u2014 projection tombstone, not live work",
|
||||
"file_path": "",
|
||||
"db_id": "5c53733b-c077-4a93-be66-9c3af8f9b6fd",
|
||||
"file_value": "",
|
||||
"db_value": "",
|
||||
"fixable": false
|
||||
},
|
||||
{
|
||||
"severity": "WARN",
|
||||
"check_id": "C-26",
|
||||
"message": "Workplan id 'THE-WP-0001' uses prefix 'THE-WP' but repo canonical prefix is 'CUST-WP' \u2014 new plans must conform",
|
||||
"file_path": "workplans/THE-WP-0001-federation-interface.md",
|
||||
"db_id": "",
|
||||
"file_value": "THE-WP-0001",
|
||||
"db_value": "CUST-WP",
|
||||
"fixable": false
|
||||
}
|
||||
],
|
||||
"fixes_applied": [
|
||||
"bindings: synced 89/89",
|
||||
"C-17 cleared: pushed 2 backlogged commit(s)",
|
||||
"C-05 fixed: workstream def8455a\u2026 title \u2192 'Domain and Repository Goals'",
|
||||
"C-22 fixed: task 87637402\u2026 description updated",
|
||||
"push: pushed"
|
||||
],
|
||||
"summary": {
|
||||
"fail": 0,
|
||||
"automation_error": 0,
|
||||
"warn": 8,
|
||||
"info": 4
|
||||
},
|
||||
"result": "warn"
|
||||
}
|
||||
|
|
@ -0,0 +1 @@
|
|||
WARN: working-memory commit failed: Generated-only commits rejected: staged
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
{
|
||||
"reason": "Build inputs and logs are ignored by generic repository patterns; these exact public source/evidence paths are required for a reproducible capsule.",
|
||||
"paths": [
|
||||
"docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/container-build.log",
|
||||
"docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/embedded-and-static-backend.log",
|
||||
"docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/replay-container-build.log",
|
||||
"docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-source/build/forgejo/README.md",
|
||||
"docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-source/build/forgejo/forgejo-security-extension.patch",
|
||||
"docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-source/build/forgejo/inputs.lock.json",
|
||||
"docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-source/build/forgejo/runtime-base-config.json"
|
||||
]
|
||||
}
|
||||
|
|
@ -0,0 +1,325 @@
|
|||
{
|
||||
"exit_code": 1,
|
||||
"commit": "aae10f5bbb6b8380fa9a8dcb955c5825c14dcaae",
|
||||
"base": "aae10f5bbb6b8380fa9a8dcb955c5825c14dcaae",
|
||||
"files": [
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/cust80-completion-r2/completion-audit.json",
|
||||
"sha256": "001ede40ad6d7cadcfc575a101828f782f65ea0c75e6a5e0f6b0afe761420b0d"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/actual-issuer-test-summary.json",
|
||||
"sha256": "fae6563963eda88dcc1dc231d7c7dec8bca50fd238d5a84c4920203fd9076807"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/composed-forgejo-source.patch",
|
||||
"sha256": "15cb7f13b1b1d1095cc344176ca337f705333a436a70ae803fcfd3d7f802ccf4"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/composed-patch-verification.json",
|
||||
"sha256": "c7be6167d511df96db68396bea9e05af730d360624789c72bcd447e34ca7776d"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/composed-source-inventory.json",
|
||||
"sha256": "a9bdaef559b010cbe6c884c34141c787c7e1cf56a8b58b9b4c9d387815ce97c7"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after-attempt2.json",
|
||||
"sha256": "0d1db244928063aae16959956115828a0d64e9238ca85f397917ae8c4e260a01"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after-attempt2.jsonl",
|
||||
"sha256": "961c5c121280e8cd38fc3386e30fcd92e9290fb19b7df68a26cbd579b4567c9c"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after-attempt3.json",
|
||||
"sha256": "860d3e3d02f6bb1ffff09f01725aba933879292741c31481bb822dbfb24ad313"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after-attempt3.jsonl",
|
||||
"sha256": "e30775857f9f904731779d2a8167b337806ec375bf9398c9147212a7ab3ecf78"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after.json",
|
||||
"sha256": "9b49035400a123442f93ff3405d03e5380f5cd72b4767516a9bb71cb3e29d9a2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after.jsonl",
|
||||
"sha256": "455776e610d2bf0b120a7c3bcd1b57e18f54861d62419a703ddcd578a3da3deb"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-before.jsonl",
|
||||
"sha256": "222e34ec71e62a895728e5b2b7aa53ebf146e7f26e226fd58c316b1143b0cfbd"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine.go",
|
||||
"sha256": "d5f07f9491ac2212410e1fa8c0248d68ba3a723e7ca99e363627c5292d187aa8"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine_assurance.go",
|
||||
"sha256": "42de751b1e9a243301d566260954813b770558ecb449639acaeab307fe788642"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine_assurance_test.go",
|
||||
"sha256": "44e7459f6c1106a264093c19d61d01a8365f6ad22682906552d832ba39d61dd3"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine_callback_test.go",
|
||||
"sha256": "5cea36b630c895a9473dc876b7128526ddef65d9395b2fddc56343e162452472"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine_test.go",
|
||||
"sha256": "99edd6cfe3e834d73e0447a7915f52cc4ab7b82644669c5ae61963f850b447e8"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-test-attempt1.json",
|
||||
"sha256": "c75ce102ed7e1a37458ebf03d3e617d2cf69ac3570f085910f5f0a77417b72ef"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer_wire_after_test.go",
|
||||
"sha256": "ca411819ebbe9f4576fa2dd8722ddcaf09d868dbafb3e9a2c6f114c865903a9a"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/coordinator-source-review.json",
|
||||
"sha256": "df05e694aa7da5da3b152b423ae04bd5f836a4b9c2c0d21e246bfd4bc8ca0763"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/freeze_composite.py",
|
||||
"sha256": "42caf7444d83fb81e4adb4a287590dd3572059c35be9477c43f185e6e93bfc30"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-attempt2.jsonl",
|
||||
"sha256": "f02f19667656e6a7077b54da2824e45ec7556bb82ced4d3140da61a507706148"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-attempt3.jsonl",
|
||||
"sha256": "5b94c52dc70e1447c8c9e723d2c65106c46fcd0e84dafe13b324a54ebc5381b9"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-attempt4.jsonl",
|
||||
"sha256": "dc0d6142807c6e5a3c60d83f646f5118f25b82835adb5afdee0f68e80bb5fcc2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-attempt5.jsonl",
|
||||
"sha256": "955aef3da3431583202fe9ecc8b030f4374786580e605d9848f6a34121a783e2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-result-attempt2.json",
|
||||
"sha256": "5a454d2586aa4933f85bd9c1a05c0692d434ee78218b9115e714c28c125a420b"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-result-attempt3.json",
|
||||
"sha256": "2364d756120bc90dcd86190900adb26c13f3cbbcd2c5052ee34a0027d6efa8ff"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-result-attempt4.json",
|
||||
"sha256": "eaaa50c708e390f34df0deb949cf4f220bc41b9bf78472c55d83d84b20a8c615"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-result-attempt5.json",
|
||||
"sha256": "a1bf3fff4410d0ef3b16e0ca23c4d16239eff91eaa1d2b52bb0d1efcf26fda93"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture.jsonl",
|
||||
"sha256": "c47bfeb94dae0a6b47bcc4a28c9ea765d98b3a0b72b754dc6148238e0894a894"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/apply_source.py",
|
||||
"sha256": "30b954de9c00f0d907f9bbe3427b45b005cbe3884a85c0a8f51050d45dc3f90a"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/consistency.json",
|
||||
"sha256": "cb2f373865ddbe1892dc9da36bad0d4409ebe5e768f2e90e8699e6686a00781a"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/consistency.stderr.txt",
|
||||
"sha256": "f4a6aa1609a13600a0b97cbb08bbc03b3e247b619ff37912d37f7e109ce798ba"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/projection.json",
|
||||
"sha256": "a7f8b1c91a979d22c3236a6c3be044861f17638ff6656556a1c351383d2a5405"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/projection.stderr.txt",
|
||||
"sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/publication-commit.json",
|
||||
"sha256": "fcf90731e5c0f2a331fb17efe612701660f7873cf429f12c346342768aaf921b"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/publication-inputs.json",
|
||||
"sha256": "ab332f463433cac098427a7fc14de4f4e5ae14b142fcbca4158ca65f2dbd10f1"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/source-application.json",
|
||||
"sha256": "4ff72df57513f5bcbdee085408accce70f8f3d1d99b0528aca97f654c6ded979"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/source-manifest.json",
|
||||
"sha256": "efc3581a2b2a00001b5108e86f2884c6586453dc1adf7af8cffe176ffe354228"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/task-bindings-readback.json",
|
||||
"sha256": "cb8baec6401f0ce858092fcf082b1765b3876baf9933ea9c32f9bcf23bb55853"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/workplan-preimage.md",
|
||||
"sha256": "0ac8db087247bf980339ef8661a26eeb817af82391e3e85038be773fe3c6fb3a"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/workplan.md",
|
||||
"sha256": "95b48b308d5154f87355b2c230dc9990241aeeb37c2094e164952150ed2fd258"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/preimages/access_engine.go",
|
||||
"sha256": "851dc8712c883ec2f3135406cdce58d7adf733c0f79501e2594e41646faf28a2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/preimages/access_engine_callback_test.go",
|
||||
"sha256": "e2fcbfcc2f1077996c947c5c6fd5150aaaa11ba0e77e05f07055a355978398be"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/preimages/access_engine_test.go",
|
||||
"sha256": "0552719648e821243c5c6f887359a724c1440cd077e435f15a444bd3c99da888"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/prepare_composite.py",
|
||||
"sha256": "b90e642b4db70a49503278879c076718f5bd7f1f13edc06916bb07fbcbd2a63f"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/produce_fixture.py",
|
||||
"sha256": "30ad0c84592d7a2cbbbe592f68ec4dfa38af04a8a7088907470003ea869074c8"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/producer-slice-parity.json",
|
||||
"sha256": "81ba3e2e8689edfea31eae39970bc29779d63e9cbab8f17e82998d37b5e90441"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/binary-version-result.json",
|
||||
"sha256": "5b34ec6398ed2c658d22bcfc68375831fe1d8f681fc01ec37443d411e9fa0762"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/build.json",
|
||||
"sha256": "b40b6bc4181a9b1932b0c2db7ea1d1c9d4dfa0477768eeef906fc7cee993aacd"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/cli-attempts.json",
|
||||
"sha256": "338949ece2f2ee5817d274ab52b23090d30f85912882e3f054bb394dfa5d8562"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/cli-report-scope.json",
|
||||
"sha256": "bc0829c2830a1c95d671d110f9dbe2c97815ecab0246f707ff0bc98f81283359"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/cli-results.json",
|
||||
"sha256": "ad07393a5c02636209ee4c50aa6a8ac94357c7eef69407aa0326f5c044b55ef5"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/container-build-result.json",
|
||||
"sha256": "eab449c68eb172bd55d5ccabbb26acb04c305305f4fc73977566811f0242b2ea"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/container-reproduction.json",
|
||||
"sha256": "acb13b9c2135c69e814fdea23fd53688cedbd55c91e127ac190543318e1eee96"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/container-result.json",
|
||||
"sha256": "b9e349566278650ea5db54ae1b337768400be3c4502a55901d8a72059b480333"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/embedded-and-static-backend-result.json",
|
||||
"sha256": "fbac11b0da3f2ef3ee496de2a5aa50bd5e745e46562c64313c596a17aa313f79"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/embedded-extract-result.json",
|
||||
"sha256": "36829b0e4be299de56383b9d46e71e12a03b0b271c924da176c5967b924ae1a1"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/embedded-files.json",
|
||||
"sha256": "74a0ec278ab99ac86ee434d7620229dc4a70146efd51876a1e4738d2c9f4ffdb"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/frontend-result.json",
|
||||
"sha256": "589716f5332480f32f9c67f55129ae5d074770b4d7d815e21f37a7379569e706"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/image-build-metadata.json",
|
||||
"sha256": "5c401df606f8942d2b072347cfea966736b371fb8003696f49262db5aeaa5ff6"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/new-cli-help-result.json",
|
||||
"sha256": "a1c6b33dd1abba2a4f16a5f122362572f0c6a2b83687c6363e9ec362b0771622"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/npm-offline-ci-result.json",
|
||||
"sha256": "9fcacf720b68412990549f2ee122541991993fa3d2352b57987789c9ec828407"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/npm-public-acquire-result.json",
|
||||
"sha256": "de88d9ef86c7e3cb3d234953d23e452f1f12e98e8c3c7faa798863ff8377c84c"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/prepared.json",
|
||||
"sha256": "01bf2cad8dc13fc780db68fec8dcf1bd0da9fbaac13c2923c048f16cf20c49f2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/public-node-checksum.json",
|
||||
"sha256": "71873490b48c325fd9f024f1a0a6979f90d64cf8ae71eb1e2451adcc4819e0b2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/replay-container-build-result.json",
|
||||
"sha256": "15c4a835a4ae72e5f5ecb7c59cb0478357404a6c658d87cbc2603b9e7794879e"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/replay-container-result.json",
|
||||
"sha256": "377a8de444594bef7e16d12331b4843511d078664323ae0b12ba0f12df2093b3"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/replay-image-build-metadata.json",
|
||||
"sha256": "a3582299cf44f29da0c5f3958681141953d100958dd51288be3eb712b78740a8"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/verification.json",
|
||||
"sha256": "17311f339925e54fc6c7c745dee7f38fd69099aa95e0d4dfcc3eae586f60d9d9"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/verify-go-modules-result.json",
|
||||
"sha256": "167646f03fce836e8cee2a848ac38b778e2949e1987e47a1a734924518fcb69d"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-source/tools/forgejo-release-build.py",
|
||||
"sha256": "bd5b15ff2ca1e5694903aed3cd47c4fd1fb8baa43c49dd291029a9c9739cc96c"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-validation.json",
|
||||
"sha256": "eef356c3e747947a10a1e8a247cbf6392f48bea972373fb53848463d683e88f0"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/run_composed.py",
|
||||
"sha256": "3d7f96305b571f4d84244432b20902ddee0d87a63ea312e7c221443c5a080914"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/run_consumer_wire.py",
|
||||
"sha256": "b58edfa22092eea3fa0235d8de7d65c7bce1a3930499902a2e4641c288a53a5e"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/selected-package-test-summary.json",
|
||||
"sha256": "61e3464644b5838619544efdfe7c5ddc97c7cbc7d5e2dae35fb340779c2a532d"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/test_release_cli.py",
|
||||
"sha256": "1f722a55ac97eebdd88abb5f28969e9726f4203d91a139139ef5ce3ee67ccfa6"
|
||||
},
|
||||
{
|
||||
"path": "docs/netkingdom-target-implementation.md",
|
||||
"sha256": "0c2431dd50f89d542d4a1982a048263f0781a08e00c67e8459c238a247961422"
|
||||
},
|
||||
{
|
||||
"path": "workplans/CUST-WP-0080-netkingdom-security-blueprint-and-gap-closure.md",
|
||||
"sha256": "1e8573140955925c4862055e5eb94dc5fab6b1f66f5be88ee9cd299ab1a98599"
|
||||
}
|
||||
],
|
||||
"stdout": "",
|
||||
"stderr": "{\"blocked_blob_ids\": [\"6997c0c2bff0636d1c8cf6f25acedceef000c876\"], \"scanned_blobs\": 79, \"scanner_sha256\": \"88f91962aa2f93ac6ab281d553b9e125f5197bbbce38f9f2437f7299c32e5509\", \"scanner_version\": \"8.30.1\", \"scope\": \"changed-staged-blobs\", \"status\": \"blocked\"}\n"
|
||||
}
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
{
|
||||
"workplan_id": "dfadb19b-445e-59c6-bcd6-48e87b912c52",
|
||||
"id": "947b56c2-3673-46a8-a775-9815a009f2ee",
|
||||
"topic_id": null,
|
||||
"task_id": "87637402-02f1-57c1-8fbc-4141598af8e3",
|
||||
"decision_id": null,
|
||||
"event_type": "note",
|
||||
"summary": "CUST-WP-0080 continuation: corrected actual KeyCape structured assurance/authentication-time/tenant provenance interoperability in the Forgejo consumer. Actual issuer/provider/discovery/UserInfo/callback suite: 77 passes; selected composed packages: 93 passes, no skips. Complete frontend/static release built; 2234 embedded assets exact; 48 real release CLI/SQLite checks pass; two fresh no-cache OCI exports have identical archive/manifest/config/index. Apps source commit 3fb031a47ff5379358fd8cc230b40961b3b5d3a8 is published with all 9 task bindings retained, T09 progress. Custodian source/evidence commit 1b8dc0a8fdeabbc2d9619006e9b837ac27fc847a retains full16 gates/G01-G13/116 ledger scope. Scanner refusal on public asset hashes retained; verified typed SHA-256 metadata passes unchanged scanner. All 11 unrelated worktree files preserved, including concurrent Forgejo route work. Existing operation/inverse sessions, ongoing protected paths, release-wide writer exclusion, custody/retention, independent owner review and native acceptance remain open; no native gate closed and workplan/goal remain active. Evidence: docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1 and cust80-completion-r2.",
|
||||
"detail": null,
|
||||
"author": "codex",
|
||||
"session_id": null,
|
||||
"created_at": "2026-10-18T00:44:10.492004Z",
|
||||
"workstream_id": "dfadb19b-445e-59c6-bcd6-48e87b912c52"
|
||||
}
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
{
|
||||
"summary": "CUST-WP-0080 continuation: corrected actual KeyCape structured assurance/authentication-time/tenant provenance interoperability in the Forgejo consumer. Actual issuer/provider/discovery/UserInfo/callback suite: 77 passes; selected composed packages: 93 passes, no skips. Complete frontend/static release built; 2234 embedded assets exact; 48 real release CLI/SQLite checks pass; two fresh no-cache OCI exports have identical archive/manifest/config/index. Apps source commit 3fb031a47ff5379358fd8cc230b40961b3b5d3a8 is published with all 9 task bindings retained, T09 progress. Custodian source/evidence commit 1b8dc0a8fdeabbc2d9619006e9b837ac27fc847a retains full16 gates/G01-G13/116 ledger scope. Scanner refusal on public asset hashes retained; verified typed SHA-256 metadata passes unchanged scanner. All 11 unrelated worktree files preserved, including concurrent Forgejo route work. Existing operation/inverse sessions, ongoing protected paths, release-wide writer exclusion, custody/retention, independent owner review and native acceptance remain open; no native gate closed and workplan/goal remain active. Evidence: docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1 and cust80-completion-r2.",
|
||||
"event_type": "note",
|
||||
"author": "codex",
|
||||
"workplan_id": "dfadb19b-445e-59c6-bcd6-48e87b912c52",
|
||||
"task_id": "87637402-02f1-57c1-8fbc-4141598af8e3"
|
||||
}
|
||||
|
|
@ -0,0 +1,292 @@
|
|||
{
|
||||
"ok": true,
|
||||
"status": "applied",
|
||||
"repo_slug": "the-custodian",
|
||||
"commit": "1b8dc0a8fdeabbc2d9619006e9b837ac27fc847a",
|
||||
"requests": 2,
|
||||
"elapsed_ms": 9795.9,
|
||||
"git": {
|
||||
"upstream": "origin/main",
|
||||
"behind": 0,
|
||||
"ahead": 0
|
||||
},
|
||||
"identifiers": {
|
||||
"schema": "repo-manager.identifier-assignment.v1",
|
||||
"ok": true,
|
||||
"executed": true,
|
||||
"repo": "the-custodian",
|
||||
"namespace": "helixforge",
|
||||
"assignments": [],
|
||||
"historical_invalid_identifiers": [
|
||||
{
|
||||
"kind": "workplan",
|
||||
"id": "CUST-WP-ADHOC-2026-08-25-RETIRED",
|
||||
"source": "workplans/ADHOC-2026-08-25-retired.md"
|
||||
}
|
||||
],
|
||||
"historical_identity_collisions": [],
|
||||
"files_changed": []
|
||||
},
|
||||
"receipt": {
|
||||
"schema": "state-hub.repository-projection-reconcile.v1",
|
||||
"instance_role": "primary",
|
||||
"instance_label": "railiance01",
|
||||
"expected_commit": "1b8dc0a8fdeabbc2d9619006e9b837ac27fc847a",
|
||||
"derived_commit": "1b8dc0a8fdeabbc2d9619006e9b837ac27fc847a",
|
||||
"outcome": {
|
||||
"schema": "state-hub.projection-reset.v1",
|
||||
"repo_slug": "the-custodian",
|
||||
"commit": "1b8dc0a8fdeabbc2d9619006e9b837ac27fc847a",
|
||||
"status": "applied",
|
||||
"counts": {
|
||||
"created": 0,
|
||||
"updated": 88,
|
||||
"retired": 0,
|
||||
"refused": 0,
|
||||
"released": 0,
|
||||
"created_tasks": 0,
|
||||
"updated_tasks": 0,
|
||||
"cancelled_tasks": 0,
|
||||
"created_edges": 0,
|
||||
"removed_edges": 0,
|
||||
"unresolved_edges": 0,
|
||||
"external_edges": 13
|
||||
},
|
||||
"created": [],
|
||||
"updated": [
|
||||
"CUST-WP-0000",
|
||||
"CUST-WP-0000b",
|
||||
"CUST-WP-0000c",
|
||||
"CUST-WP-0001",
|
||||
"CUST-WP-0002",
|
||||
"CUST-WP-0004",
|
||||
"CUST-WP-0005",
|
||||
"CUST-WP-0006",
|
||||
"CUST-WP-0007",
|
||||
"CUST-WP-0008",
|
||||
"CUST-WP-0009",
|
||||
"CUST-WP-0010",
|
||||
"CUST-WP-0010b",
|
||||
"CUST-WP-0013",
|
||||
"CUST-WP-0014",
|
||||
"CUST-WP-0015",
|
||||
"CUST-WP-0016",
|
||||
"CUST-WP-0017",
|
||||
"CUST-WP-0017-LEGACY",
|
||||
"CUST-WP-0018",
|
||||
"CUST-WP-0019",
|
||||
"CUST-WP-0020",
|
||||
"CUST-WP-0021",
|
||||
"CUST-WP-0022",
|
||||
"CUST-WP-0023",
|
||||
"CUST-WP-0024",
|
||||
"CUST-WP-0025",
|
||||
"CUST-WP-0026",
|
||||
"CUST-WP-0027",
|
||||
"CUST-WP-0028",
|
||||
"CUST-WP-0029",
|
||||
"CUST-WP-0030",
|
||||
"CUST-WP-0031",
|
||||
"CUST-WP-0032",
|
||||
"CUST-WP-0033",
|
||||
"CUST-WP-0034",
|
||||
"CUST-WP-0035",
|
||||
"CUST-WP-0036",
|
||||
"CUST-WP-0037",
|
||||
"CUST-WP-0039",
|
||||
"CUST-WP-0040",
|
||||
"CUST-WP-0041",
|
||||
"CUST-WP-0043",
|
||||
"CUST-WP-0044",
|
||||
"CUST-WP-0045",
|
||||
"CUST-WP-0046",
|
||||
"CUST-WP-0047",
|
||||
"CUST-WP-0048",
|
||||
"CUST-WP-0049",
|
||||
"CUST-WP-0050",
|
||||
"CUST-WP-0051",
|
||||
"CUST-WP-0052",
|
||||
"CUST-WP-0053",
|
||||
"CUST-WP-0053-LEGACY",
|
||||
"CUST-WP-0054",
|
||||
"CUST-WP-0055",
|
||||
"CUST-WP-0056",
|
||||
"CUST-WP-0057",
|
||||
"CUST-WP-0058",
|
||||
"CUST-WP-0059",
|
||||
"CUST-WP-0060",
|
||||
"CUST-WP-0061",
|
||||
"CUST-WP-0062",
|
||||
"CUST-WP-0063",
|
||||
"CUST-WP-0064",
|
||||
"CUST-WP-0065",
|
||||
"CUST-WP-0066",
|
||||
"CUST-WP-0067",
|
||||
"CUST-WP-0068",
|
||||
"CUST-WP-0069",
|
||||
"CUST-WP-0070",
|
||||
"CUST-WP-0071",
|
||||
"CUST-WP-0072",
|
||||
"CUST-WP-0073",
|
||||
"CUST-WP-0074",
|
||||
"CUST-WP-0075",
|
||||
"CUST-WP-0076",
|
||||
"CUST-WP-0077",
|
||||
"CUST-WP-0078",
|
||||
"CUST-WP-0079",
|
||||
"CUST-WP-0080",
|
||||
"CUST-WP-0081",
|
||||
"CUST-WP-ADHOC-2026-03-29",
|
||||
"CUST-WP-ADHOC-2026-05-02",
|
||||
"CUST-WP-ADHOC-2026-07-02",
|
||||
"CUST-WP-ADHOC-2026-08-25",
|
||||
"CUST-WP-ADHOC-2026-09-06",
|
||||
"THE-WP-0001"
|
||||
],
|
||||
"retired": [],
|
||||
"released": [],
|
||||
"created_tasks": [],
|
||||
"updated_tasks": [],
|
||||
"cancelled_tasks": [],
|
||||
"created_edges": [],
|
||||
"removed_edges": [],
|
||||
"unresolved_edges": [],
|
||||
"external_edges": [
|
||||
{
|
||||
"workplan": "CUST-WP-0071",
|
||||
"from": "CUST-WP-0071-T05",
|
||||
"target": "CUST-WP-0071-T04",
|
||||
"relationship_type": "starts_after",
|
||||
"from_workplan_id": "2249bddb-7524-5add-bd5c-c4163a6ca0f3",
|
||||
"from_task_id": "20ddd4d7-d85d-5b95-bb0a-7b0ca8af76ca",
|
||||
"to_workplan_id": null,
|
||||
"to_task_id": "944f98e2-7e42-5894-925b-752423f3a1cc"
|
||||
},
|
||||
{
|
||||
"workplan": "CUST-WP-0071",
|
||||
"from": "CUST-WP-0071-T03",
|
||||
"target": "CUST-WP-0071-T01",
|
||||
"relationship_type": "starts_after",
|
||||
"from_workplan_id": "2249bddb-7524-5add-bd5c-c4163a6ca0f3",
|
||||
"from_task_id": "6dc67558-eb1e-5bb6-a667-986f884dd495",
|
||||
"to_workplan_id": null,
|
||||
"to_task_id": "4ae8eb8d-f8c5-5256-ae50-c323cfd73d7a"
|
||||
},
|
||||
{
|
||||
"workplan": "CUST-WP-0071",
|
||||
"from": "CUST-WP-0071-T03",
|
||||
"target": "CUST-WP-0071-T02",
|
||||
"relationship_type": "starts_after",
|
||||
"from_workplan_id": "2249bddb-7524-5add-bd5c-c4163a6ca0f3",
|
||||
"from_task_id": "6dc67558-eb1e-5bb6-a667-986f884dd495",
|
||||
"to_workplan_id": null,
|
||||
"to_task_id": "82192370-2fd7-5363-88d2-3c67889d3d68"
|
||||
},
|
||||
{
|
||||
"workplan": "CUST-WP-0071",
|
||||
"from": "CUST-WP-0071-T02",
|
||||
"target": "CUST-WP-0071-T01",
|
||||
"relationship_type": "starts_after",
|
||||
"from_workplan_id": "2249bddb-7524-5add-bd5c-c4163a6ca0f3",
|
||||
"from_task_id": "82192370-2fd7-5363-88d2-3c67889d3d68",
|
||||
"to_workplan_id": null,
|
||||
"to_task_id": "4ae8eb8d-f8c5-5256-ae50-c323cfd73d7a"
|
||||
},
|
||||
{
|
||||
"workplan": "CUST-WP-0071",
|
||||
"from": "CUST-WP-0071-T02",
|
||||
"target": "RAPPS-WP-0014-T03",
|
||||
"relationship_type": "starts_after",
|
||||
"from_workplan_id": "2249bddb-7524-5add-bd5c-c4163a6ca0f3",
|
||||
"from_task_id": "82192370-2fd7-5363-88d2-3c67889d3d68",
|
||||
"to_workplan_id": null,
|
||||
"to_task_id": "dd069c6d-fcc1-5bac-b233-976f2f0d5cd1"
|
||||
},
|
||||
{
|
||||
"workplan": "CUST-WP-0071",
|
||||
"from": "CUST-WP-0071-T04",
|
||||
"target": "CUST-WP-0071-T03",
|
||||
"relationship_type": "starts_after",
|
||||
"from_workplan_id": "2249bddb-7524-5add-bd5c-c4163a6ca0f3",
|
||||
"from_task_id": "944f98e2-7e42-5894-925b-752423f3a1cc",
|
||||
"to_workplan_id": null,
|
||||
"to_task_id": "6dc67558-eb1e-5bb6-a667-986f884dd495"
|
||||
},
|
||||
{
|
||||
"workplan": "CUST-WP-0073",
|
||||
"from": "CUST-WP-0073-T02",
|
||||
"target": "GLAS-WP-0012",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "a98a9f34-83b4-5c8c-8107-e05f7806d50d",
|
||||
"from_task_id": "4b88b0b7-dc7e-5612-aa5d-1a08f0530c35",
|
||||
"to_workplan_id": "170bf1ae-337f-5553-8d1e-03b07100e08f",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "CUST-WP-0073",
|
||||
"from": "CUST-WP-0073-T04",
|
||||
"target": "CUST-WP-0073-T02",
|
||||
"relationship_type": "starts_after",
|
||||
"from_workplan_id": "a98a9f34-83b4-5c8c-8107-e05f7806d50d",
|
||||
"from_task_id": "90725511-4e31-549f-b567-47feff1a9ca4",
|
||||
"to_workplan_id": null,
|
||||
"to_task_id": "4b88b0b7-dc7e-5612-aa5d-1a08f0530c35"
|
||||
},
|
||||
{
|
||||
"workplan": "CUST-WP-0079",
|
||||
"from": "CUST-WP-0079-T03",
|
||||
"target": "ACTIVITY-WP-0047",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "ab288f92-d364-5c24-9362-aee451f266c3",
|
||||
"from_task_id": "1be0569c-221d-5925-a0ff-fd2af88e52b1",
|
||||
"to_workplan_id": "ee97869b-dca2-54c9-aa18-0b479c244fb3",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "CUST-WP-0079",
|
||||
"from": "CUST-WP-0079-T04",
|
||||
"target": "PNEX-WP-0006",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "ab288f92-d364-5c24-9362-aee451f266c3",
|
||||
"from_task_id": "5dd52156-09a8-5781-b288-99ae822f59a6",
|
||||
"to_workplan_id": "774c5037-a3d0-5e65-893c-d18970acd66a",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "CUST-WP-0080",
|
||||
"from": "CUST-WP-0080-T04",
|
||||
"target": "CUST-WP-0080-T03",
|
||||
"relationship_type": "starts_after",
|
||||
"from_workplan_id": "dfadb19b-445e-59c6-bcd6-48e87b912c52",
|
||||
"from_task_id": "82378b0f-7004-5c2f-9683-b356a1227576",
|
||||
"to_workplan_id": null,
|
||||
"to_task_id": "87637402-02f1-57c1-8fbc-4141598af8e3"
|
||||
},
|
||||
{
|
||||
"workplan": "CUST-WP-0080",
|
||||
"from": "CUST-WP-0080-T05",
|
||||
"target": "RPF-WP-0056",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "dfadb19b-445e-59c6-bcd6-48e87b912c52",
|
||||
"from_task_id": "ed8b909a-23bf-5e5f-b600-e477fbae136b",
|
||||
"to_workplan_id": "31933d08-c877-5fda-aff9-6220c3705c92",
|
||||
"to_task_id": null
|
||||
},
|
||||
{
|
||||
"workplan": "CUST-WP-0080",
|
||||
"from": "CUST-WP-0080-T05",
|
||||
"target": "RAPP-PLAYWRIGHT-WP-0004",
|
||||
"relationship_type": "blocks",
|
||||
"from_workplan_id": "dfadb19b-445e-59c6-bcd6-48e87b912c52",
|
||||
"from_task_id": "ed8b909a-23bf-5e5f-b600-e477fbae136b",
|
||||
"to_workplan_id": "f9280c40-201e-59b5-a6f0-1aace8e0e2e2",
|
||||
"to_task_id": null
|
||||
}
|
||||
],
|
||||
"refused": [],
|
||||
"notes": [
|
||||
"Preserved bound historical row and task UUIDs: CUST-WP-ADHOC-2026-08-25-RETIRED"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
<!-- custodian-brief: generated by fix-consistency — do not edit manually -->
|
||||
# Custodian Brief — the-custodian
|
||||
|
||||
**Domain:** infotech
|
||||
**Last synced:** 2026-10-15 23:45 UTC
|
||||
**State Hub:** http://127.0.0.1:8000 *(adjust if running on a remote machine)*
|
||||
|
||||
## Active Workstreams
|
||||
|
||||
### NetKingdom target security architecture and SEC-DSM implementation
|
||||
Progress: 2/6 done | workplan_id: `dfadb19b-445e-59c6-bcd6-48e87b912c52`
|
||||
|
||||
**Open tasks:**
|
||||
- ► Close source defects and reconcile uncovered lifecycle gaps `87637402`
|
||||
- ► Coordinate self-service Playwright identity delivery `ed8b909a`
|
||||
- ► Establish the target architecture and drive the restructuring `6aca534c`
|
||||
- · Verify native closure against every requirement `82378b0f`
|
||||
|
||||
### Separate agent credentials and establish supervised privileged execution
|
||||
Progress: 2/5 done | workplan_id: `a98a9f34-83b4-5c8c-8107-e05f7806d50d`
|
||||
|
||||
**Open tasks:**
|
||||
- ! Build and hand out the agent identity `4b88b0b7`
|
||||
*(wait: Await GLAS-WP-0012 (glas-harness) production acceptance of the local supervised profile; then railiance-platform RBAC, railiance-enablement k3s config, railiance-infra principal mapping and ops-warden certificate issuance.)*
|
||||
- ! Fleet guidance and harness guards `90725511`
|
||||
*(wait: Await CUST-WP-0073-T02: the verified agent identity and execution path must exist before it can be documented; Codex/Grok read-denial guard needs glas-harness or harness-owner delivery.)*
|
||||
- ! Rotate what was exposed `1b41b532`
|
||||
*(wait: Deferred by founder decision 2026-09-24; reopened only by the founder on one of the three triggers below, in one attended rotation window.)*
|
||||
|
||||
### Size Railiance workloads from actual demand and establish a weekly allocation review
|
||||
Progress: 1/5 done | workplan_id: `2249bddb-7524-5add-bd5c-c4163a6ca0f3`
|
||||
|
||||
**Open tasks:**
|
||||
- ! Measure the Vergabe prototype under representative pilot use `82192370`
|
||||
*(wait: Await RAPPS-WP-0014-T03 (blocked, needs_human): populated two-user/document workflow run by Bernd and the company contact, giving representative load for p95 <= 2s / zero failures.)*
|
||||
- ! Review ecosystem allocations and reserve operating room `6dc67558`
|
||||
*(wait: Await CUST-WP-0071-T02 representative sample; Forgejo/runner demand and zero-request workload review need owner input (railiance-cluster, railiance-forge, resource-control).)*
|
||||
- ! Apply accepted sizing changes and verify their effects `944f98e2`
|
||||
*(wait: Await reviewed allocation proposals and applicable workload-owner authority.)*
|
||||
- ! Establish the regular weekly workload-demand and allocation assessment `20ddd4d7`
|
||||
*(wait: Await the repeatable observation and accepted sizing/review procedure.)*
|
||||
|
||||
### Deterministic security flow: standing authorizations, flow report, and agent re-engagement
|
||||
Progress: 3/7 done | workplan_id: `ab288f92-d364-5c24-9362-aee451f266c3`
|
||||
|
||||
**Open tasks:**
|
||||
- ! Schedule the flow report and decision sync `1be0569c`
|
||||
*(wait: Activity Core accepted the schedule in ACTIVITY-WP-0047. Await claiming rein workstation/hub acceptance, owner activation and the first unassisted fire with report/checkpoint evidence.)*
|
||||
- ! Encode the standing change rule as a policy-nexus guardrail `5dd52156`
|
||||
*(wait: policy-nexus owns guardrail publication; handoff written as PNEX-WP-0006.)*
|
||||
- ! Stop agent-authored index and sync commits `8a3dc219`
|
||||
*(wait: Local guard and repeatable shared-hook installation are implemented. Fleet generator adoption and the required full week of clean history remain unverified; repo-manager owner acceptance is needed.)*
|
||||
- ! Attended window #1 `e3da807f`
|
||||
*(wait: Partly done 2026-10-11: list cut from 14 to 3; U05-U07 accepted, U08 waits on KEY-WP-0040-T01. Remaining founder acts: USER-WP-0026-T03 readback, RPF-WP-0044-T08 coulombcore check, the U08 re-run, and Sol's added RPF-WP-0044-T04 issuer login.)*
|
||||
|
||||
---
|
||||
## MCP Orientation (when available)
|
||||
|
||||
If the state-hub MCP server is reachable, call:
|
||||
`get_domain_summary("infotech")`
|
||||
This provides richer cross-domain context.
|
||||
If the MCP call fails, use this file as your orientation source.
|
||||
|
|
@ -0,0 +1,536 @@
|
|||
# Work Records — the-custodian
|
||||
|
||||
> Generated by `statehub fix-consistency` (CUST-WP-0061-T04, work-record
|
||||
> stage 3). Do not edit by hand — edit the source file/block listed for
|
||||
> each record and re-run fix-consistency to refresh this index. Archived
|
||||
> workplans are omitted; closed decisions/intakes/engagements stay listed
|
||||
> so recently-resolved work is still visible. [auto]
|
||||
|
||||
| Kind | ID | Status | Lane | Source |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| workplan | CUST-WP-ADHOC-2026-05-02 | done | — | workplans/ADHOC-2026-05-02.md |
|
||||
| workplan | CUST-WP-ADHOC-2026-07-02 | finished | — | workplans/ADHOC-2026-07-02.md |
|
||||
| workplan | CUST-WP-ADHOC-2026-08-25-RETIRED | finished | — | workplans/ADHOC-2026-08-25-retired.md |
|
||||
| workplan | CUST-WP-ADHOC-2026-08-25 | finished | — | workplans/ADHOC-2026-08-25.md |
|
||||
| workplan | CUST-WP-ADHOC-2026-09-06 | finished | — | workplans/ADHOC-2026-09-06.md |
|
||||
| workplan | CUST-WP-0000 | finished | — | workplans/CUST-WP-0000-state-hub-v0.1-build-deploy.md |
|
||||
| workplan | CUST-WP-0000b | finished | — | workplans/CUST-WP-0000b-state-hub-v0.2-decisions-dependencies.md |
|
||||
| workplan | CUST-WP-0001 | done | — | workplans/CUST-WP-0001-custodian-agent-runtime.md |
|
||||
| workplan | CUST-WP-0002 | finished | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| workplan | CUST-WP-0004 | finished | — | workplans/CUST-WP-0004-ep-td-tracking.md |
|
||||
| workplan | CUST-WP-0005 | finished | — | workplans/CUST-WP-0005-dynamic-domains.md |
|
||||
| workplan | CUST-WP-0006 | done | — | workplans/CUST-WP-0006-gems-state-hub.md |
|
||||
| workplan | CUST-WP-0007 | finished | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| workplan | CUST-WP-0008 | done | — | workplans/CUST-WP-0008-consistency-engine.md |
|
||||
| workplan | CUST-WP-0009 | finished | — | workplans/CUST-WP-0009-human-interventions.md |
|
||||
| workplan | CUST-WP-0010 | finished | — | workplans/CUST-WP-0010-workstream-lifecycle-docs.md |
|
||||
| workplan | CUST-WP-0010b | finished | — | workplans/CUST-WP-0010b-domain-and-repo-goals.md |
|
||||
| workplan | CUST-WP-0013 | finished | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| workplan | CUST-WP-0015 | done | — | workplans/CUST-WP-0015-agent-inbox.md |
|
||||
| workplan | CUST-WP-0016 | done | — | workplans/CUST-WP-0016-kaizen-agentic-integration.md |
|
||||
| workplan | CUST-WP-0017 | done | — | workplans/CUST-WP-0017-scope-md-agent-and-coverage.md |
|
||||
| workplan | CUST-WP-0018 | done | — | workplans/CUST-WP-0018-api-hardening-code-quality.md |
|
||||
| workplan | CUST-WP-0019 | done | — | workplans/CUST-WP-0019-dashboard-ux-polish.md |
|
||||
| workplan | CUST-WP-0020 | done | — | workplans/CUST-WP-0020-test-suite.md |
|
||||
| workplan | CUST-WP-0021 | done | — | workplans/CUST-WP-0021-multi-host-repo-paths.md |
|
||||
| workplan | CUST-WP-0022 | done | — | workplans/CUST-WP-0022-capability-requests.md |
|
||||
| workplan | CUST-WP-0023 | done | — | workplans/CUST-WP-0023-tpsc.md |
|
||||
| workplan | CUST-WP-0024 | done | — | workplans/CUST-WP-0024-repo-doi-gate.md |
|
||||
| workplan | CUST-WP-0026 | done | — | workplans/CUST-WP-0026-distributed-consistency.md |
|
||||
| workplan | CUST-WP-0027 | done | — | workplans/CUST-WP-0027-capability-request-dispute.md |
|
||||
| workplan | CUST-WP-0029 | done | — | workplans/CUST-WP-0029-token-consumption-tracking.md |
|
||||
| workplan | CUST-WP-0030 | done | — | workplans/CUST-WP-0030-dashboard-entity-list-ux.md |
|
||||
| workplan | CUST-WP-0031 | done | — | workplans/CUST-WP-0031-capability-registry.md |
|
||||
| workplan | CUST-WP-0032 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| workplan | CUST-WP-0033 | done | — | workplans/CUST-WP-0033-interface-change-registry.md |
|
||||
| workplan | CUST-WP-0039 | done | — | workplans/CUST-WP-0039-dashboard-poll-optimization.md |
|
||||
| workplan | CUST-WP-0040 | finished | — | workplans/CUST-WP-0040-state-hub-nats-activity-core-integration.md |
|
||||
| workplan | CUST-WP-0041 | done | — | workplans/CUST-WP-0041-api-performance.md |
|
||||
| workplan | CUST-WP-0043 | finished | — | workplans/CUST-WP-0043-state-hub-repo-extraction.md |
|
||||
| workplan | CUST-WP-0044 | finished | — | workplans/CUST-WP-0044-daily-statehub-wsjf-triage.md |
|
||||
| workplan | CUST-WP-0045 | finished | — | workplans/CUST-WP-0045-activity-core-daily-triage-runner.md |
|
||||
| workplan | CUST-WP-0069 | finished | — | workplans/CUST-WP-0045-cutover-runbook.md |
|
||||
| workplan | CUST-WP-0046 | finished | — | workplans/CUST-WP-0046-hourly-recently-on-scope-activity-core.md |
|
||||
| workplan | CUST-WP-0047 | finished | — | workplans/CUST-WP-0047-ops-hub-service-inventory-now-view.md |
|
||||
| workplan | CUST-WP-0048 | finished | — | workplans/CUST-WP-0048-hub-core-state-hub-import-refactor.md |
|
||||
| workplan | CUST-WP-0049 | finished | — | workplans/CUST-WP-0049-interhub-bootstrap-access-lane.md |
|
||||
| workplan | CUST-WP-0050 | finished | — | workplans/CUST-WP-0050-repo-classification-registration-redesign.md |
|
||||
| workplan | CUST-WP-0051 | finished | — | workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md |
|
||||
| workplan | CUST-WP-0052 | finished | — | workplans/CUST-WP-0052-core-hub-fos-reset.md |
|
||||
| workplan | CUST-WP-0053 | finished | — | workplans/CUST-WP-0053-coordination-hygiene-improvements.md |
|
||||
| workplan | CUST-WP-0055 | finished | — | workplans/CUST-WP-0055-workplan-terminology-fleet-refactor.md |
|
||||
| workplan | CUST-WP-0056 | finished | — | workplans/CUST-WP-0056-daily-todo-md-stale-review.md |
|
||||
| workplan | CUST-WP-0059 | finished | — | workplans/CUST-WP-0059-forgejo-ci-publish-cutover-tail.md |
|
||||
| workplan | CUST-WP-0060 | finished | — | workplans/CUST-WP-0060-work-record-canonization.md |
|
||||
| workplan | CUST-WP-0061 | finished | — | workplans/CUST-WP-0061-work-record-stage3-intake-promotion-index.md |
|
||||
| workplan | CUST-WP-0062 | finished | — | workplans/CUST-WP-0062-sbom-nexus-daily-catchup.md |
|
||||
| workplan | CUST-WP-0063 | finished | — | workplans/CUST-WP-0063-inbox-governance-packets.md |
|
||||
| workplan | CUST-WP-0064 | finished | — | workplans/CUST-WP-0064-sbom-controlled-scan-inputs.md |
|
||||
| workplan | CUST-WP-0065 | finished | — | workplans/CUST-WP-0065-reclassify-repos-and-guidance-docs-to-the-new-sector-domain.md |
|
||||
| workplan | CUST-WP-0066 | finished | — | workplans/CUST-WP-0066-repository-qualified-ad-hoc-identifiers.md |
|
||||
| workplan | CUST-WP-0067 | finished | — | workplans/CUST-WP-0067-hub-authority-target-resolution.md |
|
||||
| workplan | CUST-WP-0068 | finished | — | workplans/CUST-WP-0068-cache-only-work-record-recovery.md |
|
||||
| workplan | CUST-WP-0070 | finished | — | workplans/CUST-WP-0070-publication-repo-category.md |
|
||||
| workplan | CUST-WP-0071 | blocked | — | workplans/CUST-WP-0071-measured-workload-sizing-and-weekly-review.md |
|
||||
| workplan | CUST-WP-0072 | finished | — | workplans/CUST-WP-0072-fleet-flavor-and-depends-on-backfill.md |
|
||||
| workplan | CUST-WP-0073 | blocked | — | workplans/CUST-WP-0073-agent-credential-separation.md |
|
||||
| workplan | CUST-WP-0074 | finished | — | workplans/CUST-WP-0074-qualified-wait-states.md |
|
||||
| workplan | CUST-WP-0075 | finished | — | workplans/CUST-WP-0075-dependency-graph-driven-unblocking.md |
|
||||
| workplan | CUST-WP-0076 | finished | — | workplans/CUST-WP-0076-provisioning-window-cadence.md |
|
||||
| workplan | CUST-WP-0077 | finished | — | workplans/CUST-WP-0077-dependency-root-execution-wave.md |
|
||||
| workplan | CUST-WP-0078 | finished | — | workplans/CUST-WP-0078-security-collaboration-consolidation.md |
|
||||
| workplan | CUST-WP-0079 | blocked | — | workplans/CUST-WP-0079-deterministic-security-flow.md |
|
||||
| workplan | CUST-WP-0080 | active | — | workplans/CUST-WP-0080-netkingdom-security-blueprint-and-gap-closure.md |
|
||||
| workplan | CUST-WP-0081 | finished | — | workplans/CUST-WP-0081-netkingdom-architecture-review-and-reuse.md |
|
||||
| workplan | THE-WP-0001 | finished | — | workplans/THE-WP-0001-federation-interface.md |
|
||||
| task | CUST-WP-ADHOC-2026-05-02-T01 | done | — | workplans/ADHOC-2026-05-02.md |
|
||||
| task | CUST-WP-ADHOC-2026-07-02-T01 | done | — | workplans/ADHOC-2026-07-02.md |
|
||||
| task | ADHOC-2026-08-25-T01 | done | — | workplans/ADHOC-2026-08-25-retired.md |
|
||||
| task | CUST-WP-ADHOC-2026-08-25-T01 | done | — | workplans/ADHOC-2026-08-25.md |
|
||||
| task | CUST-WP-ADHOC-2026-09-06-T01 | done | — | workplans/ADHOC-2026-09-06.md |
|
||||
| task | CUST-WP-0001-T01 | done | — | workplans/CUST-WP-0001-custodian-agent-runtime.md |
|
||||
| task | CUST-WP-0001-T02 | done | — | workplans/CUST-WP-0001-custodian-agent-runtime.md |
|
||||
| task | CUST-WP-0002-T01 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T02 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T03 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T04 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T05 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T06 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T07 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T08 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T09 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T10 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T11 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T12 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T13 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T14 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0002-T15 | done | — | workplans/CUST-WP-0002-contribution-tracking-sbom.md |
|
||||
| task | CUST-WP-0004-T01 | done | — | workplans/CUST-WP-0004-ep-td-tracking.md |
|
||||
| task | CUST-WP-0004-T02 | done | — | workplans/CUST-WP-0004-ep-td-tracking.md |
|
||||
| task | CUST-WP-0004-T03 | done | — | workplans/CUST-WP-0004-ep-td-tracking.md |
|
||||
| task | CUST-WP-0004-T04 | done | — | workplans/CUST-WP-0004-ep-td-tracking.md |
|
||||
| task | CUST-WP-0004-T05 | done | — | workplans/CUST-WP-0004-ep-td-tracking.md |
|
||||
| task | CUST-WP-0004-T06 | done | — | workplans/CUST-WP-0004-ep-td-tracking.md |
|
||||
| task | CUST-WP-0004-T07 | done | — | workplans/CUST-WP-0004-ep-td-tracking.md |
|
||||
| task | CUST-WP-0004-T08 | done | — | workplans/CUST-WP-0004-ep-td-tracking.md |
|
||||
| task | CUST-WP-0004-T09 | done | — | workplans/CUST-WP-0004-ep-td-tracking.md |
|
||||
| task | CUST-WP-0004-T10 | done | — | workplans/CUST-WP-0004-ep-td-tracking.md |
|
||||
| task | CUST-WP-0005-T01 | done | — | workplans/CUST-WP-0005-dynamic-domains.md |
|
||||
| task | CUST-WP-0005-T02 | done | — | workplans/CUST-WP-0005-dynamic-domains.md |
|
||||
| task | CUST-WP-0005-T03 | done | — | workplans/CUST-WP-0005-dynamic-domains.md |
|
||||
| task | CUST-WP-0005-T04 | done | — | workplans/CUST-WP-0005-dynamic-domains.md |
|
||||
| task | CUST-WP-0005-T05 | done | — | workplans/CUST-WP-0005-dynamic-domains.md |
|
||||
| task | CUST-WP-0005-T06 | done | — | workplans/CUST-WP-0005-dynamic-domains.md |
|
||||
| task | CUST-WP-0005-T07 | done | — | workplans/CUST-WP-0005-dynamic-domains.md |
|
||||
| task | CUST-WP-0005-T08 | done | — | workplans/CUST-WP-0005-dynamic-domains.md |
|
||||
| task | CUST-WP-0005-T09 | done | — | workplans/CUST-WP-0005-dynamic-domains.md |
|
||||
| task | CUST-WP-0005-T10 | done | — | workplans/CUST-WP-0005-dynamic-domains.md |
|
||||
| task | CUST-WP-0005-T11 | done | — | workplans/CUST-WP-0005-dynamic-domains.md |
|
||||
| task | T01 | done | — | workplans/CUST-WP-0006-gems-state-hub.md |
|
||||
| task | T02 | done | — | workplans/CUST-WP-0006-gems-state-hub.md |
|
||||
| task | T03 | done | — | workplans/CUST-WP-0006-gems-state-hub.md |
|
||||
| task | T04 | done | — | workplans/CUST-WP-0006-gems-state-hub.md |
|
||||
| task | T05 | done | — | workplans/CUST-WP-0006-gems-state-hub.md |
|
||||
| task | T01 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T02 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T03 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T04 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T05 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T06 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T07 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T08 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T09 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T10 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T11 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T12 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T13 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T14 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T15 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T16 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | T17 | done | — | workplans/CUST-WP-0007-gems-migration.md |
|
||||
| task | CUST-WP-0008-T01 | done | — | workplans/CUST-WP-0008-consistency-engine.md |
|
||||
| task | CUST-WP-0008-T02 | done | — | workplans/CUST-WP-0008-consistency-engine.md |
|
||||
| task | CUST-WP-0008-T03 | done | — | workplans/CUST-WP-0008-consistency-engine.md |
|
||||
| task | CUST-WP-0008-T04 | done | — | workplans/CUST-WP-0008-consistency-engine.md |
|
||||
| task | CUST-WP-0009-T1 | done | — | workplans/CUST-WP-0009-human-interventions.md |
|
||||
| task | CUST-WP-0009-T2 | done | — | workplans/CUST-WP-0009-human-interventions.md |
|
||||
| task | CUST-WP-0009-T3 | done | — | workplans/CUST-WP-0009-human-interventions.md |
|
||||
| task | CUST-WP-0010-T1 | done | — | workplans/CUST-WP-0010-workstream-lifecycle-docs.md |
|
||||
| task | CUST-WP-0010-T2 | done | — | workplans/CUST-WP-0010-workstream-lifecycle-docs.md |
|
||||
| task | CUST-WP-0010-T3 | done | — | workplans/CUST-WP-0010-workstream-lifecycle-docs.md |
|
||||
| task | CUST-WP-0010b-T01 | done | — | workplans/CUST-WP-0010b-domain-and-repo-goals.md |
|
||||
| task | CUST-WP-0010b-T02 | done | — | workplans/CUST-WP-0010b-domain-and-repo-goals.md |
|
||||
| task | CUST-WP-0013-T01 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0013-T02 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0013-T03 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0013-T04 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0013-T05 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0013-T06 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0013-T07 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0013-T08 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0013-T09 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0013-T10 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0013-T11 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0013-T12 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0013-T13 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0013-T14 | done | — | workplans/CUST-WP-0013-sbom-infra-expansion.md |
|
||||
| task | CUST-WP-0015-T01 | done | — | workplans/CUST-WP-0015-agent-inbox.md |
|
||||
| task | CUST-WP-0015-T02 | done | — | workplans/CUST-WP-0015-agent-inbox.md |
|
||||
| task | CUST-WP-0015-T03 | done | — | workplans/CUST-WP-0015-agent-inbox.md |
|
||||
| task | CUST-WP-0015-T04 | done | — | workplans/CUST-WP-0015-agent-inbox.md |
|
||||
| task | CUST-WP-0015-T05 | done | — | workplans/CUST-WP-0015-agent-inbox.md |
|
||||
| task | CUST-WP-0016-T01 | done | — | workplans/CUST-WP-0016-kaizen-agentic-integration.md |
|
||||
| task | CUST-WP-0016-T02 | done | — | workplans/CUST-WP-0016-kaizen-agentic-integration.md |
|
||||
| task | CUST-WP-0016-T03 | done | — | workplans/CUST-WP-0016-kaizen-agentic-integration.md |
|
||||
| task | CUST-WP-0016-T04 | done | — | workplans/CUST-WP-0016-kaizen-agentic-integration.md |
|
||||
| task | CUST-WP-0016-T05 | done | — | workplans/CUST-WP-0016-kaizen-agentic-integration.md |
|
||||
| task | CUST-WP-0017-T01 | done | — | workplans/CUST-WP-0017-scope-md-agent-and-coverage.md |
|
||||
| task | CUST-WP-0017-T02 | done | — | workplans/CUST-WP-0017-scope-md-agent-and-coverage.md |
|
||||
| task | CUST-WP-0017-T03 | done | — | workplans/CUST-WP-0017-scope-md-agent-and-coverage.md |
|
||||
| task | CUST-WP-0017-T04 | done | — | workplans/CUST-WP-0017-scope-md-agent-and-coverage.md |
|
||||
| task | CUST-WP-0017-T05 | done | — | workplans/CUST-WP-0017-scope-md-agent-and-coverage.md |
|
||||
| task | CUST-WP-0017-T06 | done | — | workplans/CUST-WP-0017-scope-md-agent-and-coverage.md |
|
||||
| task | CUST-WP-0018-T01 | done | — | workplans/CUST-WP-0018-api-hardening-code-quality.md |
|
||||
| task | CUST-WP-0018-T02 | done | — | workplans/CUST-WP-0018-api-hardening-code-quality.md |
|
||||
| task | CUST-WP-0018-T03 | done | — | workplans/CUST-WP-0018-api-hardening-code-quality.md |
|
||||
| task | CUST-WP-0018-T04 | done | — | workplans/CUST-WP-0018-api-hardening-code-quality.md |
|
||||
| task | CUST-WP-0018-T05 | done | — | workplans/CUST-WP-0018-api-hardening-code-quality.md |
|
||||
| task | CUST-WP-0018-T06 | done | — | workplans/CUST-WP-0018-api-hardening-code-quality.md |
|
||||
| task | CUST-WP-0018-T07 | done | — | workplans/CUST-WP-0018-api-hardening-code-quality.md |
|
||||
| task | CUST-WP-0019-T01 | done | — | workplans/CUST-WP-0019-dashboard-ux-polish.md |
|
||||
| task | CUST-WP-0019-T02 | done | — | workplans/CUST-WP-0019-dashboard-ux-polish.md |
|
||||
| task | CUST-WP-0019-T03 | done | — | workplans/CUST-WP-0019-dashboard-ux-polish.md |
|
||||
| task | CUST-WP-0020-T01 | done | — | workplans/CUST-WP-0020-test-suite.md |
|
||||
| task | CUST-WP-0020-T02 | done | — | workplans/CUST-WP-0020-test-suite.md |
|
||||
| task | CUST-WP-0020-T03 | done | — | workplans/CUST-WP-0020-test-suite.md |
|
||||
| task | CUST-WP-0020-T04 | done | — | workplans/CUST-WP-0020-test-suite.md |
|
||||
| task | CUST-WP-0020-T05 | done | — | workplans/CUST-WP-0020-test-suite.md |
|
||||
| task | CUST-WP-0021-T01 | done | — | workplans/CUST-WP-0021-multi-host-repo-paths.md |
|
||||
| task | CUST-WP-0021-T02 | done | — | workplans/CUST-WP-0021-multi-host-repo-paths.md |
|
||||
| task | CUST-WP-0021-T03 | done | — | workplans/CUST-WP-0021-multi-host-repo-paths.md |
|
||||
| task | CUST-WP-0021-T04 | done | — | workplans/CUST-WP-0021-multi-host-repo-paths.md |
|
||||
| task | CUST-WP-0021-T05 | done | — | workplans/CUST-WP-0021-multi-host-repo-paths.md |
|
||||
| task | CUST-WP-0022-T01 | done | — | workplans/CUST-WP-0022-capability-requests.md |
|
||||
| task | CUST-WP-0022-T02 | done | — | workplans/CUST-WP-0022-capability-requests.md |
|
||||
| task | CUST-WP-0022-T03 | done | — | workplans/CUST-WP-0022-capability-requests.md |
|
||||
| task | CUST-WP-0022-T04 | done | — | workplans/CUST-WP-0022-capability-requests.md |
|
||||
| task | CUST-WP-0022-T05 | done | — | workplans/CUST-WP-0022-capability-requests.md |
|
||||
| task | CUST-WP-0022-T06 | done | — | workplans/CUST-WP-0022-capability-requests.md |
|
||||
| task | CUST-WP-0022-T07 | done | — | workplans/CUST-WP-0022-capability-requests.md |
|
||||
| task | CUST-WP-0022-T08 | done | — | workplans/CUST-WP-0022-capability-requests.md |
|
||||
| task | CUST-WP-0022-T09 | done | — | workplans/CUST-WP-0022-capability-requests.md |
|
||||
| task | CUST-WP-0022-T10 | done | — | workplans/CUST-WP-0022-capability-requests.md |
|
||||
| task | CUST-WP-0023-T01 | done | — | workplans/CUST-WP-0023-tpsc.md |
|
||||
| task | CUST-WP-0023-T02 | done | — | workplans/CUST-WP-0023-tpsc.md |
|
||||
| task | CUST-WP-0023-T03 | done | — | workplans/CUST-WP-0023-tpsc.md |
|
||||
| task | CUST-WP-0023-T04 | done | — | workplans/CUST-WP-0023-tpsc.md |
|
||||
| task | CUST-WP-0023-T05 | done | — | workplans/CUST-WP-0023-tpsc.md |
|
||||
| task | CUST-WP-0023-T06 | done | — | workplans/CUST-WP-0023-tpsc.md |
|
||||
| task | CUST-WP-0023-T07 | done | — | workplans/CUST-WP-0023-tpsc.md |
|
||||
| task | CUST-WP-0023-T08 | done | — | workplans/CUST-WP-0023-tpsc.md |
|
||||
| task | CUST-WP-0023-T09 | done | — | workplans/CUST-WP-0023-tpsc.md |
|
||||
| task | CUST-WP-0023-T10 | done | — | workplans/CUST-WP-0023-tpsc.md |
|
||||
| task | CUST-WP-0024-T01 | done | — | workplans/CUST-WP-0024-repo-doi-gate.md |
|
||||
| task | CUST-WP-0024-T02 | done | — | workplans/CUST-WP-0024-repo-doi-gate.md |
|
||||
| task | CUST-WP-0024-T03 | done | — | workplans/CUST-WP-0024-repo-doi-gate.md |
|
||||
| task | CUST-WP-0024-T04 | done | — | workplans/CUST-WP-0024-repo-doi-gate.md |
|
||||
| task | CUST-WP-0024-T05 | done | — | workplans/CUST-WP-0024-repo-doi-gate.md |
|
||||
| task | CUST-WP-0026-T01 | done | — | workplans/CUST-WP-0026-distributed-consistency.md |
|
||||
| task | CUST-WP-0026-T02 | done | — | workplans/CUST-WP-0026-distributed-consistency.md |
|
||||
| task | CUST-WP-0026-T03 | done | — | workplans/CUST-WP-0026-distributed-consistency.md |
|
||||
| task | CUST-WP-0026-T04 | done | — | workplans/CUST-WP-0026-distributed-consistency.md |
|
||||
| task | CUST-WP-0026-T05 | done | — | workplans/CUST-WP-0026-distributed-consistency.md |
|
||||
| task | CUST-WP-0027-T01 | done | — | workplans/CUST-WP-0027-capability-request-dispute.md |
|
||||
| task | CUST-WP-0027-T02 | done | — | workplans/CUST-WP-0027-capability-request-dispute.md |
|
||||
| task | CUST-WP-0027-T03 | done | — | workplans/CUST-WP-0027-capability-request-dispute.md |
|
||||
| task | CUST-WP-0027-T04 | done | — | workplans/CUST-WP-0027-capability-request-dispute.md |
|
||||
| task | CUST-WP-0027-T05 | done | — | workplans/CUST-WP-0027-capability-request-dispute.md |
|
||||
| task | CUST-WP-0029-T01 | done | — | workplans/CUST-WP-0029-token-consumption-tracking.md |
|
||||
| task | CUST-WP-0029-T02 | done | — | workplans/CUST-WP-0029-token-consumption-tracking.md |
|
||||
| task | CUST-WP-0029-T03 | done | — | workplans/CUST-WP-0029-token-consumption-tracking.md |
|
||||
| task | CUST-WP-0029-T04 | done | — | workplans/CUST-WP-0029-token-consumption-tracking.md |
|
||||
| task | CUST-WP-0029-T05 | done | — | workplans/CUST-WP-0029-token-consumption-tracking.md |
|
||||
| task | CUST-WP-0029-T06 | done | — | workplans/CUST-WP-0029-token-consumption-tracking.md |
|
||||
| task | CUST-WP-0029-T07 | done | — | workplans/CUST-WP-0029-token-consumption-tracking.md |
|
||||
| task | CUST-WP-0029-T08 | done | — | workplans/CUST-WP-0029-token-consumption-tracking.md |
|
||||
| task | T01 | done | — | workplans/CUST-WP-0030-dashboard-entity-list-ux.md |
|
||||
| task | T02 | done | — | workplans/CUST-WP-0030-dashboard-entity-list-ux.md |
|
||||
| task | T03 | done | — | workplans/CUST-WP-0030-dashboard-entity-list-ux.md |
|
||||
| task | T04 | done | — | workplans/CUST-WP-0030-dashboard-entity-list-ux.md |
|
||||
| task | T05 | done | — | workplans/CUST-WP-0030-dashboard-entity-list-ux.md |
|
||||
| task | T06 | done | — | workplans/CUST-WP-0030-dashboard-entity-list-ux.md |
|
||||
| task | T07 | done | — | workplans/CUST-WP-0030-dashboard-entity-list-ux.md |
|
||||
| task | T08 | done | — | workplans/CUST-WP-0030-dashboard-entity-list-ux.md |
|
||||
| task | T09 | done | — | workplans/CUST-WP-0030-dashboard-entity-list-ux.md |
|
||||
| task | T01 | done | — | workplans/CUST-WP-0031-capability-registry.md |
|
||||
| task | T02 | done | — | workplans/CUST-WP-0031-capability-registry.md |
|
||||
| task | T03 | done | — | workplans/CUST-WP-0031-capability-registry.md |
|
||||
| task | T04 | done | — | workplans/CUST-WP-0031-capability-registry.md |
|
||||
| task | T05 | done | — | workplans/CUST-WP-0031-capability-registry.md |
|
||||
| task | T06 | done | — | workplans/CUST-WP-0031-capability-registry.md |
|
||||
| task | T07 | done | — | workplans/CUST-WP-0031-capability-registry.md |
|
||||
| task | CUST-WP-0032-T01 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T02 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T03 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T04 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T05 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T06 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T07 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T08 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T09 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T10 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T11 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T12 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T13 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T14 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0032-T15 | done | — | workplans/CUST-WP-0032-haskell-build-machine.md |
|
||||
| task | CUST-WP-0033-T01 | done | — | workplans/CUST-WP-0033-interface-change-registry.md |
|
||||
| task | CUST-WP-0033-T02 | done | — | workplans/CUST-WP-0033-interface-change-registry.md |
|
||||
| task | CUST-WP-0033-T03 | done | — | workplans/CUST-WP-0033-interface-change-registry.md |
|
||||
| task | CUST-WP-0033-T04 | done | — | workplans/CUST-WP-0033-interface-change-registry.md |
|
||||
| task | CUST-WP-0033-T05 | done | — | workplans/CUST-WP-0033-interface-change-registry.md |
|
||||
| task | CUST-WP-0033-T06 | done | — | workplans/CUST-WP-0033-interface-change-registry.md |
|
||||
| task | CUST-WP-0039-T1 | done | — | workplans/CUST-WP-0039-dashboard-poll-optimization.md |
|
||||
| task | CUST-WP-0039-T2 | done | — | workplans/CUST-WP-0039-dashboard-poll-optimization.md |
|
||||
| task | CUST-WP-0039-T3 | done | — | workplans/CUST-WP-0039-dashboard-poll-optimization.md |
|
||||
| task | CUST-WP-0039-T4 | done | — | workplans/CUST-WP-0039-dashboard-poll-optimization.md |
|
||||
| task | CUST-WP-0039-T5 | done | — | workplans/CUST-WP-0039-dashboard-poll-optimization.md |
|
||||
| task | CUST-WP-0039-T6 | done | — | workplans/CUST-WP-0039-dashboard-poll-optimization.md |
|
||||
| task | T01 | done | — | workplans/CUST-WP-0040-state-hub-nats-activity-core-integration.md |
|
||||
| task | T02 | done | — | workplans/CUST-WP-0040-state-hub-nats-activity-core-integration.md |
|
||||
| task | T03 | done | — | workplans/CUST-WP-0040-state-hub-nats-activity-core-integration.md |
|
||||
| task | T04 | done | — | workplans/CUST-WP-0040-state-hub-nats-activity-core-integration.md |
|
||||
| task | T05 | done | — | workplans/CUST-WP-0040-state-hub-nats-activity-core-integration.md |
|
||||
| task | T06 | done | — | workplans/CUST-WP-0040-state-hub-nats-activity-core-integration.md |
|
||||
| task | CUST-WP-0041-T1 | done | — | workplans/CUST-WP-0041-api-performance.md |
|
||||
| task | CUST-WP-0041-T2 | done | — | workplans/CUST-WP-0041-api-performance.md |
|
||||
| task | CUST-WP-0041-T3 | done | — | workplans/CUST-WP-0041-api-performance.md |
|
||||
| task | CUST-WP-0041-T4 | done | — | workplans/CUST-WP-0041-api-performance.md |
|
||||
| task | CUST-WP-0043-T01 | done | — | workplans/CUST-WP-0043-state-hub-repo-extraction.md |
|
||||
| task | CUST-WP-0043-T02 | done | — | workplans/CUST-WP-0043-state-hub-repo-extraction.md |
|
||||
| task | CUST-WP-0043-T03 | done | — | workplans/CUST-WP-0043-state-hub-repo-extraction.md |
|
||||
| task | CUST-WP-0043-T04 | done | — | workplans/CUST-WP-0043-state-hub-repo-extraction.md |
|
||||
| task | CUST-WP-0043-T05 | done | — | workplans/CUST-WP-0043-state-hub-repo-extraction.md |
|
||||
| task | CUST-WP-0043-T06 | done | — | workplans/CUST-WP-0043-state-hub-repo-extraction.md |
|
||||
| task | CUST-WP-0043-T07 | done | — | workplans/CUST-WP-0043-state-hub-repo-extraction.md |
|
||||
| task | CUST-WP-0043-T08 | done | — | workplans/CUST-WP-0043-state-hub-repo-extraction.md |
|
||||
| task | CUST-WP-0043-T09 | done | — | workplans/CUST-WP-0043-state-hub-repo-extraction.md |
|
||||
| task | CUST-WP-0044-T01 | done | — | workplans/CUST-WP-0044-daily-statehub-wsjf-triage.md |
|
||||
| task | CUST-WP-0044-T02 | done | — | workplans/CUST-WP-0044-daily-statehub-wsjf-triage.md |
|
||||
| task | CUST-WP-0044-T03 | done | — | workplans/CUST-WP-0044-daily-statehub-wsjf-triage.md |
|
||||
| task | CUST-WP-0044-T04 | done | — | workplans/CUST-WP-0044-daily-statehub-wsjf-triage.md |
|
||||
| task | CUST-WP-0044-T05 | done | — | workplans/CUST-WP-0044-daily-statehub-wsjf-triage.md |
|
||||
| task | CUST-WP-0044-T06 | done | — | workplans/CUST-WP-0044-daily-statehub-wsjf-triage.md |
|
||||
| task | CUST-WP-0045-T01 | done | — | workplans/CUST-WP-0045-activity-core-daily-triage-runner.md |
|
||||
| task | CUST-WP-0045-T02 | done | — | workplans/CUST-WP-0045-activity-core-daily-triage-runner.md |
|
||||
| task | CUST-WP-0045-T03 | done | — | workplans/CUST-WP-0045-activity-core-daily-triage-runner.md |
|
||||
| task | CUST-WP-0045-T04 | done | — | workplans/CUST-WP-0045-activity-core-daily-triage-runner.md |
|
||||
| task | CUST-WP-0045-T05 | done | — | workplans/CUST-WP-0045-activity-core-daily-triage-runner.md |
|
||||
| task | CUST-WP-0045-T06 | done | — | workplans/CUST-WP-0045-activity-core-daily-triage-runner.md |
|
||||
| task | CUST-WP-0045-T07 | done | — | workplans/CUST-WP-0045-activity-core-daily-triage-runner.md |
|
||||
| task | CUST-WP-0045-T08 | done | — | workplans/CUST-WP-0045-activity-core-daily-triage-runner.md |
|
||||
| task | CUST-WP-0046-T01 | done | — | workplans/CUST-WP-0046-hourly-recently-on-scope-activity-core.md |
|
||||
| task | CUST-WP-0046-T02 | done | — | workplans/CUST-WP-0046-hourly-recently-on-scope-activity-core.md |
|
||||
| task | CUST-WP-0046-T03 | done | — | workplans/CUST-WP-0046-hourly-recently-on-scope-activity-core.md |
|
||||
| task | CUST-WP-0046-T04 | done | — | workplans/CUST-WP-0046-hourly-recently-on-scope-activity-core.md |
|
||||
| task | CUST-WP-0046-T05 | done | — | workplans/CUST-WP-0046-hourly-recently-on-scope-activity-core.md |
|
||||
| task | CUST-WP-0046-T06 | done | — | workplans/CUST-WP-0046-hourly-recently-on-scope-activity-core.md |
|
||||
| task | CUST-WP-0046-T07 | done | — | workplans/CUST-WP-0046-hourly-recently-on-scope-activity-core.md |
|
||||
| task | CUST-WP-0047-T01 | done | — | workplans/CUST-WP-0047-ops-hub-service-inventory-now-view.md |
|
||||
| task | CUST-WP-0047-T02 | done | — | workplans/CUST-WP-0047-ops-hub-service-inventory-now-view.md |
|
||||
| task | CUST-WP-0047-T03 | done | — | workplans/CUST-WP-0047-ops-hub-service-inventory-now-view.md |
|
||||
| task | CUST-WP-0047-T04 | done | — | workplans/CUST-WP-0047-ops-hub-service-inventory-now-view.md |
|
||||
| task | CUST-WP-0047-T05 | cancel | — | workplans/CUST-WP-0047-ops-hub-service-inventory-now-view.md |
|
||||
| task | CUST-WP-0047-T06 | done | — | workplans/CUST-WP-0047-ops-hub-service-inventory-now-view.md |
|
||||
| task | CUST-WP-0047-T07 | done | — | workplans/CUST-WP-0047-ops-hub-service-inventory-now-view.md |
|
||||
| task | CUST-WP-0048-T01 | done | — | workplans/CUST-WP-0048-hub-core-state-hub-import-refactor.md |
|
||||
| task | CUST-WP-0048-T02 | done | — | workplans/CUST-WP-0048-hub-core-state-hub-import-refactor.md |
|
||||
| task | CUST-WP-0048-T03 | done | — | workplans/CUST-WP-0048-hub-core-state-hub-import-refactor.md |
|
||||
| task | CUST-WP-0048-T04 | done | — | workplans/CUST-WP-0048-hub-core-state-hub-import-refactor.md |
|
||||
| task | CUST-WP-0048-T05 | done | — | workplans/CUST-WP-0048-hub-core-state-hub-import-refactor.md |
|
||||
| task | CUST-WP-0048-T06 | done | — | workplans/CUST-WP-0048-hub-core-state-hub-import-refactor.md |
|
||||
| task | CUST-WP-0048-T07 | done | — | workplans/CUST-WP-0048-hub-core-state-hub-import-refactor.md |
|
||||
| task | CUST-WP-0048-T08 | done | — | workplans/CUST-WP-0048-hub-core-state-hub-import-refactor.md |
|
||||
| task | CUST-WP-0049-T01 | done | — | workplans/CUST-WP-0049-interhub-bootstrap-access-lane.md |
|
||||
| task | CUST-WP-0049-T02 | done | — | workplans/CUST-WP-0049-interhub-bootstrap-access-lane.md |
|
||||
| task | CUST-WP-0049-T03 | done | — | workplans/CUST-WP-0049-interhub-bootstrap-access-lane.md |
|
||||
| task | CUST-WP-0049-T04 | done | — | workplans/CUST-WP-0049-interhub-bootstrap-access-lane.md |
|
||||
| task | CUST-WP-0049-T05 | done | — | workplans/CUST-WP-0049-interhub-bootstrap-access-lane.md |
|
||||
| task | CUST-WP-0049-T06 | cancel | — | workplans/CUST-WP-0049-interhub-bootstrap-access-lane.md |
|
||||
| task | CUST-WP-0050-T01 | done | — | workplans/CUST-WP-0050-repo-classification-registration-redesign.md |
|
||||
| task | CUST-WP-0050-T02 | done | — | workplans/CUST-WP-0050-repo-classification-registration-redesign.md |
|
||||
| task | CUST-WP-0050-T03 | cancel | — | workplans/CUST-WP-0050-repo-classification-registration-redesign.md |
|
||||
| task | CUST-WP-0050-T04 | cancel | — | workplans/CUST-WP-0050-repo-classification-registration-redesign.md |
|
||||
| task | CUST-WP-0050-T05 | cancel | — | workplans/CUST-WP-0050-repo-classification-registration-redesign.md |
|
||||
| task | CUST-WP-0050-T06 | cancel | — | workplans/CUST-WP-0050-repo-classification-registration-redesign.md |
|
||||
| task | CUST-WP-0050-T07 | cancel | — | workplans/CUST-WP-0050-repo-classification-registration-redesign.md |
|
||||
| task | CUST-WP-0050-T08 | cancel | — | workplans/CUST-WP-0050-repo-classification-registration-redesign.md |
|
||||
| task | CUST-WP-0050-T09 | cancel | — | workplans/CUST-WP-0050-repo-classification-registration-redesign.md |
|
||||
| task | CUST-WP-0050-T10 | cancel | — | workplans/CUST-WP-0050-repo-classification-registration-redesign.md |
|
||||
| task | CUST-WP-0050-T11 | done | — | workplans/CUST-WP-0050-repo-classification-registration-redesign.md |
|
||||
| task | CUST-WP-0051-T01 | done | — | workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md |
|
||||
| task | CUST-WP-0051-T02 | done | — | workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md |
|
||||
| task | CUST-WP-0051-T03 | done | — | workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md |
|
||||
| task | CUST-WP-0051-T04 | done | — | workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md |
|
||||
| task | CUST-WP-0051-T05 | done | — | workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md |
|
||||
| task | CUST-WP-0051-T06 | done | — | workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md |
|
||||
| task | CUST-WP-0051-T07 | done | — | workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md |
|
||||
| task | CUST-WP-0051-T08 | done | — | workplans/CUST-WP-0051-infrastructure-stabilization-metaplan.md |
|
||||
| task | CUST-WP-0052-T01 | done | — | workplans/CUST-WP-0052-core-hub-fos-reset.md |
|
||||
| task | CUST-WP-0052-T02 | done | — | workplans/CUST-WP-0052-core-hub-fos-reset.md |
|
||||
| task | CUST-WP-0052-T03 | done | — | workplans/CUST-WP-0052-core-hub-fos-reset.md |
|
||||
| task | CUST-WP-0052-T04 | done | — | workplans/CUST-WP-0052-core-hub-fos-reset.md |
|
||||
| task | CUST-WP-0052-T05 | done | — | workplans/CUST-WP-0052-core-hub-fos-reset.md |
|
||||
| task | CUST-WP-0052-T06 | done | — | workplans/CUST-WP-0052-core-hub-fos-reset.md |
|
||||
| task | CUST-WP-0052-T07 | done | — | workplans/CUST-WP-0052-core-hub-fos-reset.md |
|
||||
| task | CUST-WP-0053-T01 | done | — | workplans/CUST-WP-0053-coordination-hygiene-improvements.md |
|
||||
| task | CUST-WP-0053-T02 | done | — | workplans/CUST-WP-0053-coordination-hygiene-improvements.md |
|
||||
| task | CUST-WP-0053-T03 | done | — | workplans/CUST-WP-0053-coordination-hygiene-improvements.md |
|
||||
| task | CUST-WP-0053-T04 | done | — | workplans/CUST-WP-0053-coordination-hygiene-improvements.md |
|
||||
| task | CUST-WP-0053-T05 | done | — | workplans/CUST-WP-0053-coordination-hygiene-improvements.md |
|
||||
| task | CUST-WP-0055-T01 | done | — | workplans/CUST-WP-0055-workplan-terminology-fleet-refactor.md |
|
||||
| task | CUST-WP-0055-T02 | done | — | workplans/CUST-WP-0055-workplan-terminology-fleet-refactor.md |
|
||||
| task | CUST-WP-0055-T03 | done | — | workplans/CUST-WP-0055-workplan-terminology-fleet-refactor.md |
|
||||
| task | CUST-WP-0055-T04 | done | — | workplans/CUST-WP-0055-workplan-terminology-fleet-refactor.md |
|
||||
| task | CUST-WP-0055-T05 | done | — | workplans/CUST-WP-0055-workplan-terminology-fleet-refactor.md |
|
||||
| task | CUST-WP-0055-T06 | done | — | workplans/CUST-WP-0055-workplan-terminology-fleet-refactor.md |
|
||||
| task | CUST-WP-0055-T07 | done | — | workplans/CUST-WP-0055-workplan-terminology-fleet-refactor.md |
|
||||
| task | CUST-WP-0055-T08 | done | — | workplans/CUST-WP-0055-workplan-terminology-fleet-refactor.md |
|
||||
| task | CUST-WP-0056-T01 | done | — | workplans/CUST-WP-0056-daily-todo-md-stale-review.md |
|
||||
| task | CUST-WP-0056-T02 | done | — | workplans/CUST-WP-0056-daily-todo-md-stale-review.md |
|
||||
| task | CUST-WP-0056-T03 | done | — | workplans/CUST-WP-0056-daily-todo-md-stale-review.md |
|
||||
| task | CUST-WP-0059-T01 | done | — | workplans/CUST-WP-0059-forgejo-ci-publish-cutover-tail.md |
|
||||
| task | CUST-WP-0059-T02 | done | — | workplans/CUST-WP-0059-forgejo-ci-publish-cutover-tail.md |
|
||||
| task | CUST-WP-0059-T03 | done | — | workplans/CUST-WP-0059-forgejo-ci-publish-cutover-tail.md |
|
||||
| task | CUST-WP-0059-T04 | done | — | workplans/CUST-WP-0059-forgejo-ci-publish-cutover-tail.md |
|
||||
| task | CUST-WP-0059-T05 | done | — | workplans/CUST-WP-0059-forgejo-ci-publish-cutover-tail.md |
|
||||
| task | CUST-WP-0059-T06 | done | — | workplans/CUST-WP-0059-forgejo-ci-publish-cutover-tail.md |
|
||||
| task | CUST-WP-0060-T01 | done | — | workplans/CUST-WP-0060-work-record-canonization.md |
|
||||
| task | CUST-WP-0060-T02 | done | — | workplans/CUST-WP-0060-work-record-canonization.md |
|
||||
| task | CUST-WP-0060-T03 | done | — | workplans/CUST-WP-0060-work-record-canonization.md |
|
||||
| task | CUST-WP-0060-T04 | done | — | workplans/CUST-WP-0060-work-record-canonization.md |
|
||||
| task | CUST-WP-0060-T05 | done | — | workplans/CUST-WP-0060-work-record-canonization.md |
|
||||
| task | CUST-WP-0060-T06 | done | — | workplans/CUST-WP-0060-work-record-canonization.md |
|
||||
| task | CUST-WP-0060-T07 | done | — | workplans/CUST-WP-0060-work-record-canonization.md |
|
||||
| task | CUST-WP-0061-T01 | done | — | workplans/CUST-WP-0061-work-record-stage3-intake-promotion-index.md |
|
||||
| task | CUST-WP-0061-T02 | done | — | workplans/CUST-WP-0061-work-record-stage3-intake-promotion-index.md |
|
||||
| task | CUST-WP-0061-T03 | done | — | workplans/CUST-WP-0061-work-record-stage3-intake-promotion-index.md |
|
||||
| task | CUST-WP-0061-T04 | done | — | workplans/CUST-WP-0061-work-record-stage3-intake-promotion-index.md |
|
||||
| task | CUST-WP-0061-T05 | done | — | workplans/CUST-WP-0061-work-record-stage3-intake-promotion-index.md |
|
||||
| task | CUST-WP-0061-T06 | done | — | workplans/CUST-WP-0061-work-record-stage3-intake-promotion-index.md |
|
||||
| task | CUST-WP-0062-T01 | done | — | workplans/CUST-WP-0062-sbom-nexus-daily-catchup.md |
|
||||
| task | CUST-WP-0062-T02 | done | — | workplans/CUST-WP-0062-sbom-nexus-daily-catchup.md |
|
||||
| task | CUST-WP-0062-T03 | done | — | workplans/CUST-WP-0062-sbom-nexus-daily-catchup.md |
|
||||
| task | CUST-WP-0062-T04 | done | — | workplans/CUST-WP-0062-sbom-nexus-daily-catchup.md |
|
||||
| task | CUST-WP-0062-T05 | done | — | workplans/CUST-WP-0062-sbom-nexus-daily-catchup.md |
|
||||
| task | CUST-WP-0062-T06 | done | — | workplans/CUST-WP-0062-sbom-nexus-daily-catchup.md |
|
||||
| task | CUST-WP-0063-T01 | done | — | workplans/CUST-WP-0063-inbox-governance-packets.md |
|
||||
| task | CUST-WP-0063-T02 | done | — | workplans/CUST-WP-0063-inbox-governance-packets.md |
|
||||
| task | CUST-WP-0063-T03 | done | — | workplans/CUST-WP-0063-inbox-governance-packets.md |
|
||||
| task | CUST-WP-0063-T04 | done | — | workplans/CUST-WP-0063-inbox-governance-packets.md |
|
||||
| task | CUST-WP-0063-T05 | done | — | workplans/CUST-WP-0063-inbox-governance-packets.md |
|
||||
| task | CUST-WP-0064-T01 | done | — | workplans/CUST-WP-0064-sbom-controlled-scan-inputs.md |
|
||||
| task | CUST-WP-0064-T02 | done | — | workplans/CUST-WP-0064-sbom-controlled-scan-inputs.md |
|
||||
| task | CUST-WP-0064-T03 | done | — | workplans/CUST-WP-0064-sbom-controlled-scan-inputs.md |
|
||||
| task | CUST-WP-0064-T04 | done | — | workplans/CUST-WP-0064-sbom-controlled-scan-inputs.md |
|
||||
| task | CUST-WP-0065-T01 | done | — | workplans/CUST-WP-0065-reclassify-repos-and-guidance-docs-to-the-new-sector-domain.md |
|
||||
| task | CUST-WP-0065-T02 | done | — | workplans/CUST-WP-0065-reclassify-repos-and-guidance-docs-to-the-new-sector-domain.md |
|
||||
| task | CUST-WP-0065-T03 | done | — | workplans/CUST-WP-0065-reclassify-repos-and-guidance-docs-to-the-new-sector-domain.md |
|
||||
| task | CUST-WP-0065-T04 | done | — | workplans/CUST-WP-0065-reclassify-repos-and-guidance-docs-to-the-new-sector-domain.md |
|
||||
| task | CUST-WP-0066-T01 | done | — | workplans/CUST-WP-0066-repository-qualified-ad-hoc-identifiers.md |
|
||||
| task | CUST-WP-0066-T02 | done | — | workplans/CUST-WP-0066-repository-qualified-ad-hoc-identifiers.md |
|
||||
| task | CUST-WP-0066-T03 | done | — | workplans/CUST-WP-0066-repository-qualified-ad-hoc-identifiers.md |
|
||||
| task | CUST-WP-0067-T01 | done | — | workplans/CUST-WP-0067-hub-authority-target-resolution.md |
|
||||
| task | CUST-WP-0067-T02 | done | — | workplans/CUST-WP-0067-hub-authority-target-resolution.md |
|
||||
| task | CUST-WP-0067-T03 | done | — | workplans/CUST-WP-0067-hub-authority-target-resolution.md |
|
||||
| task | CUST-WP-0067-T04 | done | — | workplans/CUST-WP-0067-hub-authority-target-resolution.md |
|
||||
| task | CUST-WP-0067-T05 | done | — | workplans/CUST-WP-0067-hub-authority-target-resolution.md |
|
||||
| task | CUST-WP-0067-T06 | done | — | workplans/CUST-WP-0067-hub-authority-target-resolution.md |
|
||||
| task | CUST-WP-0067-T07 | done | — | workplans/CUST-WP-0067-hub-authority-target-resolution.md |
|
||||
| task | CUST-WP-0067-T08 | done | — | workplans/CUST-WP-0067-hub-authority-target-resolution.md |
|
||||
| task | CUST-WP-0067-T09 | done | — | workplans/CUST-WP-0067-hub-authority-target-resolution.md |
|
||||
| task | CUST-WP-0067-T10 | done | — | workplans/CUST-WP-0067-hub-authority-target-resolution.md |
|
||||
| task | CUST-WP-0068-T01 | done | — | workplans/CUST-WP-0068-cache-only-work-record-recovery.md |
|
||||
| task | CUST-WP-0068-T02 | done | — | workplans/CUST-WP-0068-cache-only-work-record-recovery.md |
|
||||
| task | CUST-WP-0068-T03 | done | — | workplans/CUST-WP-0068-cache-only-work-record-recovery.md |
|
||||
| task | CUST-WP-0068-T04 | done | — | workplans/CUST-WP-0068-cache-only-work-record-recovery.md |
|
||||
| task | CUST-WP-0068-T05 | done | — | workplans/CUST-WP-0068-cache-only-work-record-recovery.md |
|
||||
| task | CUST-WP-0068-T06 | done | — | workplans/CUST-WP-0068-cache-only-work-record-recovery.md |
|
||||
| task | CUST-WP-0068-T07 | done | — | workplans/CUST-WP-0068-cache-only-work-record-recovery.md |
|
||||
| task | CUST-WP-0068-T08 | done | — | workplans/CUST-WP-0068-cache-only-work-record-recovery.md |
|
||||
| task | CUST-WP-0068-T09 | done | — | workplans/CUST-WP-0068-cache-only-work-record-recovery.md |
|
||||
| task | CUST-WP-0070-T01 | done | — | workplans/CUST-WP-0070-publication-repo-category.md |
|
||||
| task | CUST-WP-0070-T02 | done | — | workplans/CUST-WP-0070-publication-repo-category.md |
|
||||
| task | CUST-WP-0070-T03 | done | — | workplans/CUST-WP-0070-publication-repo-category.md |
|
||||
| task | CUST-WP-0071-T01 | done | — | workplans/CUST-WP-0071-measured-workload-sizing-and-weekly-review.md |
|
||||
| task | CUST-WP-0071-T02 | wait | — | workplans/CUST-WP-0071-measured-workload-sizing-and-weekly-review.md |
|
||||
| task | CUST-WP-0071-T03 | wait | — | workplans/CUST-WP-0071-measured-workload-sizing-and-weekly-review.md |
|
||||
| task | CUST-WP-0071-T04 | wait | — | workplans/CUST-WP-0071-measured-workload-sizing-and-weekly-review.md |
|
||||
| task | CUST-WP-0071-T05 | wait | — | workplans/CUST-WP-0071-measured-workload-sizing-and-weekly-review.md |
|
||||
| task | CUST-WP-0072-T01 | done | — | workplans/CUST-WP-0072-fleet-flavor-and-depends-on-backfill.md |
|
||||
| task | CUST-WP-0072-T02 | done | — | workplans/CUST-WP-0072-fleet-flavor-and-depends-on-backfill.md |
|
||||
| task | CUST-WP-0072-T03 | done | — | workplans/CUST-WP-0072-fleet-flavor-and-depends-on-backfill.md |
|
||||
| task | CUST-WP-0072-T04 | done | — | workplans/CUST-WP-0072-fleet-flavor-and-depends-on-backfill.md |
|
||||
| task | CUST-WP-0073-T01 | done | — | workplans/CUST-WP-0073-agent-credential-separation.md |
|
||||
| task | CUST-WP-0073-T02 | wait | — | workplans/CUST-WP-0073-agent-credential-separation.md |
|
||||
| task | CUST-WP-0073-T03 | done | — | workplans/CUST-WP-0073-agent-credential-separation.md |
|
||||
| task | CUST-WP-0073-T04 | wait | — | workplans/CUST-WP-0073-agent-credential-separation.md |
|
||||
| task | CUST-WP-0073-T05 | wait | — | workplans/CUST-WP-0073-agent-credential-separation.md |
|
||||
| task | CUST-WP-0074-T01 | done | — | workplans/CUST-WP-0074-qualified-wait-states.md |
|
||||
| task | CUST-WP-0074-T02 | done | — | workplans/CUST-WP-0074-qualified-wait-states.md |
|
||||
| task | CUST-WP-0074-T03 | done | — | workplans/CUST-WP-0074-qualified-wait-states.md |
|
||||
| task | CUST-WP-0074-T04 | done | — | workplans/CUST-WP-0074-qualified-wait-states.md |
|
||||
| task | CUST-WP-0074-T05 | done | — | workplans/CUST-WP-0074-qualified-wait-states.md |
|
||||
| task | CUST-WP-0074-T06 | done | — | workplans/CUST-WP-0074-qualified-wait-states.md |
|
||||
| task | CUST-WP-0075-T01 | done | — | workplans/CUST-WP-0075-dependency-graph-driven-unblocking.md |
|
||||
| task | CUST-WP-0075-T02 | done | — | workplans/CUST-WP-0075-dependency-graph-driven-unblocking.md |
|
||||
| task | CUST-WP-0075-T03 | done | — | workplans/CUST-WP-0075-dependency-graph-driven-unblocking.md |
|
||||
| task | CUST-WP-0075-T04 | done | — | workplans/CUST-WP-0075-dependency-graph-driven-unblocking.md |
|
||||
| task | CUST-WP-0075-T05 | done | — | workplans/CUST-WP-0075-dependency-graph-driven-unblocking.md |
|
||||
| task | CUST-WP-0075-T06 | done | — | workplans/CUST-WP-0075-dependency-graph-driven-unblocking.md |
|
||||
| task | CUST-WP-0076-T01 | done | — | workplans/CUST-WP-0076-provisioning-window-cadence.md |
|
||||
| task | CUST-WP-0077-T01 | done | — | workplans/CUST-WP-0077-dependency-root-execution-wave.md |
|
||||
| task | CUST-WP-0077-T02 | done | — | workplans/CUST-WP-0077-dependency-root-execution-wave.md |
|
||||
| task | CUST-WP-0077-T03 | done | — | workplans/CUST-WP-0077-dependency-root-execution-wave.md |
|
||||
| task | CUST-WP-0077-T04 | done | — | workplans/CUST-WP-0077-dependency-root-execution-wave.md |
|
||||
| task | CUST-WP-0077-T05 | done | — | workplans/CUST-WP-0077-dependency-root-execution-wave.md |
|
||||
| task | CUST-WP-0078-T01 | done | — | workplans/CUST-WP-0078-security-collaboration-consolidation.md |
|
||||
| task | CUST-WP-0078-T02 | done | — | workplans/CUST-WP-0078-security-collaboration-consolidation.md |
|
||||
| task | CUST-WP-0078-T03 | done | — | workplans/CUST-WP-0078-security-collaboration-consolidation.md |
|
||||
| task | CUST-WP-0078-T04 | done | — | workplans/CUST-WP-0078-security-collaboration-consolidation.md |
|
||||
| task | CUST-WP-0079-T01 | done | — | workplans/CUST-WP-0079-deterministic-security-flow.md |
|
||||
| task | CUST-WP-0079-T02 | done | — | workplans/CUST-WP-0079-deterministic-security-flow.md |
|
||||
| task | CUST-WP-0079-T03 | wait | — | workplans/CUST-WP-0079-deterministic-security-flow.md |
|
||||
| task | CUST-WP-0079-T04 | wait | — | workplans/CUST-WP-0079-deterministic-security-flow.md |
|
||||
| task | CUST-WP-0079-T05 | wait | — | workplans/CUST-WP-0079-deterministic-security-flow.md |
|
||||
| task | CUST-WP-0079-T06 | wait | — | workplans/CUST-WP-0079-deterministic-security-flow.md |
|
||||
| task | CUST-WP-0079-T07 | done | — | workplans/CUST-WP-0079-deterministic-security-flow.md |
|
||||
| task | CUST-WP-0080-T01 | done | — | workplans/CUST-WP-0080-netkingdom-security-blueprint-and-gap-closure.md |
|
||||
| task | CUST-WP-0080-T02 | done | — | workplans/CUST-WP-0080-netkingdom-security-blueprint-and-gap-closure.md |
|
||||
| task | CUST-WP-0080-T03 | progress | — | workplans/CUST-WP-0080-netkingdom-security-blueprint-and-gap-closure.md |
|
||||
| task | CUST-WP-0080-T04 | todo | — | workplans/CUST-WP-0080-netkingdom-security-blueprint-and-gap-closure.md |
|
||||
| task | CUST-WP-0080-T05 | progress | — | workplans/CUST-WP-0080-netkingdom-security-blueprint-and-gap-closure.md |
|
||||
| task | CUST-WP-0080-T06 | progress | — | workplans/CUST-WP-0080-netkingdom-security-blueprint-and-gap-closure.md |
|
||||
| task | CUST-WP-0081-T01 | done | — | workplans/CUST-WP-0081-netkingdom-architecture-review-and-reuse.md |
|
||||
| task | CUST-WP-0081-T02 | done | — | workplans/CUST-WP-0081-netkingdom-architecture-review-and-reuse.md |
|
||||
| task | CUST-WP-0081-T03 | done | — | workplans/CUST-WP-0081-netkingdom-architecture-review-and-reuse.md |
|
||||
| task | THE-WP-0001-T01 | done | — | workplans/THE-WP-0001-federation-interface.md |
|
||||
| task | THE-WP-0001-T02 | done | — | workplans/THE-WP-0001-federation-interface.md |
|
||||
| intake | CUST-IN-0001 | closed | green | intake-legacy-suggestions-migration.md |
|
||||
| intake | CUST-IN-0002 | closed | green | intake-legacy-suggestions-migration.md |
|
||||
| intake | CUST-IN-0003 | closed | green | intake-legacy-suggestions-migration.md |
|
||||
| intake | CUST-IN-0004 | routed | green | intake-legacy-suggestions-migration.md |
|
||||
| intake | CUST-IN-0005 | closed | green | intake-legacy-suggestions-migration.md |
|
||||
| intake | CUST-IN-0006 | closed | green | intake-legacy-suggestions-migration.md |
|
||||
| intake | CUST-IN-0007 | closed | green | intake-legacy-suggestions-migration.md |
|
||||
| intake | CUST-IN-0008 | closed | blue | intake-legacy-suggestions-migration.md |
|
||||
| intake | CUST-IN-0009 | closed | blue | intake-legacy-suggestions-migration.md |
|
||||
| intake | CUST-IN-0010 | closed | green | intake-legacy-suggestions-migration.md |
|
||||
| intake | CUST-IN-0011 | routed | red | intakes.md |
|
||||
| intake | CUST-IN-0012 | closed | green | intakes.md |
|
||||
| intake | CUST-IN-0013 | closed | blue | intakes.md |
|
||||
| intake | CUST-IN-0014 | closed | blue | intakes.md |
|
||||
| intake | CUST-IN-0015 | open | blue | intakes.md |
|
||||
| intake | CUST-IN-0016 | open | green | intakes.md |
|
||||
| intake | CUST-IN-0017 | open | green | intakes.md |
|
||||
| intake | CUST-IN-0018 | open | green | intakes.md |
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[
|
||||
{
|
||||
"path": ".custodian-brief.md",
|
||||
"index": "100644 6aad3a5788fad3abd60c0f1270f160062dc0168b 0\t.custodian-brief.md"
|
||||
},
|
||||
{
|
||||
"path": "WORK-RECORDS.md",
|
||||
"index": "100644 d535e0f2dcc3d454e041a8f1b547b5dea4493380 0\tWORK-RECORDS.md"
|
||||
}
|
||||
]
|
||||
File diff suppressed because one or more lines are too long
|
|
@ -0,0 +1,323 @@
|
|||
{
|
||||
"owner": "the-custodian",
|
||||
"base_revision": "aae10f5bbb6b8380fa9a8dcb955c5825c14dcaae",
|
||||
"message": "Fix KeyCape claim interoperability and verify the composed Forgejo release",
|
||||
"files": [
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/cust80-completion-r2/completion-audit.json",
|
||||
"sha256": "001ede40ad6d7cadcfc575a101828f782f65ea0c75e6a5e0f6b0afe761420b0d"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/actual-issuer-test-summary.json",
|
||||
"sha256": "fae6563963eda88dcc1dc231d7c7dec8bca50fd238d5a84c4920203fd9076807"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/composed-forgejo-source.patch",
|
||||
"sha256": "15cb7f13b1b1d1095cc344176ca337f705333a436a70ae803fcfd3d7f802ccf4"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/composed-patch-verification.json",
|
||||
"sha256": "c7be6167d511df96db68396bea9e05af730d360624789c72bcd447e34ca7776d"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/composed-source-inventory.json",
|
||||
"sha256": "a9bdaef559b010cbe6c884c34141c787c7e1cf56a8b58b9b4c9d387815ce97c7"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after-attempt2.json",
|
||||
"sha256": "0d1db244928063aae16959956115828a0d64e9238ca85f397917ae8c4e260a01"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after-attempt2.jsonl",
|
||||
"sha256": "961c5c121280e8cd38fc3386e30fcd92e9290fb19b7df68a26cbd579b4567c9c"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after-attempt3.json",
|
||||
"sha256": "860d3e3d02f6bb1ffff09f01725aba933879292741c31481bb822dbfb24ad313"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after-attempt3.jsonl",
|
||||
"sha256": "e30775857f9f904731779d2a8167b337806ec375bf9398c9147212a7ab3ecf78"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after.json",
|
||||
"sha256": "9b49035400a123442f93ff3405d03e5380f5cd72b4767516a9bb71cb3e29d9a2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after.jsonl",
|
||||
"sha256": "455776e610d2bf0b120a7c3bcd1b57e18f54861d62419a703ddcd578a3da3deb"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-before.jsonl",
|
||||
"sha256": "222e34ec71e62a895728e5b2b7aa53ebf146e7f26e226fd58c316b1143b0cfbd"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine.go",
|
||||
"sha256": "d5f07f9491ac2212410e1fa8c0248d68ba3a723e7ca99e363627c5292d187aa8"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine_assurance.go",
|
||||
"sha256": "42de751b1e9a243301d566260954813b770558ecb449639acaeab307fe788642"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine_assurance_test.go",
|
||||
"sha256": "44e7459f6c1106a264093c19d61d01a8365f6ad22682906552d832ba39d61dd3"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine_callback_test.go",
|
||||
"sha256": "5cea36b630c895a9473dc876b7128526ddef65d9395b2fddc56343e162452472"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine_test.go",
|
||||
"sha256": "99edd6cfe3e834d73e0447a7915f52cc4ab7b82644669c5ae61963f850b447e8"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-test-attempt1.json",
|
||||
"sha256": "c75ce102ed7e1a37458ebf03d3e617d2cf69ac3570f085910f5f0a77417b72ef"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer_wire_after_test.go",
|
||||
"sha256": "ca411819ebbe9f4576fa2dd8722ddcaf09d868dbafb3e9a2c6f114c865903a9a"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/coordinator-source-review.json",
|
||||
"sha256": "df05e694aa7da5da3b152b423ae04bd5f836a4b9c2c0d21e246bfd4bc8ca0763"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/freeze_composite.py",
|
||||
"sha256": "42caf7444d83fb81e4adb4a287590dd3572059c35be9477c43f185e6e93bfc30"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-attempt2.jsonl",
|
||||
"sha256": "f02f19667656e6a7077b54da2824e45ec7556bb82ced4d3140da61a507706148"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-attempt3.jsonl",
|
||||
"sha256": "5b94c52dc70e1447c8c9e723d2c65106c46fcd0e84dafe13b324a54ebc5381b9"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-attempt4.jsonl",
|
||||
"sha256": "dc0d6142807c6e5a3c60d83f646f5118f25b82835adb5afdee0f68e80bb5fcc2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-attempt5.jsonl",
|
||||
"sha256": "955aef3da3431583202fe9ecc8b030f4374786580e605d9848f6a34121a783e2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-result-attempt2.json",
|
||||
"sha256": "5a454d2586aa4933f85bd9c1a05c0692d434ee78218b9115e714c28c125a420b"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-result-attempt3.json",
|
||||
"sha256": "2364d756120bc90dcd86190900adb26c13f3cbbcd2c5052ee34a0027d6efa8ff"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-result-attempt4.json",
|
||||
"sha256": "eaaa50c708e390f34df0deb949cf4f220bc41b9bf78472c55d83d84b20a8c615"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-result-attempt5.json",
|
||||
"sha256": "a1bf3fff4410d0ef3b16e0ca23c4d16239eff91eaa1d2b52bb0d1efcf26fda93"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture.jsonl",
|
||||
"sha256": "c47bfeb94dae0a6b47bcc4a28c9ea765d98b3a0b72b754dc6148238e0894a894"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/apply_source.py",
|
||||
"sha256": "30b954de9c00f0d907f9bbe3427b45b005cbe3884a85c0a8f51050d45dc3f90a"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/consistency.json",
|
||||
"sha256": "cb2f373865ddbe1892dc9da36bad0d4409ebe5e768f2e90e8699e6686a00781a"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/consistency.stderr.txt",
|
||||
"sha256": "f4a6aa1609a13600a0b97cbb08bbc03b3e247b619ff37912d37f7e109ce798ba"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/projection.json",
|
||||
"sha256": "a7f8b1c91a979d22c3236a6c3be044861f17638ff6656556a1c351383d2a5405"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/projection.stderr.txt",
|
||||
"sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/publication-commit.json",
|
||||
"sha256": "fcf90731e5c0f2a331fb17efe612701660f7873cf429f12c346342768aaf921b"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/publication-inputs.json",
|
||||
"sha256": "ab332f463433cac098427a7fc14de4f4e5ae14b142fcbca4158ca65f2dbd10f1"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/source-application.json",
|
||||
"sha256": "4ff72df57513f5bcbdee085408accce70f8f3d1d99b0528aca97f654c6ded979"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/source-manifest.json",
|
||||
"sha256": "efc3581a2b2a00001b5108e86f2884c6586453dc1adf7af8cffe176ffe354228"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/task-bindings-readback.json",
|
||||
"sha256": "cb8baec6401f0ce858092fcf082b1765b3876baf9933ea9c32f9bcf23bb55853"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/workplan-preimage.md",
|
||||
"sha256": "0ac8db087247bf980339ef8661a26eeb817af82391e3e85038be773fe3c6fb3a"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/workplan.md",
|
||||
"sha256": "95b48b308d5154f87355b2c230dc9990241aeeb37c2094e164952150ed2fd258"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/preimages/access_engine.go",
|
||||
"sha256": "851dc8712c883ec2f3135406cdce58d7adf733c0f79501e2594e41646faf28a2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/preimages/access_engine_callback_test.go",
|
||||
"sha256": "e2fcbfcc2f1077996c947c5c6fd5150aaaa11ba0e77e05f07055a355978398be"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/preimages/access_engine_test.go",
|
||||
"sha256": "0552719648e821243c5c6f887359a724c1440cd077e435f15a444bd3c99da888"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/prepare_composite.py",
|
||||
"sha256": "b90e642b4db70a49503278879c076718f5bd7f1f13edc06916bb07fbcbd2a63f"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/produce_fixture.py",
|
||||
"sha256": "30ad0c84592d7a2cbbbe592f68ec4dfa38af04a8a7088907470003ea869074c8"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/producer-slice-parity.json",
|
||||
"sha256": "81ba3e2e8689edfea31eae39970bc29779d63e9cbab8f17e82998d37b5e90441"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/binary-version-result.json",
|
||||
"sha256": "5b34ec6398ed2c658d22bcfc68375831fe1d8f681fc01ec37443d411e9fa0762"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/build.json",
|
||||
"sha256": "b40b6bc4181a9b1932b0c2db7ea1d1c9d4dfa0477768eeef906fc7cee993aacd"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/cli-attempts.json",
|
||||
"sha256": "338949ece2f2ee5817d274ab52b23090d30f85912882e3f054bb394dfa5d8562"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/cli-report-scope.json",
|
||||
"sha256": "bc0829c2830a1c95d671d110f9dbe2c97815ecab0246f707ff0bc98f81283359"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/cli-results.json",
|
||||
"sha256": "ad07393a5c02636209ee4c50aa6a8ac94357c7eef69407aa0326f5c044b55ef5"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/container-build-result.json",
|
||||
"sha256": "eab449c68eb172bd55d5ccabbb26acb04c305305f4fc73977566811f0242b2ea"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/container-reproduction.json",
|
||||
"sha256": "acb13b9c2135c69e814fdea23fd53688cedbd55c91e127ac190543318e1eee96"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/container-result.json",
|
||||
"sha256": "b9e349566278650ea5db54ae1b337768400be3c4502a55901d8a72059b480333"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/embedded-and-static-backend-result.json",
|
||||
"sha256": "fbac11b0da3f2ef3ee496de2a5aa50bd5e745e46562c64313c596a17aa313f79"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/embedded-extract-result.json",
|
||||
"sha256": "36829b0e4be299de56383b9d46e71e12a03b0b271c924da176c5967b924ae1a1"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/embedded-files.json",
|
||||
"sha256": "74a0ec278ab99ac86ee434d7620229dc4a70146efd51876a1e4738d2c9f4ffdb"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/frontend-result.json",
|
||||
"sha256": "589716f5332480f32f9c67f55129ae5d074770b4d7d815e21f37a7379569e706"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/image-build-metadata.json",
|
||||
"sha256": "5c401df606f8942d2b072347cfea966736b371fb8003696f49262db5aeaa5ff6"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/new-cli-help-result.json",
|
||||
"sha256": "a1c6b33dd1abba2a4f16a5f122362572f0c6a2b83687c6363e9ec362b0771622"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/npm-offline-ci-result.json",
|
||||
"sha256": "9fcacf720b68412990549f2ee122541991993fa3d2352b57987789c9ec828407"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/npm-public-acquire-result.json",
|
||||
"sha256": "de88d9ef86c7e3cb3d234953d23e452f1f12e98e8c3c7faa798863ff8377c84c"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/prepared.json",
|
||||
"sha256": "01bf2cad8dc13fc780db68fec8dcf1bd0da9fbaac13c2923c048f16cf20c49f2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/public-node-checksum.json",
|
||||
"sha256": "71873490b48c325fd9f024f1a0a6979f90d64cf8ae71eb1e2451adcc4819e0b2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/replay-container-build-result.json",
|
||||
"sha256": "15c4a835a4ae72e5f5ecb7c59cb0478357404a6c658d87cbc2603b9e7794879e"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/replay-container-result.json",
|
||||
"sha256": "377a8de444594bef7e16d12331b4843511d078664323ae0b12ba0f12df2093b3"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/replay-image-build-metadata.json",
|
||||
"sha256": "a3582299cf44f29da0c5f3958681141953d100958dd51288be3eb712b78740a8"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/verification.json",
|
||||
"sha256": "17311f339925e54fc6c7c745dee7f38fd69099aa95e0d4dfcc3eae586f60d9d9"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/verify-go-modules-result.json",
|
||||
"sha256": "167646f03fce836e8cee2a848ac38b778e2949e1987e47a1a734924518fcb69d"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-source/tools/forgejo-release-build.py",
|
||||
"sha256": "bd5b15ff2ca1e5694903aed3cd47c4fd1fb8baa43c49dd291029a9c9739cc96c"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-validation.json",
|
||||
"sha256": "eef356c3e747947a10a1e8a247cbf6392f48bea972373fb53848463d683e88f0"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/run_composed.py",
|
||||
"sha256": "3d7f96305b571f4d84244432b20902ddee0d87a63ea312e7c221443c5a080914"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/run_consumer_wire.py",
|
||||
"sha256": "b58edfa22092eea3fa0235d8de7d65c7bce1a3930499902a2e4641c288a53a5e"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/selected-package-test-summary.json",
|
||||
"sha256": "61e3464644b5838619544efdfe7c5ddc97c7cbc7d5e2dae35fb340779c2a532d"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/test_release_cli.py",
|
||||
"sha256": "1f722a55ac97eebdd88abb5f28969e9726f4203d91a139139ef5ce3ee67ccfa6"
|
||||
},
|
||||
{
|
||||
"path": "docs/netkingdom-target-implementation.md",
|
||||
"sha256": "0c2431dd50f89d542d4a1982a048263f0781a08e00c67e8459c238a247961422"
|
||||
},
|
||||
{
|
||||
"path": "workplans/CUST-WP-0080-netkingdom-security-blueprint-and-gap-closure.md",
|
||||
"sha256": "1e8573140955925c4862055e5eb94dc5fab6b1f66f5be88ee9cd299ab1a98599"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -0,0 +1,363 @@
|
|||
{
|
||||
"owner": "the-custodian",
|
||||
"base_revision": "81f2f596498f431b64a9a62951b7206596bd5974",
|
||||
"message": "Fix KeyCape claim interoperability and verify the composed Forgejo release",
|
||||
"files": [
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/cust80-completion-r2/completion-audit.json",
|
||||
"sha256": "001ede40ad6d7cadcfc575a101828f782f65ea0c75e6a5e0f6b0afe761420b0d"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/actual-issuer-test-summary.json",
|
||||
"sha256": "fae6563963eda88dcc1dc231d7c7dec8bca50fd238d5a84c4920203fd9076807"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/annotate_embedded_manifest.py",
|
||||
"sha256": "5720be2ecc2f95e31a5a3df2745f2656cb78f84512541e3176369c4fc25f658f"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/composed-forgejo-source.patch",
|
||||
"sha256": "15cb7f13b1b1d1095cc344176ca337f705333a436a70ae803fcfd3d7f802ccf4"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/composed-patch-verification.json",
|
||||
"sha256": "c7be6167d511df96db68396bea9e05af730d360624789c72bcd447e34ca7776d"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/composed-source-inventory.json",
|
||||
"sha256": "a9bdaef559b010cbe6c884c34141c787c7e1cf56a8b58b9b4c9d387815ce97c7"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after-attempt2.json",
|
||||
"sha256": "0d1db244928063aae16959956115828a0d64e9238ca85f397917ae8c4e260a01"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after-attempt2.jsonl",
|
||||
"sha256": "961c5c121280e8cd38fc3386e30fcd92e9290fb19b7df68a26cbd579b4567c9c"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after-attempt3.json",
|
||||
"sha256": "860d3e3d02f6bb1ffff09f01725aba933879292741c31481bb822dbfb24ad313"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after-attempt3.jsonl",
|
||||
"sha256": "e30775857f9f904731779d2a8167b337806ec375bf9398c9147212a7ab3ecf78"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after.json",
|
||||
"sha256": "9b49035400a123442f93ff3405d03e5380f5cd72b4767516a9bb71cb3e29d9a2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-after.jsonl",
|
||||
"sha256": "455776e610d2bf0b120a7c3bcd1b57e18f54861d62419a703ddcd578a3da3deb"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-before.jsonl",
|
||||
"sha256": "222e34ec71e62a895728e5b2b7aa53ebf146e7f26e226fd58c316b1143b0cfbd"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine.go",
|
||||
"sha256": "d5f07f9491ac2212410e1fa8c0248d68ba3a723e7ca99e363627c5292d187aa8"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine_assurance.go",
|
||||
"sha256": "42de751b1e9a243301d566260954813b770558ecb449639acaeab307fe788642"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine_assurance_test.go",
|
||||
"sha256": "44e7459f6c1106a264093c19d61d01a8365f6ad22682906552d832ba39d61dd3"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine_callback_test.go",
|
||||
"sha256": "5cea36b630c895a9473dc876b7128526ddef65d9395b2fddc56343e162452472"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-source/access_engine_test.go",
|
||||
"sha256": "99edd6cfe3e834d73e0447a7915f52cc4ab7b82644669c5ae61963f850b447e8"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-test-attempt1.json",
|
||||
"sha256": "c75ce102ed7e1a37458ebf03d3e617d2cf69ac3570f085910f5f0a77417b72ef"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer-test-attempt1.log",
|
||||
"sha256": "5079f92ed8458154848863702b3152bb0aa4efcd1b3fd6cb0372abbc2d668581"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/consumer_wire_after_test.go",
|
||||
"sha256": "ca411819ebbe9f4576fa2dd8722ddcaf09d868dbafb3e9a2c6f114c865903a9a"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/coordinator-source-review.json",
|
||||
"sha256": "df05e694aa7da5da3b152b423ae04bd5f836a4b9c2c0d21e246bfd4bc8ca0763"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/freeze_composite.py",
|
||||
"sha256": "42caf7444d83fb81e4adb4a287590dd3572059c35be9477c43f185e6e93bfc30"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-attempt2.jsonl",
|
||||
"sha256": "f02f19667656e6a7077b54da2824e45ec7556bb82ced4d3140da61a507706148"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-attempt3.jsonl",
|
||||
"sha256": "5b94c52dc70e1447c8c9e723d2c65106c46fcd0e84dafe13b324a54ebc5381b9"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-attempt4.jsonl",
|
||||
"sha256": "dc0d6142807c6e5a3c60d83f646f5118f25b82835adb5afdee0f68e80bb5fcc2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-attempt5.jsonl",
|
||||
"sha256": "955aef3da3431583202fe9ecc8b030f4374786580e605d9848f6a34121a783e2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-result-attempt2.json",
|
||||
"sha256": "5a454d2586aa4933f85bd9c1a05c0692d434ee78218b9115e714c28c125a420b"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-result-attempt3.json",
|
||||
"sha256": "2364d756120bc90dcd86190900adb26c13f3cbbcd2c5052ee34a0027d6efa8ff"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-result-attempt4.json",
|
||||
"sha256": "eaaa50c708e390f34df0deb949cf4f220bc41b9bf78472c55d83d84b20a8c615"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture-result-attempt5.json",
|
||||
"sha256": "a1bf3fff4410d0ef3b16e0ca23c4d16239eff91eaa1d2b52bb0d1efcf26fda93"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/issuer-fixture.jsonl",
|
||||
"sha256": "c47bfeb94dae0a6b47bcc4a28c9ea765d98b3a0b72b754dc6148238e0894a894"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/apply_source.py",
|
||||
"sha256": "30b954de9c00f0d907f9bbe3427b45b005cbe3884a85c0a8f51050d45dc3f90a"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/consistency.json",
|
||||
"sha256": "cb2f373865ddbe1892dc9da36bad0d4409ebe5e768f2e90e8699e6686a00781a"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/consistency.stderr.txt",
|
||||
"sha256": "f4a6aa1609a13600a0b97cbb08bbc03b3e247b619ff37912d37f7e109ce798ba"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/projection.json",
|
||||
"sha256": "a7f8b1c91a979d22c3236a6c3be044861f17638ff6656556a1c351383d2a5405"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/projection.stderr.txt",
|
||||
"sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/publication-commit.json",
|
||||
"sha256": "fcf90731e5c0f2a331fb17efe612701660f7873cf429f12c346342768aaf921b"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/publication-inputs.json",
|
||||
"sha256": "ab332f463433cac098427a7fc14de4f4e5ae14b142fcbca4158ca65f2dbd10f1"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/source-application.json",
|
||||
"sha256": "4ff72df57513f5bcbdee085408accce70f8f3d1d99b0528aca97f654c6ded979"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/source-manifest.json",
|
||||
"sha256": "efc3581a2b2a00001b5108e86f2884c6586453dc1adf7af8cffe176ffe354228"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/task-bindings-readback.json",
|
||||
"sha256": "cb8baec6401f0ce858092fcf082b1765b3876baf9933ea9c32f9bcf23bb55853"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/workplan-preimage.md",
|
||||
"sha256": "0ac8db087247bf980339ef8661a26eeb817af82391e3e85038be773fe3c6fb3a"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/owner-integration/workplan.md",
|
||||
"sha256": "95b48b308d5154f87355b2c230dc9990241aeeb37c2094e164952150ed2fd258"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/preimages/access_engine.go",
|
||||
"sha256": "851dc8712c883ec2f3135406cdce58d7adf733c0f79501e2594e41646faf28a2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/preimages/access_engine_callback_test.go",
|
||||
"sha256": "e2fcbfcc2f1077996c947c5c6fd5150aaaa11ba0e77e05f07055a355978398be"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/preimages/access_engine_test.go",
|
||||
"sha256": "0552719648e821243c5c6f887359a724c1440cd077e435f15a444bd3c99da888"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/prepare_composite.py",
|
||||
"sha256": "b90e642b4db70a49503278879c076718f5bd7f1f13edc06916bb07fbcbd2a63f"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/produce_fixture.py",
|
||||
"sha256": "30ad0c84592d7a2cbbbe592f68ec4dfa38af04a8a7088907470003ea869074c8"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/producer-slice-parity.json",
|
||||
"sha256": "81ba3e2e8689edfea31eae39970bc29779d63e9cbab8f17e82998d37b5e90441"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/binary-version-result.json",
|
||||
"sha256": "5b34ec6398ed2c658d22bcfc68375831fe1d8f681fc01ec37443d411e9fa0762"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/build.json",
|
||||
"sha256": "b40b6bc4181a9b1932b0c2db7ea1d1c9d4dfa0477768eeef906fc7cee993aacd"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/cli-attempts.json",
|
||||
"sha256": "338949ece2f2ee5817d274ab52b23090d30f85912882e3f054bb394dfa5d8562"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/cli-report-scope.json",
|
||||
"sha256": "bc0829c2830a1c95d671d110f9dbe2c97815ecab0246f707ff0bc98f81283359"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/cli-results.json",
|
||||
"sha256": "ad07393a5c02636209ee4c50aa6a8ac94357c7eef69407aa0326f5c044b55ef5"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/container-build-result.json",
|
||||
"sha256": "eab449c68eb172bd55d5ccabbb26acb04c305305f4fc73977566811f0242b2ea"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/container-build.log",
|
||||
"sha256": "93085da15ddc99e2e8276a0ea7ceded7485588e9b558689a8661e31db345b3f0"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/container-reproduction.json",
|
||||
"sha256": "acb13b9c2135c69e814fdea23fd53688cedbd55c91e127ac190543318e1eee96"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/container-result.json",
|
||||
"sha256": "b9e349566278650ea5db54ae1b337768400be3c4502a55901d8a72059b480333"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/embedded-and-static-backend-result.json",
|
||||
"sha256": "fbac11b0da3f2ef3ee496de2a5aa50bd5e745e46562c64313c596a17aa313f79"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/embedded-and-static-backend.log",
|
||||
"sha256": "80ed63fcdd3333fbf2b36b56ac0fe336c21a4757082ff90a2caf078923a151d4"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/embedded-extract-result.json",
|
||||
"sha256": "36829b0e4be299de56383b9d46e71e12a03b0b271c924da176c5967b924ae1a1"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/embedded-files.json",
|
||||
"sha256": "ca09d0b2ed436ad6d3473da35d0d1081bdd8c3311825f4684993b33e6b426736"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/embedded-manifest-derivation.json",
|
||||
"sha256": "a5823f8f9409661cd90e343506850d2d4835860618ae49578e654aa2e5e63f27"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/frontend-result.json",
|
||||
"sha256": "589716f5332480f32f9c67f55129ae5d074770b4d7d815e21f37a7379569e706"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/image-build-metadata.json",
|
||||
"sha256": "5c401df606f8942d2b072347cfea966736b371fb8003696f49262db5aeaa5ff6"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/new-cli-help-result.json",
|
||||
"sha256": "a1c6b33dd1abba2a4f16a5f122362572f0c6a2b83687c6363e9ec362b0771622"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/npm-offline-ci-result.json",
|
||||
"sha256": "9fcacf720b68412990549f2ee122541991993fa3d2352b57987789c9ec828407"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/npm-public-acquire-result.json",
|
||||
"sha256": "de88d9ef86c7e3cb3d234953d23e452f1f12e98e8c3c7faa798863ff8377c84c"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/prepared.json",
|
||||
"sha256": "01bf2cad8dc13fc780db68fec8dcf1bd0da9fbaac13c2923c048f16cf20c49f2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/public-node-checksum.json",
|
||||
"sha256": "71873490b48c325fd9f024f1a0a6979f90d64cf8ae71eb1e2451adcc4819e0b2"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/replay-container-build-result.json",
|
||||
"sha256": "15c4a835a4ae72e5f5ecb7c59cb0478357404a6c658d87cbc2603b9e7794879e"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/replay-container-build.log",
|
||||
"sha256": "3ed44efd37226609b37c8016fc9c78d889fb2f7207ae62bb04ac633aa2fab953"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/replay-container-result.json",
|
||||
"sha256": "377a8de444594bef7e16d12331b4843511d078664323ae0b12ba0f12df2093b3"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/replay-image-build-metadata.json",
|
||||
"sha256": "a3582299cf44f29da0c5f3958681141953d100958dd51288be3eb712b78740a8"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/verification.json",
|
||||
"sha256": "17311f339925e54fc6c7c745dee7f38fd69099aa95e0d4dfcc3eae586f60d9d9"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/verify-go-modules-result.json",
|
||||
"sha256": "167646f03fce836e8cee2a848ac38b778e2949e1987e47a1a734924518fcb69d"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-source/build/forgejo/README.md",
|
||||
"sha256": "6250821cc41d10b92e6d91dde1f2b59b53a9d47d78ada3a597c9d039549c0da4"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-source/build/forgejo/forgejo-security-extension.patch",
|
||||
"sha256": "15cb7f13b1b1d1095cc344176ca337f705333a436a70ae803fcfd3d7f802ccf4"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-source/build/forgejo/inputs.lock.json",
|
||||
"sha256": "acf9859d1b1009d1afe0844f2068f9b95cfadb176591edce0ec42084604e4d65"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-source/build/forgejo/runtime-base-config.json",
|
||||
"sha256": "bc5a3df111729582faadebd01d126ba769e2b65d0c62f306f6bc79f4e562452b"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-source/tools/forgejo-release-build.py",
|
||||
"sha256": "bd5b15ff2ca1e5694903aed3cd47c4fd1fb8baa43c49dd291029a9c9739cc96c"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-validation.json",
|
||||
"sha256": "eef356c3e747947a10a1e8a247cbf6392f48bea972373fb53848463d683e88f0"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/run_composed.py",
|
||||
"sha256": "3d7f96305b571f4d84244432b20902ddee0d87a63ea312e7c221443c5a080914"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/run_consumer_wire.py",
|
||||
"sha256": "b58edfa22092eea3fa0235d8de7d65c7bce1a3930499902a2e4641c288a53a5e"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/selected-package-test-summary.json",
|
||||
"sha256": "61e3464644b5838619544efdfe7c5ddc97c7cbc7d5e2dae35fb340779c2a532d"
|
||||
},
|
||||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/test_release_cli.py",
|
||||
"sha256": "1f722a55ac97eebdd88abb5f28969e9726f4203d91a139139ef5ce3ee67ccfa6"
|
||||
},
|
||||
{
|
||||
"path": "docs/netkingdom-target-implementation.md",
|
||||
"sha256": "0c2431dd50f89d542d4a1982a048263f0781a08e00c67e8459c238a247961422"
|
||||
},
|
||||
{
|
||||
"path": "workplans/CUST-WP-0080-netkingdom-security-blueprint-and-gap-closure.md",
|
||||
"sha256": "1e8573140955925c4862055e5eb94dc5fab6b1f66f5be88ee9cd299ab1a98599"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -0,0 +1,186 @@
|
|||
{
|
||||
"path": "docs/changes/netkingdom-target-2026-10-18/forgejo-keycape-claims-r1/release-evidence/embedded-files.json",
|
||||
"findings": [
|
||||
{
|
||||
"rule": "bitbucket-client-secret",
|
||||
"start_line": 1159,
|
||||
"end_line": 1159
|
||||
},
|
||||
{
|
||||
"rule": "discord-api-token",
|
||||
"start_line": 1126,
|
||||
"end_line": 1126
|
||||
},
|
||||
{
|
||||
"rule": "discord-api-token",
|
||||
"start_line": 1168,
|
||||
"end_line": 1168
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 217,
|
||||
"end_line": 217
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 861,
|
||||
"end_line": 861
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 956,
|
||||
"end_line": 956
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 1121,
|
||||
"end_line": 1121
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 1388,
|
||||
"end_line": 1388
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 1389,
|
||||
"end_line": 1389
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 1428,
|
||||
"end_line": 1428
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 1706,
|
||||
"end_line": 1706
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 1711,
|
||||
"end_line": 1711
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 1787,
|
||||
"end_line": 1787
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 1790,
|
||||
"end_line": 1790
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 1791,
|
||||
"end_line": 1791
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 1812,
|
||||
"end_line": 1812
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2066,
|
||||
"end_line": 2066
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2081,
|
||||
"end_line": 2081
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2149,
|
||||
"end_line": 2149
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2150,
|
||||
"end_line": 2150
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2152,
|
||||
"end_line": 2152
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2156,
|
||||
"end_line": 2156
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2159,
|
||||
"end_line": 2159
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2170,
|
||||
"end_line": 2170
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2171,
|
||||
"end_line": 2171
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2192,
|
||||
"end_line": 2192
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2193,
|
||||
"end_line": 2193
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2194,
|
||||
"end_line": 2194
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2195,
|
||||
"end_line": 2195
|
||||
},
|
||||
{
|
||||
"rule": "discord-api-token",
|
||||
"start_line": 2223,
|
||||
"end_line": 2223
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2197,
|
||||
"end_line": 2197
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2200,
|
||||
"end_line": 2200
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2201,
|
||||
"end_line": 2201
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2202,
|
||||
"end_line": 2202
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2203,
|
||||
"end_line": 2203
|
||||
},
|
||||
{
|
||||
"rule": "generic-api-key",
|
||||
"start_line": 2219,
|
||||
"end_line": 2219
|
||||
}
|
||||
],
|
||||
"scanner_rules_changed": false
|
||||
}
|
||||
|
|
@ -0,0 +1,40 @@
|
|||
"""Commit the refined explicit public capsule through unchanged normal hooks."""
|
||||
from pathlib import Path
|
||||
import hashlib
|
||||
import json
|
||||
import subprocess
|
||||
|
||||
HERE = Path(__file__).resolve().parent
|
||||
ROOT = HERE.parents[3]
|
||||
cfg = json.loads((HERE / 'publication-inputs.json').read_text())
|
||||
def git(*args):
|
||||
return subprocess.check_output(['git', '-C', str(ROOT), *args], text=True).strip()
|
||||
assert git('rev-parse', 'HEAD') == cfg['base_revision']
|
||||
remote = git('ls-remote', 'origin', 'refs/heads/main').split()[0]
|
||||
subprocess.run(['git', '-C', str(ROOT), 'merge-base', '--is-ancestor', remote,
|
||||
cfg['base_revision']], check=True)
|
||||
paths = [r['path'] for r in cfg['files']]
|
||||
for row in cfg['files']:
|
||||
assert hashlib.sha256((ROOT / row['path']).read_bytes()).hexdigest() == row['sha256']
|
||||
protected = {}
|
||||
for row in json.loads((HERE / 'publication-backup/originals.json').read_text()):
|
||||
name = row['path']
|
||||
assert (ROOT / name).read_bytes() == (HERE / 'publication-backup' / (name + '.worktree')).read_bytes()
|
||||
assert git('ls-files', '--stage', '--', name) == row['index']
|
||||
protected[name] = ((ROOT / name).read_bytes(), row['index'])
|
||||
# Generic build/log ignore rules are not secret scanner controls. Force only
|
||||
# this exact verified manifest; ordinary generated-only and scanner hooks run.
|
||||
git('add', '-f', '--', *paths)
|
||||
run = subprocess.run(['git', '-C', str(ROOT), 'commit', '--only', '-m', cfg['message'], '--', *paths],
|
||||
capture_output=True, text=True, timeout=240)
|
||||
head = git('rev-parse', 'HEAD')
|
||||
(HERE / 'publication-commit.json').write_text(json.dumps(dict(exit_code=run.returncode,
|
||||
commit=head, base=cfg['base_revision'], files=cfg['files'], stdout=run.stdout,
|
||||
stderr=run.stderr, preceding_refusal='first-commit-refusal.json',
|
||||
remote_before='git:' + remote, concurrent_base_advance='concurrent-base-advance.json'), indent=2) + '\n')
|
||||
for name, (raw, index) in protected.items():
|
||||
assert (ROOT / name).read_bytes() == raw
|
||||
assert git('ls-files', '--stage', '--', name) == index
|
||||
assert run.returncode == 0, 'normal commit refused; retained'
|
||||
assert set(git('diff-tree', '--no-commit-id', '--name-only', '-r', head).splitlines()) == set(paths)
|
||||
print(json.dumps(dict(status='committed', commit=head, paths=len(paths), ordinary_hooks=True)))
|
||||
Loading…
Add table
Add a link
Reference in a new issue