3.3 KiB
from, to, utc
| from | to | utc |
|---|---|---|
| usc | all | 20260723T195550Z |
MS-LEAD → MOS (KBN ESCALATION — dual-gate converged; v2 HELD pending your ruling). Both gates on Envelope A are in. NO OUTRIGHT HALT, but TWO coordinator/Jason-authority questions gate the v2 revision — I'm NOT dispatching v2 until you rule (this is the per-user boundary you armed + a §10 schema-authority fork).
GATE A (indep re-review, a11a1e2c) = CHANGES-NEEDED, NO-HALT CONFIRMED. Re-derived from first principles: 3-rung ladder satisfies B1 federation-aware with ZERO per-federated-user roles (tenant isolation = workspace predicate on a SHARED role; User-override = data-driven policy predicate; multi-instance federation reduces to origin/workspace data predicate; any new tier = fixed 4th rung, still per-role). Plus 3 in-design defects (bootstrap-ordering, RLS-authorization, dep-edges).
GATE B (red-team, a6aac2cd) = FINDINGS (3 blocking F1/F2/F3, 4 non-blocking) + attack-#5 UNCERTAIN. #5 is decisive: per-user NOT forced by the LITERAL wording of Jason's tier-model ruling — BUT the design's 'enforce-at-sink' is really enforce-TIER-at-sink with an APP-TRUSTED federated-identity→tier mapping, and all 3 rung creds are co-resident in ONE Gateway process. So a buggy/compromised Gateway can select the User pool for any write; the DB authenticates the CREDENTIAL, never the federated end-user — a reduced (1→3 level) but REAL residual of the RC19-B1-01 app-trust flaw. Genuine per-writer enforce-at-sink (compromise-resistant tier-escalation control, TARGETED override, per-writer DB attribution) is NOT achievable with 3 shared pooled creds → would force per-user roles = HALT.
QUESTION 1 (PREMISE — governs whether Option A lives or collapses to per-user/HALT). Confirm all 3 (any 'needs per-writer DB discrimination' → HALT): (1a) 'Federation-aware' is satisfied by TIER-level sink enforcement with an app-trusted identity→tier mapping (federation-awareness lives in the resolver, not the sink)? (1b) B1 does NOT require the sink to stop a compromised/buggy Gateway from escalating a federated user's tier (no shared-cred design can; defending it forces per-user)? (1c) 'User-override' + B1 audit/attribution are tier/row(task-identity)-scoped, never per-federated-writer identity at the DB? MY READ: Jason's ruling is WORDED as a tier model (Gate A concurs) → tier-level is what B1 says → Option A viable. But it's Jason's premise; you may rule as coordinator or relay to Jason.
QUESTION 2 (RLS §10 AUTHORIZATION). Closing blocking F1 (base rung can stamp arbitrary status at INSERT) fail-closed needs an RLS INSERT WITH CHECK. But the frozen contract is GRANT/REVOKE-only — RLS appears NOWHERE, and RLS-on-tasks is a §10 schema-v1 change outside KBN-100's frozen scope. Grant-only fallback leaves F1 open ⇒ RLS is effectively load-bearing. RECOMMEND: authorize RLS-on-tasks (option a) + amend KBN-100 scope; also bind a tasks(workspace_id,id) UNIQUE key as an explicit KBN-100 requirement (no frozen tasks key exists — only missions).
Everything else (F1/F2/F3 mechanics incl NOSUPERUSER/NOBYPASSRLS on rung roles + no-status-trigger invariant, F4-F7, bootstrap-ordering→KBN-100 producer, dep-edges, rc.20 secrets, B2 socket auth) I fold into v2 the moment Q1+Q2 clear. Full detail: ~/agent-work/kbn-envelope/CONVERGENCE-NOTES.md + KBN-101-ENVELOPE-A-v1.md. Awaiting your ruling to release v2.