feat(identity): enforce live scoped authorization and trusted evidence

.claude/skills/add-mediatr-handler/SKILL.md

@@ -257,32 +257,33 @@ See [add-audit-coverage](../add-audit-coverage/SKILL.md).
 
 ### Step 5: Permission policy
 
-> **Not wired yet.** No `IPermissionRegistry`, `registry.Tenant(...)` or `Roles`
-> catalogue exists in `backend/src`, `LearnStack.Api` registers no authorization
-> middleware, and `AuthorizationBehavior` passes every request through; the catalogue
-> lands with the Identity module in
-> [Phase 03](../../../docs/roadmap/phase-03-identity-admin.md). Until then this step's
-> registration, Step 7's `[Authorize(Policy = …)]` and the `403` check under
-> § Validation have nothing to bind to. A module's `permissions.md` is a forward
-> declaration, a handler with no HTTP route stands on reachability, as
-> [the Tenancy permission matrix](../../../docs/modules/tenancy/permissions.md)
-> records, and an anonymous endpoint carries `[AllowAnonymous]` with its reason
-> ([Permissions Standards § HTTP endpoints](../../../docs/standards/19-permissions.md#http-endpoints)).
-
-The endpoint that invokes this handler is guarded by
-`[Authorize(Policy = "enrollment.enrollment.write")]`. Register the permission in
-the module:
-
-```csharp
-registry.Tenant(
-    key: "enrollment.enrollment.write",
-    description: "Create or update enrollments",
-    defaultGrants: [Roles.TenantAdmin, Roles.OrgAdmin]);
-```
-
-`Roles.*` references come from the **Built-in Roles** catalogue authoritative
-at [19-permissions.md § Built-in Roles](../../../docs/standards/19-permissions.md).
-Do not invent role names; pick from that table or extend it via PR.
+Declare the exact request through the module's `IOperationPolicySource`, using
+the existing scoped `PermissionDefinition` and the admitted `OperationPolicy`.
+`OperationPolicyCatalog` freezes those declarations independently of stored Role
+grants. Registration grants nothing and seed reruns never adopt new permissions.
+There is no `registry.Tenant`, generated `Roles` facade or implicit default grant.
+
+The canonical `AuthorizationBehavior` delegates to the scoped operation
+coordinator at step 5, with its mandatory denial-evidence barrier. The unchanged
+eight-step pipeline registers that owner and its frozen catalogue directly;
+there is no staged replacement behavior. Unknown application requests default
+deny before handler construction. Public, AccountSite and finite seed/event/job
+classifications have different ceilings; none grants an implicit general
+exception, and a SystemActor UUID supplies no bypass. Protected application
+dispatch performs a fresh permission check independently of any earlier HTTP or
+resolver result. The [phase Status block](../../../docs/roadmap/phase-03-identity-admin.md)
+owns qualification and review state; registration or an attribute alone proves
+no HTTP coverage.
+
+Tests of authorization must use the canonical registered behavior and actual
+source owner for their subject. Do not replace its DI descriptor, restore a
+pass-through adapter or treat a test-only policy as a production permission.
+
+When an HTTP operation is admitted, bind its exact application request metadata
+and the named ASP.NET requirement generated from that canonical policy. Preserve
+the [four-step authorization order](../../../docs/standards/11-security.md#live-authorization-contract)
+and prove unknown/missing/conflicting declarations deny. Keep initial templates
+and explicit grant adoption separate from definition composition.
 
 See [add-permission](../add-permission/SKILL.md).
 
@@ -311,7 +312,8 @@ Endpoint controllers are thin:
 public sealed class EnrollmentsController(ISender mediator) : ApiControllerBase
 {
     [HttpPost]
-    [Authorize(Policy = "enrollment.enrollment.write")]
+    [Authorize(Policy = "LearnStackOperation:enrollment.enrollment.create")]
+    [OperationPolicy(typeof(CreateEnrollmentCommand))]
     public async Task<IActionResult> Create(
         [FromBody] CreateEnrollmentRequest body, CancellationToken ct)
     {
@@ -321,6 +323,11 @@ public sealed class EnrollmentsController(ISender mediator) : ApiControllerBase
 }
 ```
 
+This illustrates an already admitted operation whose module source uses policy
+id `enrollment.enrollment.create`; it does not register that policy or license a
+new endpoint. Use the current API classifier/requirement mapping and its exact
+source census, rather than copying a policy string without its source.
+
 ## Validation
 
 - `dotnet build` and `dotnet test` pass.

.claude/skills/add-permission/SKILL.md

@@ -3,7 +3,7 @@ name: add-permission
 description: >
   Register a new permission key in a module — closed action set
   (`read | write | delete | admin`), explicit scope (Platform / Tenant /
-  Organization), default role grants, matrix entry, and `[Authorize(Policy = …)]`
+  Organization), finite grant manifests, matrix entry, and `[Authorize(Policy = …)]`
   on the relevant endpoint. USE FOR: adding a permission for a new resource,
   splitting an existing resource into separate read/write capabilities, or
   promoting a "platform admin only" gate into a tenant-scoped permission. DO NOT
@@ -16,16 +16,21 @@ description: >
 
 ## Purpose
 
-Add a permission to the module's
-[IPermissionRegistry](../../../docs/standards/19-permissions.md) using the closed
-naming convention, register it on the right endpoint, and update the per-module
-permission matrix.
-
-> **Not wired yet.** `IPermissionRegistry`, `IModule.RegisterPermissions` and the
-> `Roles` catalogue land with the Identity module in
-> [Phase 03](../../../docs/roadmap/phase-03-identity-admin.md); none exists in
-> `backend/src`. Until then only Step 1 and Step 5 apply, as a forward declaration on
-> [the Tenancy precedent](../../../docs/modules/tenancy/permissions.md).
+Add an explicitly scoped definition through the module-owned source described in
+[Permissions Standards](../../../docs/standards/19-permissions.md), bind the
+admitted operation and update its matrix. Registration grants no Role authority.
+
+> **Current implementation boundary.** P03-1 supplies `PermissionDefinition` and
+> the retained `IdentityFoundationManifest.Version1` with actual seed consumers.
+> Jointly Accepted ADR-0076/0077 select the
+> [live contract](../../../docs/standards/19-permissions.md#live-permission-enforcement-contract);
+> live policy/evaluator and grant-edit/adoption commands are implemented. The
+> [Phase 03 Status block](../../../docs/roadmap/phase-03-identity-admin.md) owns
+> current qualification and review state; the
+> [phase decision register](../../../docs/roadmap/phase-03-identity-admin.md#the-decision-register)
+> owns gate state. No `IModule` registration API or generated Roles facade is
+> implied. Read the current source and accepted operation contract before coding;
+> do not introduce a module loader to match an illustrative sketch.
 
 ## When to use
 
@@ -50,7 +55,7 @@ permission matrix.
 | Permission key | Yes | Dotted `{module}.{resource}.{action}`, snake_case multi-word resources. |
 | Scope | Yes | `Platform` / `Tenant` / `Organization`. |
 | Description | Yes | One short sentence shown in Studio's role editor. |
-| Default role grants | Yes | Which built-in roles get this on tenant provisioning. |
+| Initial/adopted grant manifest | Yes | Explicit finite version; registration and seed reruns grant nothing to existing Roles. |
 
 ## Workflow
 
@@ -83,56 +88,40 @@ Rules:
 
 ### Step 2: Register in the module
 
-In `<Module>.Application/<Module>Module.cs`:
+Declare `(PermissionScope, PermissionKey)` through the admitted module definition
+source. The current value-type shape is:
 
 ```csharp
-public void RegisterPermissions(IPermissionRegistry registry)
-{
-    registry.Tenant(
-        key: "enrollment.course_access.read",
-        description: "View entitlements",
-        defaultGrants: [Roles.TenantAdmin, Roles.OrgAdmin, Roles.Instructor]);
-
-    registry.Tenant(
-        key: "enrollment.course_access.write",
-        description: "Grant or revoke entitlements",
-        defaultGrants: [Roles.TenantAdmin]);
-
-    registry.Organization(
-        key: "enrollment.enrollment.write",
-        description: "Create or update enrollments (org-scoped)",
-        defaultGrants: [Roles.OrgAdmin, Roles.OrgInstructor]);
-}
+new PermissionDefinition(PermissionScope.Organization, "enrollment.enrollment.write");
 ```
 
-`registry.Tenant(...)` / `registry.Organization(...)` / `registry.Platform(...)`
-declare scope explicitly; the three registries are disjoint, asserted at seed.
+This example registers nothing by itself. The same key at Tenant and Organization
+scope is two distinct definitions; Platform definitions cannot enter tenant Role
+grants. Unknown/inactive pairs authorize nothing.
 
-`Roles.*` references come from the **Built-in Roles** catalogue authoritative
-at [19-permissions.md § Built-in Roles](../../../docs/standards/19-permissions.md)
-(`TenantAdmin`, `Instructor`, `Learner`, `Guardian`, `Editor`, `OrgAdmin`,
-`OrgInstructor`, `PortalPublic`, `HubOperator`, `PlatformAdmin`). Do not invent
-role names; pick from that table or extend it via PR + standard update.
+Pick the template/capability from the canonical
+[Built-in Roles](../../../docs/standards/19-permissions.md#built-in-roles).
+Keep definition composition separate from finite initial grants and explicit
+adoption. Never extend retained v1 seed grants or the immutable admin kernel by
+editing a registration's defaults. A new assignable pair also needs the actual
+database registry guard/migration and approved grant contract before its writer.
 
 ### Step 3: Apply to the endpoint
 
-```csharp
-[ApiController]
-[Route("enrollments")]   // the versioned prefix is the convention's, not yours
-public sealed class EnrollmentsController : ControllerBase
-{
-    [HttpGet]
-    [Authorize(Policy = "enrollment.enrollment.read")]
-    public Task<IActionResult> List(...) => ...;
-
-    [HttpPost]
-    [Authorize(Policy = "enrollment.enrollment.write")]
-    public Task<IActionResult> Create(...) => ...;
-}
-```
+Bind the endpoint to the admitted named ASP.NET policy and exact application
+request policy from the actual composition source. Scoped pair identity is
+explicit: a same-key Tenant/Organization pair is not one permission. Do not
+infer a functioning evaluator from an attribute; use the registered evaluator
+and policy APIs. Unknown, missing or conflicting classifications deny
+at runtime. Application step 5 repeats the policy on direct/nested dispatch.
+
+Public and special AccountSite classifications retain their independent
+HostScope/physical mode boundaries. Platform and additional human-facing
+operations remain gated by their owning phase; this workflow grants no route.
 
-The 4-step auth order ([11-security.md § Authorization](../../../docs/standards/11-security.md))
-runs automatically:
+The admitted surface must prove the 4-step auth order
+([11-security.md § Authorization](../../../docs/standards/11-security.md));
+an attribute alone does not install it:
 
 1. Authentication (valid JWT).
 2. Tenant membership (Membership exists in resolved tenant).
@@ -141,23 +130,15 @@ runs automatically:
 
 ### Step 4: Resource scope (when needed)
 
-For "instructor edits only own courses", add an authorization handler:
-
-```csharp
-public sealed class CourseOwnedByActorHandler
-    : IAuthorizationHandler<CourseOwnedByActorRequirement, Course>
-{
-    public Task HandleAsync(AuthorizationHandlerContext ctx, ...)
-    {
-        if (resource.OwnerId == ctx.Actor.UserId) ctx.Succeed();
-        return Task.CompletedTask;
-    }
-}
-```
+Use the admitted application-layer resource policy after capability admission
+and visible-scope lookup. A missing or foreign-scope resource is masked 404; a
+visible resource failing ownership is 403. The application policy consumes the
+trusted actor and exact resource facts; module code acquires no ASP.NET types.
 
-The application-layer policy class combines with the permission key:
-permission grants the **capability** (`education.course.write`), policy decides
-**on which rows** (own course only).
+[Security's live policy contract](../../../docs/standards/11-security.md#live-authorization-contract)
+owns this ordering. Declared tenant-wide reads use the immutable
+[operation witness](../../../docs/standards/05-database.md#operation-bound-read-authority),
+never a header/body Boolean, Role name or cleared organization write scope.
 
 ### Step 5: Update the matrix
 
@@ -167,8 +148,8 @@ Open `docs/modules/<module>/permissions.md`. Add a row:
 | Entitlement | ✓ | ✓ | – | – | tenant-admin: read+write; instructor: read |
 ```
 
-Legend: ✓ = exists, – = N/A. The "Default role grants" column summarises
-`defaultGrants` from the registration call.
+Legend: ✓ = exists, – = N/A. The "Default role grants" column names the approved
+finite initial manifest; it does not promise automatic grants on upgrade/rerun.
 
 ### Step 6: Tests
 
@@ -189,22 +170,27 @@ Plus, for org-scoped permissions, a cross-org test:
 
 ```csharp
 [Fact]
-public async Task Cross_org_actor_within_same_tenant_is_403() { ... }
+public async Task Cross_org_actor_is_refused_without_disclosure() { ... }
 ```
 
-Architecture test `Permission_Registry_Has_DeniedTest` ensures every registered
-key has at least one denied test.
+Use the admitted surface's masking/denial contract for exact status assertions;
+foreign resource scope and a visible ownership denial are different controls.
+The canonical obligation `Permission_Registry_Has_DeniedTest` requires actual
+denied coverage; verify its current catalogue status and nonempty subjects.
 
 ## Validation
 
 - `dotnet build` and `dotnet test` pass.
-- The permission is visible in `IPermissionRegistry` (assert via a one-off
-  startup-test).
+- The exact scoped pair is in the admitted composition source; a missing or
+  inactive definition denies, and registry additions do not mutate stored grants.
 - The endpoint rejects unauthenticated, wrong-tenant, and wrong-permission callers
   with the right status codes.
 - The permission appears in `docs/modules/<module>/permissions.md`.
-- The architecture tests `Permission_Keys_Match_Convention` and
-  `Permission_Scope_Matches_Resource_Scope` are green.
+- Check `Permission_Keys_Match_Convention`,
+  `Permission_Scope_Matches_Resource_Scope` and
+  `Permission_Registry_Has_DeniedTest` against their current catalogue status.
+  Their P03-2 controls are Registered at acceptance; run the actual implemented
+  owners before claiming green, and never promote an absent proof.
 
 ## Common pitfalls
 
@@ -213,13 +199,12 @@ key has at least one denied test.
 - **Skipping scope.** A `Tenant`-scope permission checked against an
   `[OrganizationScoped]` resource without an org test is a bug; the matching
   architecture test catches it.
-- **Hard-coding the key string in policy code.** Use the generated catalogue
-  (`Permissions.Education.Course.Write`); typos in raw strings silently pass at
-  compile time.
+- **Duplicating key strings.** Reuse the owning compiled definition/constants;
+  do not invent a generated catalogue that is not present in the source.
 - **Frontend-only check.** Hidden buttons are not security. Every UI permission
   check has a server-side counterpart.
-- **Storing the permission in Keycloak.** Keycloak handles authentication, not
-  LearnStack authorization. Permissions live in `IPermissionRegistry` only.
+- **Storing the permission in Keycloak.** Keycloak handles authentication;
+  LearnStack's admitted definition/Role contracts own application authorization.
 - **Renaming an existing key.** A rename without a deprecation window
   invalidates every role assignment in the wild. Renaming is a deprecation cycle
   (one release with the old key warning-logged), not an in-place edit.

.claude/skills/local-dev-setup/SKILL.md

@@ -132,21 +132,49 @@ installed deployment authority, following
 [Identity deployment](../../../docs/modules/identity/README.md#global-implementation-and-deployment).
 Authority qualification is mandatory before the API accepts requests.
 The dispatcher credential belongs only to the API; every Seeder invocation uses
-an explicit application-only environment, and the web launcher receives neither
+an explicit application-role runtime environment, and the web launcher receives no
 database credential. Both empty hop lists remain
 valid in every mode; a network-only or secret-only configuration is refused.
 The application connection must name `learnstack_app`; the data-source guard also
 refuses direct or transitive BYPASSRLS/superuser access. Migration credentials
 never enter either application launch recipe.
 
+**P03-2 source configuration.** The confined authorization/
+evidence sources use the same application role, not new credentials or roles.
+[Standard 05's source ledger](../../../docs/standards/05-database.md#authorization-and-evidence-source-ledger)
+owns the coupled backend configuration pair, Development-only direct-PostgreSQL
+derivation and explicit non-Development requirement;
+[Standard 12](../../../docs/standards/12-infrastructure.md#authorization-and-evidence-topology)
+owns operational topology. Startup qualifies the installed authority and actual
+database identity before admitting source use. Owned seed/demo runtime children
+receive the selected authority and connection pair, with the existing
+`Deployment__Mode=Development` for their direct local stack; their restore/build
+and manifest children receive no runtime authority or database credentials.
+The Seeder shares one process-owned evidence source across per-act providers.
+Direct CLI use must supply the authority pair and explicit auxiliary pair unless
+explicit Development permits supported direct-PostgreSQL derivation; the tool
+does not load `.env`. Follow [seed-tenant](../seed-tenant/SKILL.md) for its exact
+startup contract. Do not expose these values to the web, silently accept a
+partial pair, or mistake extra client pools for PgBouncer backend reservation.
+The local API configuration loader selects a complete explicit process
+authorization/evidence pair atomically over the selected root-file pair.
+When both process keys are absent, the root-file pair is used. Partial, empty or
+whitespace process values refuse before the API child starts; sources never fill
+one another's missing partner. The constructed runtime preserves selected strings
+exactly and imports neither partner from its ambient prerequisite environment.
+The owned demo separately retains its selected-stack conflict check: explicit
+process values cannot disagree with values present in its selected private file.
+The phase Status block owns current qualification and review state.
+
 **`make migrate` runs as `learnstack_migration`, not as the API's role.** From
 Phase 02a Packet 6 the stack provisions four database roles on the first boot of
 a fresh `postgres-data` volume
 ([ADR-0003 Amendment 3](../../../docs/decisions/0003-tenant-isolation-defense-in-depth.md)):
 `learnstack_migration` owns every table, `learnstack_app` is what the API
 connects as, and `learnstack_platform` / `learnstack_outbox_admin` hold audited
-bypasses. Four roles, four passwords, four connection strings — all in
-`.env.example`, and none of them interchangeable. Running migrations as the
+bypasses. The four roles/passwords and baseline connection strings are in
+`.env.example`, and their privileges are not interchangeable. The accepted
+P03-2 application-role sources do not expand this role set. Running migrations as the
 runtime role would make it the table owner, which is the arrangement
 `FORCE ROW LEVEL SECURITY` exists to defeat.