[happy-v587]

Which issue or RFC does this PR close?

Closes #2299.

Rationale for this change

Data accepted with ACCESS_MODE=disabled has no Artifact owner or Candidate owner attestation. Enabling enforcement preserves reads but blocks old Artifact updates with 403 and Candidate approval with 503 artifact_owner_pending. Administrators need explicit attribution and a check of the background Principal's permissions.

What changes are included in this PR?

• Add offline powercontext server access-ownership-migrate plan/apply, explicit ownership, Scope selection, maintenance confirmation, and a pre-switch --background-principal check.
• Add administrator HTTP ownership plan/apply and dry-run. Inventory merged and retired Artifacts, preserve identities and revisions, and report existing-owner and Candidate-attestation conflicts.
• Preserve pending and completed recovery evidence through both CLI and HTTP. External migration writes use durable owner recovery; a same-owner retry completes the original ownership audit before success. Preview does not replay work. Migration keys preserve their accepted form; oversized keys use SHA-256 over the complete ordered identity parts instead of exceeding the Access limit. Offline CLI test fixtures use POSIX database URLs, and Windows portability CI runs the affected pre-switch and recovery cases.
• Check every selected Scope's background contribution permission and existing Profile write authority, including after ownership gaps have been filled.
• Document both locales, synchronize HTTP/integration/Desktop contracts and DSH/Cindy distributions, classify the new Access operations in the E2E harness, and add a source-specific Desktop protocol qualification.

Are there any user-facing changes?

Administrators can preview and assign missing ownership before or after enabling enforcement. HTTP apply requires enforcement and server.admin. Background checks without an Access store return an explicit unavailable error; the offline command supports this check before enforcement.

Ownership assignments are immutable. Back up the database and select the correct Principal for each Scope before applying. Rolling back application code does not undo ownership assignments. The migration changes authorization metadata, preserves domain history, and uses the existing ownership recovery schema.

How was this change tested?

• uv run --frozen pytest -q tests/e2e/test_access_ownership_migration.py tests/e2e/test_owner_recovery_http.py tests/test_owner_recovery.py tests/e2e/test_recall_manifest.py tests/e2e/test_atomic_memory_description_upgrade.py — 67 passed. These cover ownership migration, external recovery/audit retry, long identities, the merged manifest API, and description upgrades.
• make contract-test — 56 passed. Python, integration and Desktop artifacts were regenerated from the combined OpenAPI; pnpm --dir desktop generate:check also passes with the installed OpenJDK on PATH.
• UV_NO_SYNC=1 make check — passed, including lock checks, the combined persistence compatibility review, hooks, type checks and 61 integration-manifest tests.
• make js-test cindy-test with Node 24.14.1 / pnpm 11.13.1 — passed, including 439 DSH unit tests, 9 DSH integration tests, 20 Cindy tests, package creation and committed-bundle drift checks.
• The complete default-feature native Rust suite, Rust formatting, frontend typecheck and all 132 frontend tests pass. The unchanged bundled-qualification regression failed for the unqualified combined digest, then passed after the real built-wheel protocol qualification.

The existing desktop/tests/real_server.py native harness passed all four SQLite HTTP/TLS connection modes on clean Server sources db9c8d6edc49166504b39e0d8038dd0082368dee. All 625 packaged runtime source files match that commit byte for byte, excluding generated version metadata. The immutable source/contract/wheel evidence is recorded under desktop/VALIDATION.md#server-db9c8d6e-protocol-qualification; historical qualification records retain their original identities.

Migration tests use temporary SQLite databases with fault-injected external relationship/audit delivery. Protocol qualification uses independent built-wheel Server processes on macOS ARM64. These results do not establish native Windows/Intel execution, installed Desktop UI/credential acceptance, seekDB/OceanBase upgrade acceptance or real spawned Worker migration acceptance. Windows CI retains the three offline path cases; new remote CI results are separate from local validation.

AI usage statement

Codex (GPT-6.1 and GPT-6 family models) assisted with implementation, code review, regression tests, documentation, and PR preparation. Validation commands and their results are listed above.

[hidb4ai]

Two reproducible ownership/recovery defects remain in the offline and external-store migration paths. Please address the inline findings before merging.

[hidb4ai]

[P2] Preserve recovery evidence in the offline migration too

This call omits owner_recovery, and the command always opens the built-in relationship store. On a stopped domain database containing a pending external-store Profile ownership intent for Alice, running access-ownership-migrate --action apply --owner user:bob --scope-id ... --maintenance-confirmed exits 0 with conflicts: [] and creates a local Bob owner. The original Alice intent remains pending; replaying it against that store then fails with artifact-owner. I reproduced this through the CLI using two SQLite databases. The HTTP protection does not cover this entry point. Inspect the persisted recovery evidence before assigning ownership, or reject deployments this offline command cannot safely migrate before making writes.

[happy-v587]

Fixed in 15c9d93. The offline command now inspects durable ownership recovery evidence in the primary database before assigning an owner. Pending or completed external-store evidence returns a conflict and leaves local ownership untouched. CLI regressions cover both evidence states and verify that the original external owner remains recoverable.

[hidb4ai]

@happy-v587 Rechecked on 67cf2326955150110a27683b41be0d84a2faa346. The original built-in Profile case is fixed, but the new custom-family migration support exposes the same protection gap for incident-report.

[P2] Preserve custom-family recovery evidence in the offline path. An interrupted external HTTP migration to Alice leaves a durable pending owner intent. After stopping the Server, a fresh access-ownership-migrate --action apply --owner user:bob --scope-id ... --maintenance-confirmed process exits 0 with conflicts: [] and persists Bob locally. Alice's intent remains pending, and replay against that store fails with artifact-owner. Reproduced with the real example plugin, separate SQLite domain/relationship stores, and an independent CLI process; only external relationship delivery was fault-injected.

_owned_artifact_families() now includes saved custom declarations (ownership.py:401-403), but its recovery preflight calls OwnerRecovery.inventory_gaps(), which still filters on the process-local ARTIFACT_FAMILY_PROFILES. The offline process does not restore those custom profiles, so their recovery evidence is skipped. The recovery preflight must cover every persisted family accepted by migration before any competing ownership is written.

[happy-v587]

Fixed in 0b39db6. Migration now passes the family set it accepted from persisted declarations into OwnerRecovery.inventory_gaps, and a family without a process-local profile reports its evidence instead of raising. Regression: tests/e2e/test_artifact_plugins.py::test_offline_migration_reports_pending_custom_family_owner creates an incident-report Artifact, stages a pending owner intent for Alice, runs server access-ownership-migrate --action apply --owner user:bob in a separate process, and asserts exit 1, conflicts == [owner-recovery-pending], and no Bob relation. Verified the test fails without the change (migration applies Bob, conflicts: []).

[AlexStocks]

head 0b39db6b 已按本条处置，补两处独立核对。

1. 家族集合同源：ownership.py 的 _owned_artifact_families 取「内置 OWNED_ARTIFACT_FAMILIES ∪ 持久化的 read_artifact_declarations」，plan 侧的 _artifact_gaps(...) 与离线 apply 侧调用的是同一个 frozenset，新增的 _owner_recovery_conflicts(..., families) 把这同一集合传给 OwnerRecovery.inventory_gaps。该函数随后不再回落到进程内 ARTIFACT_FAMILY_PROFILES：传入 families 时用 tuple(dict.fromkeys(families)) 构造 IN 条件，缺本地 profile 的家族走 profile is None 分支报证据而不是 KeyError。离线进程没有插件 profile 时不会再写出与外部 intent 竞争的 owner。
2. release/upgrade-support.json 的 schema_review.persistence_sha256 在本提交由 2c22da66… 变为 e353cb45…，与 server/authz/owner_recovery.py 的改动同源（MANAGED_INPUTS 含 src/powercontext/server/authz）。我在 exact head 副本上用 scripts/upgrade_release_gate.py::managed_digest 复算，得到 e353cb455c823180b0847f7b3b44fce5dcea8bb29d312eecc3f14e83c1e950de，与声明一致。

未覆盖：离线 access-ownership-migrate 对已注册自定义家族的真实重放我没有执行（需要带插件注册的 Server 实例与真实 Access 存储），该 head 的 86 success / 11 skipped 只覆盖既有 job。

[hidb4ai]

@happy-v587 Rechecked 2ee2da386b93e621404a96ac701233452ab19fc0: the custom Artifact pending/completed cases are fixed, but Candidate attribution still has this protection gap.

[P2] Cover every accepted Candidate family in recovery preflight. _candidate_gaps() accepts Prompt Dream Candidates, while ownership.py:314 now passes the Artifact ownership family set to the Candidate recovery scan too; that set excludes prompt. With a valid Prompt Candidate, interrupting external HTTP migration to Alice leaves a durable Candidate intent. Bob's HTTP dry-run then reports it in applied with no conflicts. After stopping the Server, a fresh access-ownership-migrate --action apply --owner user:bob --scope-id ... --maintenance-confirmed exits 0 and persists Bob's attestation; Alice's intent remains pending, and replay against that store fails with candidate-owner.

Reproduced using the SDK Dream path with deterministic generation, real SQLite stores, HTTP migration, and an independent CLI process; external relationship delivery was fault-injected. The unfiltered recovery scan sees Alice's intent, while the migration-filtered scan returns no items. Recovery protection must include every Candidate identity accepted by migration, even when its family does not require standalone Artifact ownership.

[AlexStocks]

@happy-v587 please fix the file confliction

[hidb4ai]

@happy-v587 Re-reviewed 1ca415f5. The previously reported ownership/audit and Windows-path defects are addressed. A merge probe against current master 90355b8e still reports conflicts in desktop/VALIDATION.md, desktop/src-tauri/src/transport/operations.json, desktop/ui/src/generated/operations.ts, and release/upgrade-support.json. Please integrate current master, regenerate the combined contracts, recheck the Desktop qualification and persistence digest, and complete Main, including the newly added Windows cases, before merging.

[hidb4ai]

@happy-v587 Re-reviewed cf6741eb. The previously reported ownership/audit and Windows-path defects are fixed, and the merge conflicts reported on 1ca415f5 are resolved. I found no further blocking defect in the reviewed ownership migration paths. The merged Desktop contract has a matching qualification record, and the persistence-policy declaration is consistent. Current-head Main and acceptance checks are still pending; please complete those, including the affected Windows cases, before merging.

[hidb4ai]

Two ownership-maintenance defects remain: the offline preview schedules processing work, and HTTP migration drops the originating audit context. Please address the inline findings before merging.

[happy-v587]

CI is complete on 19994e2052ad057e0c1ac9ce714744696ecdaf4d: 86 checks succeeded and 1 was skipped; no checks are pending or failed. All 10 workflows completed successfully, including Main, E2E harness and Desktop validation.

All six review threads are resolved. The PR has no merge conflicts. The earlier changes-requested review remains recorded; the fixes and their validation are ready for reviewer confirmation.

[hireview001]

• Resolve merge conflicts with the target branch.

[happy-v587]

Rebased onto master 0b0a1c71; the branch now has no conflicts with the target branch.

Both P2 findings are fixed in 8b2772e2:

• Ownership plan/apply now inventory families restored from persisted Artifact-Family declarations, including registered custom families. Regression: tests/e2e/test_artifact_plugins.py::test_ownership_migration_restores_a_registered_custom_family.
• bounded_idempotency_key keeps existing key spellings and digests longer identities; approval, Candidate attestation, profile, handoff and custom-plugin owner writes use it. Regression: the long-Scope migration test now approves the migrated Candidate at 240 and 256 characters.

Desktop qualification was rerun for the rebased source: wheel powercontext-1.4.2.dev112+g581be595a-py3-none-any.whl, 667 runtime files byte-identical, four SQLite modes passed, record sqlite-atomic-581be595-v1. CI is now running on the new head.

[happy-v587]

CI triage for run 41256517755 (head 7d1ad6d): 90 checks pass; two failed and both are runner infrastructure, not branch behavior.

• desktop-validation / macos (macos-15): the clang linker itself crashed during cargo test — clang: error: unable to execute command: Bus error: 10, linker command failed due to signal. The same Rust suite passes locally, and the linux, windows and macos-15-intel desktop jobs pass.
• managed-resource-candidates / windows-x86_64: curl.exe exited 3221225477 (0xC0000005 access violation) while downloading jaraco.classes-3.4.0 from files.pythonhosted.org inside prepare_managed_resources.py. The macos-arm64 and macos-x86_64 candidates pass.

This account has pull-only rights on oceanbase/powercontext, so per-job rerun returns 403. Pushed 67cf232, an empty commit that only retriggers the workflow matrix; no file changed and the tree is identical to 7d1ad6d.

[hidb4ai]

Re-reviewed commit 67cf2326955150110a27683b41be0d84a2faa346. The earlier background-dispatch and HTTP audit-identity issues are fixed. One confirmed P2 remains in the new custom-family support: a fresh offline migration can miss persisted owner-recovery evidence and assign a competing owner. See the reproduction and repair direction in #2304 (comment). Please address this before merging.

[happy-v587]

Rebased onto master 22090cd and handled the P2 custom-family recovery finding in 0b39db6.

• OwnerRecovery.inventory_gaps now accepts the family set that migration already derives from persisted Artifact-Family declarations, and a family without a process-local profile reports its evidence instead of raising. The offline CLI process therefore sees pending custom-family intents before any competing owner is written.
• Regression tests/e2e/test_artifact_plugins.py::test_offline_migration_reports_pending_custom_family_owner fails without the change (Bob applied, conflicts: []) and passes with it (exit 1, owner-recovery-pending, no Bob relation).
• Rebase conflicts resolved by restoring the branch-side contract artifacts (master 22090cd changed no OpenAPI path or schema) and unioning master's new managed-Ops rationale into release/upgrade-support.json; the persistence review digest is now e3cb455c (includes the migration change in src/powercontext/builtin/persistence).
• Validation: ownership and recovery suites 53 passed, plugin e2e 13 passed (one search-readiness test needed a rerun under load), upgrade gate 115 passed / 6 skipped, contract 61 passed, desktop contract 68 passed / 49 skipped, prek 11 hooks passed.

CI is running on 0b39db6.

[happy-v587]

CI is green on 0b39db6: 86 checks pass, 11 skipped, 0 failed, including the desktop matrix, managed-resource candidates and upgrade acceptance. The PR is MERGEABLE again after the rebase onto 22090cd.

[AlexStocks]

@happy-v587 I have approved this PR. please fix the file confliction.

[happy-v587]

Conflicts are resolved on 7f2f42da: the branch includes master 5032075a, and GitHub reports no merge conflicts.

Main run 41289931395 completed successfully on this exact head: all 18 workflow jobs passed, including OceanBase acceptance. The PR shows 19 successful checks including CLA, with no pending or failed checks. This run's job selection is the evidence for this head; previous runs have separate matrix results.

All eight review threads are resolved. GitHub still reports mergeStateStatus=BLOCKED; successful CI and conflict resolution do not override the remaining review or repository requirements.

[hireview001]

[P2] Account for static permissions in background checks

For fresh legacy Scopes in a single-token deployment, checking service:server-token reports a contribution denial even though the configured worker calls bootstrap_static_scope() before authorization and succeeds. Evaluate the worker's effective permissions, including its configured static preset, without granting bindings during planning.

[happy-v587]

Fixed in e08cc47. Background planning includes the configured local static preset through a read-only Access check. It inspects preset receipts, so a revoked contributor remains denied; planning neither materializes Scope bindings nor grants administrator roles. Existing Profile write authority is still checked separately. HTTP regressions cover cold Scopes, own/other Profile owners, unrelated Principals, revocation, and unchanged grants; offline tests cover configured-token and no-token deployments. The new offline cases are selected by Windows CI. Local SQLite checks pass; the new remote run is separate.

[hidb4ai]

@happy-v587 Rechecked 2ee2da386b93e621404a96ac701233452ab19fc0: the static-preset fix works for ordinary Scope IDs, but the same false denial remains for supported long IDs.

[P2] Match static permission preview to actual bootstrap for long Scopes. On a cold 220- or 256-character Scope, /v1/access/ownership/plan reports service:server-token as denied with no-matching-binding. An immediate authenticated Source write succeeds with 201 through the real SQLite static bootstrap, and repeating the plan returns no gap. The new len(key) <= 255 guard in authz/service.py:923 rejects the generated preset key, whereas the bootstrap path it predicts successfully persists it. Align the read-only prediction with actual bootstrap behavior for supported identities, while retaining the revoked-receipt protection.

This was executed through real Server lifespan and HTTP ASGI with SQLite, not a mocked authorization provider or a spawned-worker/MySQL test.

[happy-v587]

@hireview001 @hidb4ai Please re-review current head e08cc47903e8c283cc165f22a3c44d33e3d38368.

The Handoff recovery-evidence gap, published-Handoff inventory gap, and static background-permission check are fixed. The static check also preserves revoked grants. All 11 review threads are resolved, with fix details and regression evidence in the relevant replies. Local ownership/authorization/recovery tests, contract checks, and make check pass.

The formal review-request action is unavailable to the current integration/account, so I am requesting re-review here.

[hidb4ai]

Re-reviewed 2ee2da386b93e621404a96ac701233452ab19fc0. The previous custom Artifact and Handoff attribution cases are fixed. Two confirmed P2 cases remain:

• Prompt Candidate migration skips recorded owner-recovery evidence and can persist competing attribution: #2304 (comment)
• Static background permission preview falsely rejects supported long Scope IDs: #2304 (comment)

Please address these before merging.