Skip to content

feat(gov): SP3b — per-EP migration status (rollup + endpoint + Migrate badge) - #857

Merged
viethqb merged 4 commits into
mainfrom
feat/gov-sp3b-migrate
Nov 13, 2026
Merged

viethqb merged 4 commits into
mainfrom
feat/gov-sp3b-migrate

Conversation

@viethqb

@viethqb viethqb commented Nov 13, 2026

Copy link
Copy Markdown
Member

Governance SP3b — per-enforcement-point migration status

Exposes, per enforcement point, whether any operator (manual) policy has not yet migrated into the model — the signal SP3d's per-EP gate will consume, surfaced today as a badge on the Migrate tab.

What this adds (additive, read-only)

  • ep_migration_status(&[ClassifiedPolicy]) (classify.rs): a pure rollup that partitions a profile's managed_by='operator' policies into migrated / pending / blocked. complete is fail-closed — an EP is complete only when every operator policy has migrated (pending == 0 and no blocked). Compiler/infra policies are ignored.
  • GET /perm/policies/services/{service_id}/migration-status (routes.rs): read-only endpoint mirroring classify_service_policies (auth policy:read), registered in ApiDoc.
  • Migration-complete badge on the Migrate tab, invalidated after migrate/undo.

What this does NOT do

No migration runs here; the Migrate flow (classify → grant/rule, provenance perm.migrated_from, undo, equivalence probes) already exists from SP4d-3. No compiled artifact, golden, or classify logic changes. ep_migration_status is the function SP3d's gate will call — not wired to any gate here.

Scope (decision ②)

The demo stack has exactly one operator policy (a flat access policy, already convertible to a grant) and zero engine-capability shapes, so no operator→typed-engine-privilege mapping is built — deferred until a real shape exists.

Verification

  • cargo fmt --check, cargo clippy --workspace --all-targets -D warnings clean.
  • egret-perm-compile tests pass (incl. 5 ep_migration_status unit tests); routes.rs DB-gated tests pass against the demo postgres.
  • committed_openapi_json_is_current: regenerated egret openapi diffs 0 against the committed file.
  • Generated-client digest unchanged on regeneration.
  • MigrateTab.test.tsx: 22 vitest pass.

Docs: badge documented in egret-data/docs (separate PR); SP3d owns the live screenshot (demo backend lacks the endpoint until then).

🤖 Generated with Claude Code

viethqb and others added 4 commits November 13, 2026 13:02
…EP migration status

ep_migration_status partitions a profile's classified operator policies into
migrated / pending / blocked and reports complete only when every one is
migrated. Pure over the existing classifier output; compiler/infra rows are
skipped. This is the signal SP3d's per-EP gate will consume.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
GET .../services/{service_id}/migration-status returns the EP's migration
standing (migrated/pending/blocked, complete). Read-only; rolls up the existing
classification. OpenAPI + generated client regenerated.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The badge reads the migration-status endpoint and tells the operator whether
the EP's manual policies are all in the model, how many remain, and which are
blocked and why.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Thin package: the Migrate flow already exists (SP4d-3); SP3b adds only the
per-EP migration-status rollup + endpoint + badge. No operator→engine-privilege
mapping (decision 2: nothing to map on the demo stack).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@viethqb
viethqb merged commit 5ed1d46 into main Nov 13, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant