coulomb/railiance-platform
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
railiance-platform/WORK-RECORDS.md

81 lines
8.3 KiB
Markdown
Raw Normal View History

chore(consistency): add generated WORK-RECORDS.md [auto] Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-24 00:29:20 +02:00
# Work Records — railiance-platform
> 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 | RAILIANCE-WP-0005 | finished | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
| workplan | RAILIANCE-WP-0008 | finished | — | workplans/RAILIANCE-WP-0008-openbao-approved-automation-delegation.md |
| workplan | RAILIANCE-WP-0009 | finished | — | workplans/RAILIANCE-WP-0009-issue-core-runtime-ingestion-key-lane.md |
| workplan | RAILIANCE-WP-0010 | finished | — | workplans/RAILIANCE-WP-0010-llm-connect-openrouter-provider-key-lane.md |
| workplan | RAILIANCE-WP-0011 | finished | — | workplans/RAILIANCE-WP-0011-reuse-surface-runtime-secrets-openbao-lane.md |
Document rapp-openbao compatibility handoff
2026-07-26 10:39:40 +02:00
| workplan | RAILIANCE-WP-0012 | finished | — | workplans/RAILIANCE-WP-0012-rapp-openbao-extraction-boundary.md |
Cut forgejo package prune over to OpenBao lane
2026-07-26 09:32:08 +02:00
| workplan | RAILIANCE-WP-0013 | finished | — | workplans/RAILIANCE-WP-0013-forgejo-admin-pat-openbao-cutover.md |
Open RAILIANCE-WP-0015: platform rapp consistency Survey of the four-axis repo family model against the live cluster and all six family repos found the concepts sound but unenforced: rapp.yaml has no schema and has drifted three ways across the three existing rapps, the reef binding registry lists 1 of 3 live rapps, the rapp population diverged from the first-wave plan of record, and the model is not in custodian canon so fix-consistency cannot check it. Operator decisions recorded in the workplan: grouped-by-bounded-context rapp granularity, S3 owns only its own rapps and routes schema/canon changes to the repos that own them, canonize the model now, and build the missing wave-1 user-facing exemplar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 11:08:44 +02:00
| workplan | RAILIANCE-WP-0014 | finished | — | workplans/RAILIANCE-WP-0014-credential-change-suite-stabilization.md |
Publish S3 platform-service rapp pattern; route family proposals T01: docs/rapp-platform-service-pattern.md generalizes the ownership split already drawn in the rapp-openbao and rapp-postgres boundary docs into a reusable four-question test, a reference rapp.yaml for platform services, the grouped-rapp member rule, and the credential-lane position. It deliberately does not restate the four-axis model, which railiance-master owns. T03/T04/T05: proposals routed to the repos that own the model rather than authored here - reef-railiance (bound_rapps lists 1 of 3 live rapps, and should be derived rather than hand-listed), railiance-master (rapp.schema.json plus a family declaration validator, grouped-rapp members field, wave-2 candidate refresh), the-custodian (canon promotion of the four-axis model, which also closes the open C-31 multi-segment prefix failures). T02 is held until the schema settles so the platform rapps and the schema do not converge on different answers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 11:11:57 +02:00
| workplan | RAILIANCE-WP-0015 | active | — | workplans/RAILIANCE-WP-0015-platform-rapp-consistency.md |
Assess the Railiance architecture in aspiration from INTENT files Reads all ten local railiance-* INTENT.md files as a statement of intended architecture, cross-checked against git history, remotes and the live cluster. Ten repos declare eight distinct intents. The aspiration is coherent and the handoffs are stated from both sides. Findings: railiance-bootstrap is a second local clone of railiance-cluster rather than a repo (which means fleet counts built by scanning ~ overcount, including the 112 figure in the org refactor); railiance-hosts and railiance-infra are distinct remotes with unrelated histories and byte-identical INTENT, both claiming S1; railiance-forge is unplaced in the OAS stack dimension; S4 is aspiration-only at 25 commits and zero workplans. The strongest finding is a shared thread nobody named: five layers independently aspire to be "self-evidencing" or "auditable", and no repo owns the verification substrate that would evaluate those claims. That is the same gap as the enforcement control loop, arrived at from the opposite direction. Also notes missing homes for observability, end-to-end restore proof, and the cost-attribution interface. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:01:21 +02:00
| workplan | RAILIANCE-WP-0016 | ready | — | workplans/RAILIANCE-WP-0016-apps-pg-resource-evidence.md |
Route the cleanup backlog to railiance-master for adoption T03 done: sent as ac73b172 with the recommendation that master takes the eight ratification and taxonomy items, and including the correction that our earlier ArgoCD report to them was wrong. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 01:35:04 +02:00
| workplan | RAILIANCE-WP-0016 | active | — | workplans/RAILIANCE-WP-0016-architecture-cleanup-backlog.md |
chore(consistency): add generated WORK-RECORDS.md [auto] Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-24 00:29:20 +02:00
| task | RAILIANCE-WP-0005-T01 | done | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
| task | RAILIANCE-WP-0005-T02 | done | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
| task | RAILIANCE-WP-0005-T03 | done | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
| task | RAILIANCE-WP-0005-T04 | done | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
| task | RAILIANCE-WP-0005-T05 | done | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
| task | RAILIANCE-WP-0005-T06 | done | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
| task | RAILIANCE-WP-0005-T07 | done | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
| task | RAILIANCE-WP-0005-T08 | done | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
| task | RAILIANCE-WP-0005-T09 | done | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
| task | RAILIANCE-WP-0005-T10 | done | — | workplans/RAILIANCE-WP-0005-credential-request-and-lease-broker.md |
| task | RAILIANCE-WP-0008-T01 | done | — | workplans/RAILIANCE-WP-0008-openbao-approved-automation-delegation.md |
| task | RAILIANCE-WP-0008-T02 | done | — | workplans/RAILIANCE-WP-0008-openbao-approved-automation-delegation.md |
| task | RAILIANCE-WP-0008-T03 | done | — | workplans/RAILIANCE-WP-0008-openbao-approved-automation-delegation.md |
| task | RAILIANCE-WP-0008-T04 | done | — | workplans/RAILIANCE-WP-0008-openbao-approved-automation-delegation.md |
| task | RAILIANCE-WP-0008-T05 | done | — | workplans/RAILIANCE-WP-0008-openbao-approved-automation-delegation.md |
| task | RAILIANCE-WP-0009-T01 | done | — | workplans/RAILIANCE-WP-0009-issue-core-runtime-ingestion-key-lane.md |
| task | RAILIANCE-WP-0009-T02 | done | — | workplans/RAILIANCE-WP-0009-issue-core-runtime-ingestion-key-lane.md |
| task | RAILIANCE-WP-0009-T03 | done | — | workplans/RAILIANCE-WP-0009-issue-core-runtime-ingestion-key-lane.md |
| task | RAILIANCE-WP-0009-T04 | done | — | workplans/RAILIANCE-WP-0009-issue-core-runtime-ingestion-key-lane.md |
| task | RAILIANCE-WP-0009-T05 | done | — | workplans/RAILIANCE-WP-0009-issue-core-runtime-ingestion-key-lane.md |
| task | RAILIANCE-WP-0009-T06 | done | — | workplans/RAILIANCE-WP-0009-issue-core-runtime-ingestion-key-lane.md |
| task | RAILIANCE-WP-0009-T07 | done | — | workplans/RAILIANCE-WP-0009-issue-core-runtime-ingestion-key-lane.md |
| task | RAILIANCE-WP-0010-T01 | done | — | workplans/RAILIANCE-WP-0010-llm-connect-openrouter-provider-key-lane.md |
| task | RAILIANCE-WP-0010-T02 | done | — | workplans/RAILIANCE-WP-0010-llm-connect-openrouter-provider-key-lane.md |
| task | RAILIANCE-WP-0010-T03 | done | — | workplans/RAILIANCE-WP-0010-llm-connect-openrouter-provider-key-lane.md |
| task | RAILIANCE-WP-0010-T04 | done | — | workplans/RAILIANCE-WP-0010-llm-connect-openrouter-provider-key-lane.md |
| task | RAILIANCE-WP-0010-T05 | done | — | workplans/RAILIANCE-WP-0010-llm-connect-openrouter-provider-key-lane.md |
| task | RAILIANCE-WP-0010-T06 | done | — | workplans/RAILIANCE-WP-0010-llm-connect-openrouter-provider-key-lane.md |
| task | RAILIANCE-WP-0010-T07 | done | — | workplans/RAILIANCE-WP-0010-llm-connect-openrouter-provider-key-lane.md |
| task | RAILIANCE-WP-0011-T01 | done | — | workplans/RAILIANCE-WP-0011-reuse-surface-runtime-secrets-openbao-lane.md |
| task | RAILIANCE-WP-0011-T02 | done | — | workplans/RAILIANCE-WP-0011-reuse-surface-runtime-secrets-openbao-lane.md |
| task | RAILIANCE-WP-0011-T03 | done | — | workplans/RAILIANCE-WP-0011-reuse-surface-runtime-secrets-openbao-lane.md |
| task | RAILIANCE-WP-0011-T04 | done | — | workplans/RAILIANCE-WP-0011-reuse-surface-runtime-secrets-openbao-lane.md |
Define rapp-openbao boundary
2026-07-25 11:22:50 +02:00
| task | RAILIANCE-WP-0012-T01 | done | — | workplans/RAILIANCE-WP-0012-rapp-openbao-extraction-boundary.md |
| task | RAILIANCE-WP-0012-T02 | done | — | workplans/RAILIANCE-WP-0012-rapp-openbao-extraction-boundary.md |
| task | RAILIANCE-WP-0012-T03 | done | — | workplans/RAILIANCE-WP-0012-rapp-openbao-extraction-boundary.md |
Document rapp-openbao compatibility handoff
2026-07-26 10:39:40 +02:00
| task | RAILIANCE-WP-0012-T04 | done | — | workplans/RAILIANCE-WP-0012-rapp-openbao-extraction-boundary.md |
Cut forgejo package prune over to OpenBao lane
2026-07-26 09:32:08 +02:00
| task | RAILIANCE-WP-0013-T01 | done | — | workplans/RAILIANCE-WP-0013-forgejo-admin-pat-openbao-cutover.md |
| task | RAILIANCE-WP-0013-T02 | done | — | workplans/RAILIANCE-WP-0013-forgejo-admin-pat-openbao-cutover.md |
| task | RAILIANCE-WP-0013-T03 | done | — | workplans/RAILIANCE-WP-0013-forgejo-admin-pat-openbao-cutover.md |
| task | RAILIANCE-WP-0013-T04 | done | — | workplans/RAILIANCE-WP-0013-forgejo-admin-pat-openbao-cutover.md |
Open RAILIANCE-WP-0015: platform rapp consistency Survey of the four-axis repo family model against the live cluster and all six family repos found the concepts sound but unenforced: rapp.yaml has no schema and has drifted three ways across the three existing rapps, the reef binding registry lists 1 of 3 live rapps, the rapp population diverged from the first-wave plan of record, and the model is not in custodian canon so fix-consistency cannot check it. Operator decisions recorded in the workplan: grouped-by-bounded-context rapp granularity, S3 owns only its own rapps and routes schema/canon changes to the repos that own them, canonize the model now, and build the missing wave-1 user-facing exemplar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 11:08:44 +02:00
| task | RAILIANCE-WP-0014-T01 | done | — | workplans/RAILIANCE-WP-0014-credential-change-suite-stabilization.md |
| task | RAILIANCE-WP-0014-T02 | done | — | workplans/RAILIANCE-WP-0014-credential-change-suite-stabilization.md |
| task | RAILIANCE-WP-0014-T03 | done | — | workplans/RAILIANCE-WP-0014-credential-change-suite-stabilization.md |
| task | RAILIANCE-WP-0014-T04 | done | — | workplans/RAILIANCE-WP-0014-credential-change-suite-stabilization.md |
Rapp context is its own grouping dimension Operator design review considered binding bounded rapp context to Forgejo orgs or State Hub domains and rejected both. OAS P1 governs - independent perspectives must stay in separate dimensions - and cardinality forces it: a repo has exactly one Forgejo org (a path segment in the clone URL) so org:repo is 1:many, while rapp:repo is many:many, and a many:many grouping cannot be derived from a 1:many one. Records the dimension table, the composition block (first-party member repos plus pinned upstream components and a stated purpose), and the precision that makes enforcement well-defined: repos are many:many with rapps but deployables are 1:1, so the validator can ask whether every live deployable belongs to exactly one rapp. That is the coverage check that would have caught all three of this survey's drift findings at once. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 11:34:51 +02:00
| task | RAILIANCE-WP-0015-T01 | done | — | workplans/RAILIANCE-WP-0015-platform-rapp-consistency.md |
Publish S3 platform-service rapp pattern; route family proposals T01: docs/rapp-platform-service-pattern.md generalizes the ownership split already drawn in the rapp-openbao and rapp-postgres boundary docs into a reusable four-question test, a reference rapp.yaml for platform services, the grouped-rapp member rule, and the credential-lane position. It deliberately does not restate the four-axis model, which railiance-master owns. T03/T04/T05: proposals routed to the repos that own the model rather than authored here - reef-railiance (bound_rapps lists 1 of 3 live rapps, and should be derived rather than hand-listed), railiance-master (rapp.schema.json plus a family declaration validator, grouped-rapp members field, wave-2 candidate refresh), the-custodian (canon promotion of the four-axis model, which also closes the open C-31 multi-segment prefix failures). T02 is held until the schema settles so the platform rapps and the schema do not converge on different answers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 11:11:57 +02:00
| task | RAILIANCE-WP-0015-T02 | todo | — | workplans/RAILIANCE-WP-0015-platform-rapp-consistency.md |
Rapp context is its own grouping dimension Operator design review considered binding bounded rapp context to Forgejo orgs or State Hub domains and rejected both. OAS P1 governs - independent perspectives must stay in separate dimensions - and cardinality forces it: a repo has exactly one Forgejo org (a path segment in the clone URL) so org:repo is 1:many, while rapp:repo is many:many, and a many:many grouping cannot be derived from a 1:many one. Records the dimension table, the composition block (first-party member repos plus pinned upstream components and a stated purpose), and the precision that makes enforcement well-defined: repos are many:many with rapps but deployables are 1:1, so the validator can ask whether every live deployable belongs to exactly one rapp. That is the coverage check that would have caught all three of this survey's drift findings at once. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 11:34:51 +02:00
| task | RAILIANCE-WP-0015-T03 | done | — | workplans/RAILIANCE-WP-0015-platform-rapp-consistency.md |
| task | RAILIANCE-WP-0015-T04 | done | — | workplans/RAILIANCE-WP-0015-platform-rapp-consistency.md |
| task | RAILIANCE-WP-0015-T05 | done | — | workplans/RAILIANCE-WP-0015-platform-rapp-consistency.md |
Publish S3 platform-service rapp pattern; route family proposals T01: docs/rapp-platform-service-pattern.md generalizes the ownership split already drawn in the rapp-openbao and rapp-postgres boundary docs into a reusable four-question test, a reference rapp.yaml for platform services, the grouped-rapp member rule, and the credential-lane position. It deliberately does not restate the four-axis model, which railiance-master owns. T03/T04/T05: proposals routed to the repos that own the model rather than authored here - reef-railiance (bound_rapps lists 1 of 3 live rapps, and should be derived rather than hand-listed), railiance-master (rapp.schema.json plus a family declaration validator, grouped-rapp members field, wave-2 candidate refresh), the-custodian (canon promotion of the four-axis model, which also closes the open C-31 multi-segment prefix failures). T02 is held until the schema settles so the platform rapps and the schema do not converge on different answers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 11:11:57 +02:00
| task | RAILIANCE-WP-0015-T06 | todo | — | workplans/RAILIANCE-WP-0015-platform-rapp-consistency.md |
Assess the Railiance architecture in aspiration from INTENT files Reads all ten local railiance-* INTENT.md files as a statement of intended architecture, cross-checked against git history, remotes and the live cluster. Ten repos declare eight distinct intents. The aspiration is coherent and the handoffs are stated from both sides. Findings: railiance-bootstrap is a second local clone of railiance-cluster rather than a repo (which means fleet counts built by scanning ~ overcount, including the 112 figure in the org refactor); railiance-hosts and railiance-infra are distinct remotes with unrelated histories and byte-identical INTENT, both claiming S1; railiance-forge is unplaced in the OAS stack dimension; S4 is aspiration-only at 25 commits and zero workplans. The strongest finding is a shared thread nobody named: five layers independently aspire to be "self-evidencing" or "auditable", and no repo owns the verification substrate that would evaluate those claims. That is the same gap as the enforcement control loop, arrived at from the opposite direction. Also notes missing homes for observability, end-to-end restore proof, and the cost-attribution interface. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:01:21 +02:00
| task | RAILIANCE-WP-0016-T01 | todo | — | workplans/RAILIANCE-WP-0016-apps-pg-resource-evidence.md |
| task | RAILIANCE-WP-0016-T02 | todo | — | workplans/RAILIANCE-WP-0016-apps-pg-resource-evidence.md |
| task | RAILIANCE-WP-0016-T03 | todo | — | workplans/RAILIANCE-WP-0016-apps-pg-resource-evidence.md |
Route the cleanup backlog to railiance-master for adoption T03 done: sent as ac73b172 with the recommendation that master takes the eight ratification and taxonomy items, and including the correction that our earlier ArgoCD report to them was wrong. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 01:35:04 +02:00
| task | RAILIANCE-WP-0016-T01 | done | — | workplans/RAILIANCE-WP-0016-architecture-cleanup-backlog.md |
| task | RAILIANCE-WP-0016-T02 | done | — | workplans/RAILIANCE-WP-0016-architecture-cleanup-backlog.md |
Rescope items 9 and 10; item 10 was badly mis-sized T04 done, and the answer changes the order. Item 10 was scored size 5 as a greenfield build. It is not. railiance-infra already has a Goss baseline suite, an ansible runner, a make verify target that runs it against all hosts and commits TAP reports to git, and an evidence trail in reports/. The mechanism is built and wired. Two things are wrong with it and neither is a build. Nothing runs it - the last TAP report is dated 2026-03-09, five months ago. And its firewall assertion matches /6443\/tcp.*ALLOW/, which asserts the port is allowed but not from whom - it passes identically whether 6443 is restricted to one operator address or open to the internet, which is exactly the drift that went undetected. It would however have caught the other finding, since it asserts Status: active and UFW is inactive on CoulombCore. Rescoped into slices: 10a (run it, tighten the assertion) is size 1-2 and rises to WSJF 12.0, fourth overall and the highest-value item after the ratifications. 10b (schedule + alert path) is 7.0. Names the shared dependency - 10b and 9b are the same plumbing, and building either of 9 or 10 without it produces logs nobody reads. The lesson recorded: the gap analysis correctly identified no-conformance-loop as a capability gap, but the capability was two-thirds built and abandoned. Before sizing a gap as a build, check whether it is actually an abandonment. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 02:01:44 +02:00
| task | RAILIANCE-WP-0016-T03 | done | — | workplans/RAILIANCE-WP-0016-architecture-cleanup-backlog.md |
Record the 10a outcome: estimate held, check paid for itself on first run 32 assertions, 31 pass on Railiance01. The one failure is a real defect the old loose assertion could never have seen: Flannel VXLAN declared open to Anywhere with no source restriction, currently absent from the host, so converging would introduce the exposure rather than correct drift. Also records the sharper finding from wiring it up: verify.yaml was missing the vars_files the bootstrap play had, so the firewall assertions rendered empty and silently asserted nothing - worse than having no check at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 03:30:34 +02:00
| task | RAILIANCE-WP-0016-T04 | done | — | workplans/RAILIANCE-WP-0016-architecture-cleanup-backlog.md |
Route the cleanup backlog to railiance-master for adoption T03 done: sent as ac73b172 with the recommendation that master takes the eight ratification and taxonomy items, and including the correction that our earlier ArgoCD report to them was wrong. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 01:35:04 +02:00
| task | RAILIANCE-WP-0016-T05 | todo | — | workplans/RAILIANCE-WP-0016-architecture-cleanup-backlog.md |
Reference in a new issue Copy permalink