Reconcile Forgejo owner response and remaining implementation gates

Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1abf1-7e95-7141-87c9-ee78332bf790

docs/evidence/2026-11-06-forgejo-owner-continuation.md

@@ -0,0 +1,63 @@
+# Forgejo owner continuation — 2026-11-06
+
+RAPPS-WP-0016 remains active, with two of nine tasks done. The current T05
+blocker incorrectly says NetKingdom has not answered the Apps 1.3 review.
+State Hub message `5634d12a-caa5-47bd-b463-2d9685706887`, from NetKingdom on
+2026-10-23, answers C1–C3 and requests Apps implementation. This record corrects
+that dependency; it does not claim a live authentication-source deployment.
+
+## Revised C3 disposition
+
+Apps adopts the revised placement as an implementation requirement: one owner
+configuration transaction wraps the configuration change and admitted hand-over,
+with an independently reachable configuration inverse. The inverse must work
+for public clients, confidential NO_CHANGE delivery and failures before receipt
+creation. Each inverse requires a fresh authorized attended owner operation;
+the revoked hand-over session cannot authorize it. Receipt removal stays
+receipt-only. Delivery removal stays created-only and follows verified
+configuration deactivation. This supersedes the earlier proposal to put an
+unguarded Helm rollback inside delivery's `owner_remove`.
+
+Reviewed material: NetKingdom commit
+`2a9d94652485424486da3b57726a9424aca4229c`, its type-text diff, and Custodian
+`docs/changes/netkingdom-target-2026-10-17/nk48-r5-f3-implementation-r2/`
+`owner-contract-candidate.md` and `owner-backend-next.md`. This is agreement
+on placement and required behavior, not independent validation of the executable
+candidate, acceptance of new descriptor/type digests or operational admission.
+C1/C2 completion is reported by NetKingdom; exact source/digest re-review remains
+part of the later frozen package review.
+
+## Actual implementation prerequisites
+
+The current Apps Makefile's `forgejo-deploy` still includes unrelated mailer and
+secret-scan prerequisites and a normal Helm upgrade. Source inspection finds no
+real T05 `owner_apply`, `owner_remove`, configuration journal or inverse-session
+backend in Apps tools. The earlier Custodian inventory remains accurate on those
+points. A generic release invocation cannot establish an OAuth-only inverse.
+
+Before binding the owner wrapper, T05 must implement and publish:
+
+1. An exact configuration/source binding and a non-secret projection that proves
+   case-only changes while preserving local sign-in and unrelated configuration.
+2. Authenticated durable intent, post-state, inverse-attempt/outcome and recovery
+   records, including ambiguous publication/process-loss handling. The committed
+   hand-over receipt design alone is not this journal.
+3. Exclusion covering every writer to this release during mutation and inverse,
+   or an enforced attended release freeze and reconciliation path. A local lock
+   or revision check alone is insufficient.
+4. A real current owner authorization/session backend for the distinct inverse,
+   with exact operation scope and per-attempt revocation on every exit.
+
+The four-probe observer and committed hand-over/revert backend also remain T05
+work. T07/T08/T09 have source candidates, but their existing runtime, continuing
+authorization, custody and independent-admission requirements remain open.
+No synthetic authority callback or in-memory journal is accepted as an owner
+backend. No code, credential, deployment, visibility or account-link state was
+changed by this reconciliation.
+
+KEY-WP-0038-T02 still waits for the first admitted KnownSecurityCase under
+NK-WP-0048-T06. Apps T02/T03 native delivery and login/group acceptance therefore
+remain waiting. T04's later decision on local password sign-in is separate.
+The next implementation work is the four T05 backend bindings above, alongside
+the existing source/runtime admission work; another request for the already
+received NetKingdom answer is unnecessary.

workplans/RAPPS-WP-0016-forgejo-netkingdom-login.md

@@ -9,7 +9,7 @@ flavor: implementation
 owner: claude-code
 topic_slug: railiance
 created: "2026-10-08"
-updated: "2026-10-18"
+updated: "2026-11-06"
 depends_on:
   - KEY-WP-0038
 related_repos:
@@ -146,7 +146,7 @@ step, taken separately.
 id: RAPPS-WP-0016-T05
 status: wait
 depends_on: [RAPPS-WP-0016-T02]
-blocking_reason: "Waits for net-kingdom's answer to the Apps 1.3 needs-change record (the-custodian docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/owner-review-railiance-apps.json: RAPPS-1.3-C1..C3) and the re-frozen 1.3 candidate."
+blocking_reason: "NetKingdom answered C1-C3 on 2026-10-23; revised C3 placement adopted 2026-11-06. Real owner wrapper/journal, fresh inverse sessions, all-release-writer exclusion, four-probe verifier and receipt backend remain unimplemented/unadmitted. Native acceptance also waits for T02/T03 and KEY-WP-0038-T02's first KnownSecurityCase."
 priority: medium
 state_hub_task_id: "728786c9-f1f9-5983-a6a4-dea21faf67f5"
 ```
@@ -163,6 +163,17 @@ See the owner-review record for the contract.
 Acceptance: receipts produced from the live T02/T03 run validate against the
 adapters' checks with no value-bearing keys.
 
+2026-11-06 reconciliation: NetKingdom's answer is already present in State Hub
+message `5634d12a-caa5-47bd-b463-2d9685706887`. Adopt revised C3's independent
+owner configuration transaction/inverse placement, including public and NO_CHANGE
+cases and fresh attended inverse authority. This supersedes the earlier inverse
+inside delivery owner_remove. It accepts the implementation requirement, not
+new descriptor/type pins or native admission. The actual durable/session/writer
+backends and observer/store remain work; source preparation can proceed while
+native T02/T03 waits. See the [owner continuation](../docs/evidence/2026-11-06-forgejo-owner-continuation.md)
+for reviewed references, exact missing bindings and the remaining first-case
+dependency. T05 stays wait for its live receipt acceptance.
+
 ## Also in scope: stale node credential
 
 The k3s `registries.yaml` on railiance01 still holds a login for the frozen Gitea