[field report] rc→GA upgraded envs: package-declared permission sets frozen at first-boot snapshot — provenance skip is silent and has no adoption/migration path

[baozhoutao]

Part of steedos-labs/os-project-titanwind-ehr#1606 (and steedos-labs/os-project-titanwind-ehr#1613).

Field report from a production-test deployment. Related but not covered by: #8692 (closed — platform-default seeder / os meta resync path), #8672 (open — org-less materialization; measured-harm follow-up posted there), #2705 (the resync intent this violates in spirit).

Summary

An environment whose database was first initialized on an earlier 17-rc line and then upgraded in place to GA 17.0.0 ends up with sys_permission_set rows that bootstrapDeclaredPermissions / upsertPackagePermissionSet permanently refuses to reconcile: the legacy rows do not carry managed_by: 'package' + the current package_id, so every boot takes the skippedEnvAuthored / skippedForeign branch. Result: every permission change shipped in the package after the env's first boot silently never takes effect — grants stay frozen at the first-boot snapshot while the deployed artifact moves on. The only signal is a log counter; nothing in Setup shows that a package-declared set has diverged from the package.

There is also no adoption/migration path: no migration, no os command, and (in our deployment — see #8672 follow-up) not even a Setup surface that can see the rows. The only remediation we found is direct SQL against sys_permission_set.

Pinned versions

• @objectstack/* 17.0.0 (GA) — core, runtime, objectql, plugin-auth, spec, types, cli
• vendor packs: @objectstack/organizations@1.0.0, @objectstack/security-enterprise@1.0.0
• driver: postgres (postgres:16), single organization
• Env DB first booted ~2026-07-30 on the then-current 17-rc; app image rebuilt/redeployed multiple times since, most recently 2026-08-19 with the current package.

Measured on the live env (2026-08-19, admin session)

• sys_user_permission_set holds 13 assignment rows referencing sys_permission_set ids whose id timestamps date to the env's first boot (2026-07-30). The rows exist and are still enforced by authz.
• The package's permission set (ehr_quality_inspector) currently declares 49 object grants in the built artifact; the env enforces the 41-object first-boot snapshot. Grants added to the package after 07-30 (e.g. CRU on a child object, read on another) return 403 for real users — this is how the freeze was discovered (app issue steedos-labs/os-project-titanwind-ehr#1606).
• Redeploying the current artifact and restarting does not change the snapshot — consistent with the provenance skip in upsertPackagePermissionSet (packages/plugins/plugin-security/src/bootstrap-declared-permissions.ts): update only when existing.managed_by === 'package' && existing.package_id === packageId, else counted as skipped with a log line only.
• Control: a fresh GA 17.0.0 env materializes the same package correctly (49 objects, managed_by: 'package', package_id set, active: true).

Expected vs actual

• Expected (the [cli/plugin-security] dev 元数据物化不一致:默认权限集 insert-if-not-exists 不重物化(声明集走 upsert) #2705 intent, and what the ADR-0086 D5 log line implies): a package-declared permission set edited at the source is reconciled into sys_permission_set on boot, so the deployed artifact and the enforced grants agree; rows the platform's own earlier seeder created are recognized as platform/package-owned, not as tenant customizations.
• Actual: rows created by an earlier 17-rc seeder are classified env-authored (cf. [finding] os meta resync may silently skip every platform default permission set — the seeder never writes managed_by, and the tests stub the field default away #8692's mechanism — inserts without managed_by fall to the object's defaultValue: 'admin'), so GA's sync freezes them forever, silently. The env-authored protection is sound for genuine admin-authored sets; the defect is that the platform's own historical rows land in that bucket and there is no adoption path out of it.

What we did NOT do

No app-side workaround was added. We are remediating the env with one-off SQL (UPDATE sys_permission_set SET managed_by='package', package_id='<pkg>', organization_id='<org>' WHERE name LIKE '<prefix>%' + restart), recorded in the app issue. Every other env upgraded along the same rc→GA line will need the same surgery until an adoption/migration path exists.

Asks

1. An adoption/migration for legacy sys_permission_set rows whose name matches a currently-declared package set but whose provenance columns predate the current scheme (one-time migration, or an explicit os command an operator can run).
2. Surface the skip: when boot sync skips a package-declared set because of provenance, show it somewhere an admin can see (Setup badge / warning on the set), not only a log counter — the failure mode is "declared ≠ enforced" drifting for weeks with 403s as the only symptom.

[os-warren]

Triage: lands in packages/plugins/plugin-security (bootstrap-declared-permissions.ts) + a Setup surface → domain:services; type Bug (declared ≠ enforced: the artifact declares 49 grants, the env enforces the 41-grant first-boot snapshot, silently). Routed to the maintainer inbox: both asks touch stored-data/migration shape — human floor.

<!-- os-decision-facets -->

• platform long-term coherence: The env-authored protection is sound; the defect is the platform's own historical rows landing in that bucket with no exit. A one-time adoption path restores the [cli/plugin-security] dev 元数据物化不一致:默认权限集 insert-if-not-exists 不重物化(声明集走 upsert) #2705 reconcile intent without weakening provenance; leaving it means "declared = enforced" is permanently false for every rc→GA env.
• measured business pull: Production field report, measured on a live env — grants shipped after first boot return 403 to real users, remediation today is raw SQL. Every env upgraded along the same rc line is affected.
• AI-agent error-resistance: The current failure signal is a log counter — the exact silent-tolerance shape that lets drift run for weeks. Surfacing the skip loudly (Setup badge/warning on the set) is the contract-tightening half and looks safe under every option.
• startup scope discipline: Keep it a narrow, one-time adoption keyed on name-match + provenance-predates-scheme; do not build a general reconciliation framework.

Options: A boot-time auto-adoption of legacy rows matching currently-declared package sets (+ skip surfacing) · B explicit operator command (e.g. os meta adopt-permission-sets), no silent auto-migration (+ skip surfacing) · C document the SQL remediation only; defer.

Recommendation: B — auto-adoption on boot silently rewrites rows the classifier believes are admin-authored, and a name collision with a genuinely env-authored set would be destroyed without a trace; an operator-run command keeps the mutation explicit and auditable, and the skip surfacing makes the freeze visible either way. Confidence gap: this analysis cannot see how many envs sit on the rc→GA line, nor whether any genuinely admin-authored set shares a package set's name in the wild — the collision likelihood is what would flip B to A.

Related: #8672 (open, on-hold — org-less materialization, same file), #8692 (closed — seeder half). Not stamped target:* this round; flagged to the maintainer in the round brief instead.

---

Generated by Claude Code