janpeter/Ops-dashboard
1
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions

WIP: feat(IDEA-213): policy-adoptie voor queue dispatch via de operatorflow (ST-1590) #236

Closed
janpeter wants to merge 7 commits from feat/idea-213-dispatch into main
pull from: feat/idea-213-dispatch
merge into: janpeter:main
Conversation 1 Commits 7 Files changed 24 +1273 -20
janpeter commented 2026-09-20 09:15:28 +02:00
Owner
Copy link

Draft — niet mergen. Geopend om CI te laten draaien; IP-10 t/m IP-14 van ST-1590 zijn nog niet uitgevoerd. Hoort bij Scrum4Me #251; de zeven feat/idea-213-dispatch-branches horen bij elkaar.

Inhoud

De adoptieflow adopt_queue_dispatch_policy en de uitbreiding van prisma-operator.sh en policy-bundle-flow.sh voor de zes-rollen-adoptie onder de bestaande schema-lock (IP-02).

Review-fixes (code-review 2026-09-20)

  • T-1840 22b6b33 — een halverwege gestopte migratieset is hervatbaar (RESUME partial), en resolve bindt tijdens een pending adoptie aan de root-owned approval. Hoort bij Scrum4Me c860ba23. Open MINOR: T-1851.

Verificatie (lokaal)

  • test/db-access-operator.test.ts: 56/56; tsc schoon.
  • Linux-rootcontainer met echte flock en echte Prisma-migraties: adoptie-integratie 1/1, vier wrapper-/flow-suites 83/83.
  • Op macOS falen 17 tests in 3 files op flock: command not found — identiek met en zonder deze wijziging.
  • Het partial-pad is end-to-end alleen met de nagebootste policy-adapter bewezen. Een containerproef is geen bewijs voor de geïnstalleerde host.

Commits

  • 8d72f79 feat(IDEA-213): bind queue policy adoption to the operator flow
  • 22b6b33 fix(IDEA-213): give a half-applied policy adoption a way forward

🤖 Generated with Claude Code

Draft — niet mergen. Geopend om CI te laten draaien; IP-10 t/m IP-14 van ST-1590 zijn nog niet uitgevoerd. Hoort bij [Scrum4Me #251](https://git.jp-visser.nl/janpeter/Scrum4Me/pulls/251); de zeven `feat/idea-213-dispatch`-branches horen bij elkaar. ## Inhoud De adoptieflow `adopt_queue_dispatch_policy` en de uitbreiding van `prisma-operator.sh` en `policy-bundle-flow.sh` voor de zes-rollen-adoptie onder de bestaande schema-lock (IP-02). ## Review-fixes (code-review 2026-09-20) - **T-1840** `22b6b33` — een halverwege gestopte migratieset is hervatbaar (`RESUME partial`), en `resolve` bindt tijdens een pending adoptie aan de root-owned approval. Hoort bij Scrum4Me `c860ba23`. Open MINOR: T-1851. ## Verificatie (lokaal) - `test/db-access-operator.test.ts`: 56/56; `tsc` schoon. - Linux-rootcontainer met echte `flock` en echte Prisma-migraties: adoptie-integratie 1/1, vier wrapper-/flow-suites 83/83. - Op macOS falen 17 tests in 3 files op `flock: command not found` — identiek met en zonder deze wijziging. - Het `partial`-pad is end-to-end alleen met de nagebootste policy-adapter bewezen. Een containerproef is geen bewijs voor de geïnstalleerde host. ## Commits - `8d72f79` feat(IDEA-213): bind queue policy adoption to the operator flow - `22b6b33` fix(IDEA-213): give a half-applied policy adoption a way forward 🤖 Generated with [Claude Code](https://claude.com/claude-code)
fix(IDEA-213): give a half-applied policy adoption a way forward
Some checks failed
CI / Select checks (pull_request) Successful in 22s
Details
CI / Root app checks (pull_request) Failing after 1m11s
Details
CI / Ops-agent checks (pull_request) Successful in 39s
Details
CI / Deploy artifact checks (pull_request) Successful in 42s
Details
CI / DB access operator (pull_request) Failing after 1m20s
Details
CI / Mac foundation hermetic checks (pull_request) Successful in 2m41s
Details
CI / Mac foundation reproducible build (pull_request) Successful in 3m7s
Details
CI / Docker image build (pull_request) Successful in 1m21s
Details
CI / Required checks (pull_request) Failing after 13s
Details
22b6b33162 
A migrate deploy that stopped between two migrations left the adoption
stuck: the precheck only knew 'before' and 'after', and the root-only
resolve refused because a pending adoption runs the target checkout
against the still-active old bundle.

Run migrate deploy again on a verified 'partial' ledger, and let resolve
bind to the root-owned pending approval instead of the bundle revision.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
ci(IDEA-213): give the adoption tests a CI owner and a manual config
All checks were successful
CI / Select checks (pull_request) Successful in 38s
Details
CI / Ops-agent checks (pull_request) Successful in 40s
Details
CI / DB access operator (pull_request) Successful in 1m7s
Details
CI / Deploy artifact checks (pull_request) Successful in 38s
Details
CI / Root app checks (pull_request) Successful in 8m16s
Details
CI / Mac foundation hermetic checks (pull_request) Successful in 2m39s
Details
CI / Mac foundation reproducible build (pull_request) Successful in 2m41s
Details
CI / Docker image build (pull_request) Successful in 2m36s
Details
CI / Required checks (pull_request) Successful in 37s
Details
84ca4c7490 
The adoption flow test had no CI test group, which the workflow
contract refuses, and the adoption integration test was added to the
PostgreSQL job's config although that job has no Scrum4Me checkout, no
root container and a different database, so it could only throw. The
contract test pins that config to the operator test alone.

Assign the flow test to the base group and move the integration test to
its own config as the manual Linux root-container gate the runbook
already describes.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The release manifest pins what a release should contain; nothing reported
what a host actually has. capture-db-access-evidence.py hashes the installed
wrappers, the flow YAML, commands.yml and the sudoers rules, and reads the
adoption receipt's manifest/database/migration binding, so check-release.ts
can compare the two.

Strictly read-only: it opens files, hashes them and prints JSON. It refuses a
symlink rather than following it, reports a host without an adoption receipt
as null instead of inventing one, and never replaces a root-owned trusted
hash to make a comparison pass.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
docs(IDEA-213): document dispatch rollout recovery and acceptance
All checks were successful
CI / Select checks (pull_request) Successful in 39s
Details
CI / Ops-agent checks (pull_request) Successful in 42s
Details
CI / DB access operator (pull_request) Successful in 1m12s
Details
CI / Deploy artifact checks (pull_request) Successful in 38s
Details
CI / Mac foundation hermetic checks (pull_request) Successful in 2m31s
Details
CI / Root app checks (pull_request) Successful in 8m34s
Details
CI / Mac foundation reproducible build (pull_request) Successful in 2m36s
Details
CI / Docker image build (pull_request) Successful in 2m3s
Details
CI / Required checks (pull_request) Successful in 12s
Details
41b7a91704 
Write the adoption sequence down as the scripts actually implement it:
operator roles first, then install the wrappers/flows/sudoers rules and
demonstrate fail-before-migrate before the new migrations and the V2 policy
reach main or the deploy checkout, then the release bundle and an explicit
adoption-hash approval, then the four-step adoption flow on a clean approved
checkout without a new git pull, and only then the phases prisma-operator.sh
runs under the config flock and the schema lock.

Also record what already exists and is easy to get wrong: a restart reuses
the original proof, a partial ledger prefix resumes, a failed migration needs
the root-only resolve --rolled-back, the migration count comes from the
approved manifest (eight today, not three), and the adoption integration
config is referenced by no workflow, script or test group, so it runs nowhere
automatically. Documents the evidence file's shape for the release manifest.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
fix(IDEA-213): report a repeated queue policy adoption as done, not refused
All checks were successful
CI / Select checks (pull_request) Successful in 12s
Details
CI / Ops-agent checks (pull_request) Successful in 39s
Details
CI / DB access operator (pull_request) Successful in 1m19s
Details
CI / Deploy artifact checks (pull_request) Successful in 38s
Details
CI / Mac foundation hermetic checks (pull_request) Successful in 2m39s
Details
CI / Root app checks (pull_request) Successful in 8m10s
Details
CI / Mac foundation reproducible build (pull_request) Successful in 2m43s
Details
CI / Docker image build (pull_request) Successful in 2m22s
Details
CI / Required checks (pull_request) Successful in 18s
Details
12e7d13fba 
finish_adoption consumes the approval and the pending file, so a second
adopt-idea-213 fell through to 'explicit adoption approval required' and exited
2. Nothing happened on the database, but the flow showed red — which is
indistinguishable from a real refusal and sends an operator looking for a
problem that does not exist. The "already active" branch could not catch it:
it needs the pending file, so it is only reachable after a crash between the
config write and the cleanup.

adopt_idea_213 now recognises the completed state up front: no approval, no
pending file, and the receipt.json the previous run left behind. It then still
proves the state with one receipt precheck of the active bundle before printing
'queue dispatch adoption already active' and returning 0. The receipt is what
keeps this honest — a host that never adopted has none, so it still stops at
'explicit adoption approval required', and a failing precheck on the adopted
bundle still refuses with 'adopted config has no valid receipt'. No trusted
hash and no root-owned file is replaced anywhere.

macOS cannot judge this suite (no flock), so the red-first and green runs were
made in a disposable node:24-bookworm container; the runbook now carries that
recipe alongside the corrected rerun semantics.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
docs(IDEA-213): require a maintenance window and lock_timeout for dispatch adoption
All checks were successful
CI / Select checks (pull_request) Successful in 1m10s
Details
CI / Ops-agent checks (pull_request) Successful in 39s
Details
CI / DB access operator (pull_request) Successful in 1m15s
Details
CI / Deploy artifact checks (pull_request) Successful in 40s
Details
CI / Mac foundation hermetic checks (pull_request) Successful in 2m33s
Details
CI / Root app checks (pull_request) Successful in 8m0s
Details
CI / Mac foundation reproducible build (pull_request) Successful in 2m40s
Details
CI / Docker image build (pull_request) Successful in 2m26s
Details
CI / Required checks (pull_request) Successful in 12s
Details
ccf9759254 
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
janpeter commented 2026-09-24 13:18:52 +02:00
Author
Owner
Copy link

Ingehaald door #238/#240; unieke runbook-delta (lock_timeout) geport in #241. Evidence-script (ce6014d11) niet geport: geen afnemer (check-release.ts bestaat niet). 12e7d13fb en 22b6b3316 zijn gedekt/achterhaald door de adoptieflow van #238 (approval.env bestaat niet meer).

Ingehaald door #238/#240; unieke runbook-delta (lock_timeout) geport in #241. Evidence-script (ce6014d11) niet geport: geen afnemer (check-release.ts bestaat niet). 12e7d13fb en 22b6b3316 zijn gedekt/achterhaald door de adoptieflow van #238 (approval.env bestaat niet meer).
janpeter closed this pull request 2026-09-24 13:18:52 +02:00
All checks were successful
CI / Select checks (pull_request) Successful in 1m10s
Details
CI / Ops-agent checks (pull_request) Successful in 39s
Required
Details
CI / DB access operator (pull_request) Successful in 1m15s
Required
Details
CI / Deploy artifact checks (pull_request) Successful in 40s
Required
Details
CI / Mac foundation hermetic checks (pull_request) Successful in 2m33s
Details
CI / Root app checks (pull_request) Successful in 8m0s
Required
Details
CI / Mac foundation reproducible build (pull_request) Successful in 2m40s
Details
CI / Docker image build (pull_request) Successful in 2m26s
Required
Details
CI / Required checks (pull_request) Successful in 12s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
severity/s2

   
severity/s3
No labels
severity/s2
severity/s3
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
janpeter/Ops-dashboard!236
No description provided.