feat(kernel): complete P02b-4 transactional job runtime

.claude/skills/README.md

@@ -74,6 +74,7 @@ index plus the relevant [Architecture](../../docs/architecture/) doc.
 | [add-tenant-owned-entity](add-tenant-owned-entity/SKILL.md) | Adding a `[TenantOwned]` / `[OrganizationScoped]` aggregate with EF filter + RLS migration + isolation tests. |
 | [add-mediatr-handler](add-mediatr-handler/SKILL.md) | Adding a command or query handler that participates in the MediatR pipeline (Result, FluentValidation, audit). |
 | [add-integration-event](add-integration-event/SKILL.md) | Publishing or consuming an integration event (outbox + inbox guard + Dapr topic). |
+| [add-background-job](add-background-job/SKILL.md) | Adding module-owned transactional/external jobs, delayed submissions, capacity declarations or durable recurrence through the typed H1 runtime. |
 | [add-ef-migration](add-ef-migration/SKILL.md) | Producing an EF Core migration with RLS-aware patterns and the project naming convention. |
 | [add-permission](add-permission/SKILL.md) | Registering a permission key with the closed action set and scope (Platform / Tenant / Organization). |
 | [add-feature-key](add-feature-key/SKILL.md) | Adding a `FeatureKey` / `LimitKey` to the typed registry and wiring entitlement-projection reads. |

.claude/skills/add-background-job/SKILL.md

@@ -0,0 +1,179 @@
+---
+name: add-background-job
+description: >
+  Add a module-owned transactional or external background-job definition, delayed
+  submission, or durable recurrence using LearnStack's typed scheduler and H1
+  runtime. USE FOR: job parameters/roots, prepare-execute-finalize adapters,
+  capacity declarations, recurrence manifests and their proofs. DO NOT USE FOR:
+  direct Hangfire calls, operator replay, privileged maintenance, or changing
+  runtime ownership/storage policy without its decision pass.
+---
+
+# Adding a background job
+
+## Purpose
+
+Deliver a feature's job through the existing trusted submission, ordinary
+transaction owner and retained-work boundaries. The architecture is decided in
+[ADR-0047](../../../docs/decisions/0047-transactional-background-job-runtime.md),
+with lifecycle refinements in ADR-0058/0059/0060 and known external failure policy
+in [ADR-0061](../../../docs/decisions/0061-known-external-job-failure-policy.md).
+Use [implement-task](../implement-task/SKILL.md) as the substantive entry point.
+
+## When to use
+
+- Add a feature-owned transactional or external definition and its request metadata.
+- Schedule an ordinary job or declare a code-owned recurring manifest.
+- Bind a feature's external operation port, dedicated capacity group or worker queue.
+
+## When not to use
+
+- Publish cross-module facts: use [add-integration-event](../add-integration-event/SKILL.md).
+- Change the scheduler, credential grants, transaction owner, quiescence policy or
+  native invocation contract: run the owning decision pass first.
+- Add operator replay, privileged maintenance or a cancellation/rescheduling API:
+  verify the named feature phase's accepted contract before implementation.
+
+## Inputs
+
+| Input | Required | Description |
+|-------|----------|-------------|
+| Owning feature phase/module | Yes | Confirm this is the phase that delivers the business definition. |
+| Profile and scope | Yes | Transactional/external; TenantWide/Organization. |
+| Typed parameter and request contracts | Yes | Exact module Contracts/Application types and all allowed nested requests. |
+| Queue/capacity declaration | Yes | Compatible pool; external work requires its declared capacity group. |
+| External evidence contract | External | Stable logical operation, Execute/Reconcile, known outcome and positive quiescence. |
+| Recurrence manifest | Recurring | Monotonic revision, UTC schedule, target and closed lifecycle recipient policy. |
+
+## Workflow
+
+### 1. Check the delivered boundary
+
+Read the feature roadmap and current
+[P02b-4 record](../../../docs/roadmap/phase-02b-events-auth.md#p02b-4-decision-package-2026-10-15).
+P02b-4 intentionally carries no production business definitions or recurrence
+manifests. The first feature must explicitly reconcile that infrastructure-only
+census when its own accepted phase delivers real definitions.
+
+Read the relevant [glossary](../../../docs/glossary.md),
+[Events and Outbox architecture](../../../docs/architecture/15-event-and-outbox.md),
+[Database Standards](../../../docs/standards/05-database.md#background-jobs), and
+[Observability Standards](../../../docs/standards/10-observability.md#required-metrics).
+Verify new capabilities have an owning decision rather than inventing a new entry
+path, general tenant selector or platform authority.
+
+### 2. Declare inert types and exact request metadata
+
+Use the actual contracts in
+[`SharedKernel/Jobs`](../../../backend/src/LearnStack.SharedKernel/Jobs).
+Put a sealed, init-only identifier parameter record implementing
+`IBackgroundJobParameters` in the owning `Application.Contracts`. Follow the
+payload guards for identifier types and size; custom getters, plaintext business
+content and mutable object graphs are refused.
+
+Declare the module's code-owned definition in `Application`, with its exact
+`BackgroundJobKey<TParameters>`, scope, readiness and profile. List every allowed
+root/nested request with positive `Ordinary` scope metadata. Roots belong to the
+owning Application assembly; nested cross-module work uses the existing Contracts
+mechanism. Use [add-mediatr-handler](../add-mediatr-handler/SKILL.md) and
+[add-audit-coverage](../add-audit-coverage/SKILL.md) for each actual handler.
+
+Wire declarations through the existing module/definition/infrastructure registries
+and API composition; inspect their current constructors and validation instead of
+copying a stale registration example. Verify root parameter constructors, queue
+profile, module ownership and scope before constructing any handler. Add an
+explicit retired tombstone for an intentionally retired identity; unknown and
+Pending definitions preserve work for a compatible deployment.
+Composition is explicit: preserve `BackgroundJobFrameworkRequests.All` and the
+catalog aliases when supplying feature registries. Verify the resolved API
+registry and every submitting composition root, including Seeder when applicable.
+
+### 3. Submit on the owning transaction
+
+Inject only `IBackgroundJobScheduler` into feature code. Its real methods are
+`EnqueueAsync(key, parameters, ct)` and `ScheduleAsync(key, parameters, dueAt, ct)`.
+Submit inside the existing enrolled writable module transaction. Tenant,
+organization, producer and causal metadata come from trusted enrollment; a key or
+payload cannot supply them. The returned identity does not commit the owner.
+
+Keep schedule/business changes and the job INSERT atomic. Prove commit and
+rollback, including an absorbed refusal after produced work. An org-bound context
+cannot submit a TenantWide definition by relabeling the input. Never write job
+rows, call a Hangfire client or mint routing/start/recipient receipts in a module.
+
+### 4. Implement the selected execution profile
+
+**Transactional:** use the ordinary MediatR root and its existing owner. Do not
+open another transaction, change tenant context or acknowledge the job directly.
+Completion, outbox and MUST audit remain one owned transaction.
+
+**External:** define identifier-only `IBackgroundJobPlan` and
+`IBackgroundJobOutcome` records in Contracts. Its module Contracts port inherits
+one closed `IBackgroundJobExternalOperation<TPlan,TOutcome>`; the concrete adapter
+lives in the same module's Infrastructure. Prepare/finalize are ordinary typed
+requests; Execute/Reconcile hold no business transaction or sender/service locator.
+
+Qualify stable logical-operation deduplication and positive provider/supervisor
+quiescence. A timeout, cancellation, missing process or NotFound after ExecuteIntent
+is not proof that effects stopped. Use the explicit Succeeded/Failed/Cancelled
+factories and the actual three-state failure policy. Cancelled cannot be Permanent;
+nonrepeatable outcomes are not silently retried. Preserve selected durable facts
+across restart and conflicting later reports. Finalization must not repeat Execute.
+
+Declare the module's tenant-wide `BackgroundJobCapacityGroupRegistration` through
+the infrastructure registry. Use [add-feature-key](../add-feature-key/SKILL.md) for
+any optional registered Hard `LimitKey`. An unknown external effect keeps its
+reservation; expiry, host exit or replacement never frees capacity.
+
+### 5. Declare recurrence through the existing manifest path
+
+Use `BackgroundJobRecurrenceRegistration` and its actual registry validation.
+The target belongs to the same module, accepts `BackgroundJobOccurrenceParameters`
+and matches the selected recipient scope. That input deliberately does not
+implement `IBackgroundJobParameters`; recurrence does not call the ordinary
+submission port directly.
+
+Preserve revision/hash compatibility, UTC CoalesceLatest and bounded lifecycle
+paging. Native ticks are opaque hints; the durable occurrence/recipient records
+own progress. Do not add a module tenant-list reader or a per-route scheduler loop.
+Prove duplicate/late ticks, mixed revisions, tenant/org eligibility, bounded raw
+paging and one reciprocal accepted child receipt. No recurring tick grants
+business execution authority.
+
+### 6. Validate and reconcile carriers
+
+Run [run-tests-locally](../run-tests-locally/SKILL.md) for affected Unit,
+Architecture and real PostgreSQL suites, using the nonempty/zero-skip runner.
+Use [add-integration-test](../add-integration-test/SKILL.md) for tenant/org pairs
+as `learnstack_app`; independently verify the dispatcher's narrow status grants.
+
+Exercise actual registrations and dirty controls. Include rollback, hidden/cross-org
+input, Pending/unknown identities, current/stale ownership, duplicate wakeups and
+confirmed failure versus unknown COMMIT. External definitions additionally need
+accepted-before-ACK, restart reconciliation, retained cleanup, no-effect restart
+proof and reservation retention/release. Recurrence needs actual held-control
+progress and late native duplicates, not only a mocked tick.
+
+Update the owning roadmap, module audit/permission matrices and applicable feature
+handoffs. Standards 05 owns schema/grants, Standards 10 instruments and Standards 21
+the canonical obligations. Preserve Accepted ADR bodies; new decisions follow
+[write-adr](../write-adr/SKILL.md). Commit with
+[commit-and-pr](../commit-and-pr/SKILL.md) and perform the requested review rounds.
+
+## Validation
+
+- Production registration is nonempty for the feature and matches its owner/scope.
+- Submission is atomic; execution uses the existing ordinary transaction owner.
+- Failure, uncertainty, cancellation and quiescence remain distinct in actual tests.
+- Finite registered metric dimensions contain no tenant/org/job/occurrence identities.
+- All touched rules and handoffs describe delivered behavior and actual evidence.
+
+## Common pitfalls
+
+- Treating a definition key, tick, lease expiry or cleanup timeout as authority.
+- Calling Hangfire or selecting all tenants from feature code.
+- Moving long external I/O into a database transaction.
+- Releasing capacity without verified positive completion/no-start/quiescence evidence,
+  or retrying a nonrepeatable effect.
+- Losing prior selected outcome facts while retrying finalization.
+- Inventing cancel, replace, dedup or replay semantics absent from the owning contract.

.claude/skills/add-ef-migration/SKILL.md

@@ -26,7 +26,7 @@ and survive forward-only deploy rules
 - Adding monthly partition for an append-only table (`audit_log`, future event
   tables).
 - Backfilling data alongside a schema change (use an idempotent SQL block or a
-  Hangfire job).
+  deployment-owned backfill).
 
 ## When not to use
 
@@ -44,7 +44,7 @@ and survive forward-only deploy rules
 | Module | Yes | The module's `Infrastructure` project hosts the migration. |
 | Touches RLS? | Yes | New table → yes. Column add on existing tenant-owned table → no. |
 | Destructive? | Yes | Drop, rename, type-change — requires two-step plan. |
-| Backfill? | No | If data must be populated, prefer an idempotent Hangfire job. |
+| Backfill? | No | Use an idempotent deployment-owned backfill when inline SQL is too large. |
 
 ## Workflow
 
@@ -260,9 +260,12 @@ migrationBuilder.DropColumn(name: "source_legacy", table: "enrollments");
 
 ### Step 7: Data migration
 
-Small data migrations live inline as SQL. Larger migrations live as **idempotent
-Hangfire jobs** triggered by the migration. The job sets `app.tenant_id` per tenant
-before mutating data, on the **migration** connection:
+Small data migrations live inline as SQL. Larger backfills remain idempotent,
+deployment-owned migration work under
+[ADR-0047](../../../docs/decisions/0047-transactional-background-job-runtime.md#bounded-supersessions-and-additive-seams).
+The ordinary API job runtime cannot receive migration credentials or execute this
+backfill. The migration-owned loop sets `app.tenant_id` per tenant on its own
+**migration** connection:
 
 > This loop is a migration-time backfill, not a ninth entry in ADR-0040's closed
 > eight-setter set. Application code never opens its own connection to set the

.claude/skills/add-integration-test/SKILL.md

@@ -69,8 +69,13 @@ architecture test) plus any other invariant the change touches. See
 > for a role-level or provisioning question. `SchemaFixture` builds on it and is
 > what almost every test wants: **every** migration chain applied — through
 > `MigrationChains.ApplyAllAsync`, never a list a fixture keeps itself — and every
-> table seeded for two tenants, with a second organization under tenant A. There
-> are five chains and 23 data tables (28 including migration histories). Discover
+> table populated under its role and table class, with two tenants and a second
+> organization under tenant A for tenant-owned data. There
+> are five chains and 42 data tables (47 including migration histories). Every
+> discovered public table must match an exact class in
+> [SchemaTableClasses](../../../backend/tests/LearnStack.Tests.Integration/Database/SchemaTableClasses.cs).
+> Vendor/control SELECTs as `learnstack_app` must raise `42501`; a zero count or
+> an excluded table does not prove the required denial. Discover
 > current chains and history names through
 > [MigrationChains](../../../backend/tests/LearnStack.Tests.Integration/Database/MigrationChains.cs);
 > do not copy that inventory into a fixture. Share the schema with
@@ -90,9 +95,12 @@ What the fixtures do today:
   which owns every table — and expose a connection as **`learnstack_app`** for the
   tests themselves. A test that connects as the owner or as a `BYPASSRLS` role
   passes even when every policy is inert, so it proves nothing.
-- Seed **every table for both tenants**, deliberately: a count assertion against a
-  table the fixture never populated passes whatever the policy says. That shipped
-  once, in Packet 6, and is why `SchemaFixture` fills all of them.
+- Seed **every table**, deliberately: tenant tables carry both tenants and org-scoped
+  tables also carry both organizations under A. Control/vendor tables carry nonempty
+  subjects through their confined dispatcher grants; the FORCE-RLS control tables
+  have no owner/app policy and cannot be seeded by assuming ownership bypasses RLS.
+  Tenant isolation assertions always authenticate as `learnstack_app`. A count
+  against an empty table passes whatever the policy says; that shipped in Packet 6.
 - Expose the seeded ids as `SchemaFixture.TenantA` / `TenantB` / `OrgA1` / `OrgA2`,
   and the session-variable helpers as `SchemaQueries.SetTenantAsync` /
   `SetSettingAsync` — `set_config(name, value, true)`, not `SET LOCAL`, because

.claude/skills/code-review/SKILL.md

@@ -81,7 +81,7 @@ Walk every change against the project's
 | **Tenant + organization isolation** | New tenant-owned entity has `[TenantOwned]` + EF filter + RLS policy + canonical `app.tenant_id` session var. `[OrganizationScoped]` covered the same way. Any `IgnoreQueryFilters` outside platform-admin paths is a zero-tolerance blocker per [17-code-review.md § Zero Tolerance](../../../docs/standards/17-code-review.md). |
 | **4-step auth order** | Every write use case checks in order: (1) Authn → (2) Tenant membership → (3) Role / permission → (4) Resource scope. Failure at each step returns the right Problem Details code (`unauthorized` / `tenant_mismatch` / `forbidden` / `resource_scope_violation`). Source: [11-security.md § Authorization](../../../docs/standards/11-security.md), [19-permissions.md § Enforcement Points](../../../docs/standards/19-permissions.md). |
 | **Authn / authz** | Every new endpoint has `[Authorize(Policy=…)]` or `[AllowAnonymous]` with a comment. Policy keys exist in the permission registry. Resource-scope handlers (`instructor` edits own course only) present where needed. |
-| **Tenant id from the resolved context only** | Resolved per [ADR-0036](../../../docs/decisions/0036-tenant-resolution-trusted-inputs.md): from the host lookup of the effective host, or on a platform host from validated claims confirmed by live membership; off HTTP, from the job parameters or the integration-event envelope. Never from a request body, query string, cookie or tenant header — `X-Tenant-Id` and `X-Organization-Id` are assertions that can only reject, on every hop. Check command and DTO surfaces. |
+| **Tenant id from the resolved context only** | Resolved per [ADR-0036](../../../docs/decisions/0036-tenant-resolution-trusted-inputs.md): from the host lookup of the effective host, or on a platform host from validated claims confirmed by live membership; off HTTP, from the validated authoritative job row or the integration-event envelope. Never from a request body, query string, cookie or tenant header — `X-Tenant-Id` and `X-Organization-Id` are assertions that can only reject, on every hop. Check command and DTO surfaces. |
 | **SQL injection** | EF Core LINQ or `FromSqlInterpolated`; never raw string concatenation. Raw SQL has parameters. |
 | **XSS** | No `dangerouslySetInnerHTML` outside a sanitisation wrapper; CSP nonces in place; markdown via allowlist. Nothing sets a CSP today: the [standards index](../../../docs/standards/README.md#honest-status-today) row for Security Standards carves § HTTP Headers out to [Phase 11](../../../docs/roadmap/phase-11-production-hardening.md#security), so a missing nonce is not a Blocker until that phase sets one. Accepted P02d-6 G42 requires atomic four-color validation and a fixed style element, with whole-palette fallback; output must be safe without CSP. [The accepted package](../../../docs/roadmap/phase-02d-walking-skeleton.md#p02d-6-accepted-answers) owns its proof obligations; acceptance alone is not delivery. |
 | **CSRF** | Server Actions / Auth.js session check; non-Action mutating fetches carry CSRF tokens. |