Activity

1. gael-obin commented on Oct 23, 2026

   

   gael-obin

   on Oct 23, 2026

   ContributorAuthor

   More actions

   Independent review: authority delivery for the hosted Robin playground

   Reviewed 22 October 2026 local / 23 October UTC. Read-only investigation; no deployment authorization or readiness claim.

   Verdict

   An existing authority path was omitted from the blocking conclusion: signed module-manifest delivery plus the Host's real, MFA-gated administrator ceiling write. The accepted handbook explicitly permits this writer and explicitly reserves tenant pinning to it. Using that public operation, with an authorized administrator and narrowly reviewed grants, is not a fixture and is not an administrator bypass. It does not make the administrator the actor for the subsequent upload/chat demonstration: that journey must still use an ordinary member and the installed modules' bounded authority.

   The closed Core proposal establishes an owner-direction conflict, not a demonstrated runtime incompatibility. CLI v0.1.202 deliberately includes the second-document implementation through its exact Core dependency; Host v0.0.105 includes its consumer. Platform-core v0.0.39 already selects that Host. The two selected Core revisions have no solutionhost/ changes between them. There is therefore existing producer/consumer source for the signed-envelope path as well. No end-to-end deployment qualification was established for it here.

   Design acceptance: accept the existing MFA administrator route as an ownership-correct alternative, conditional on installation isolation and narrow grants. Do not approve a replacement issuer, private owner patch, broad cross_tenant grant, warn-mode authority, or a new delivery document. The release-owner contradiction still needs disposition before calling the selected package combination supported for delivery.

   Implementation qualification: not qualified for Azure. The candidate does not yet declare an Azure environment; it has development frontend inputs and a known owner-version mismatch. The delivery/tenancy conflict is not proof that the intended outcome is impossible. Nor does identifying the operator route establish package readiness, release custody, installed state, or the member journey.

   Scope, independence and revisions

   I was the independent reviewer and read the complete architecture-bouncer reviewer instructions. The initial briefing and delivery-owner-reconciliation.md supplied hypotheses and source locations, not an accepted design. During this review I sent preliminary findings to the caller; its response agreed to examine the administrator alternative and confirmed no draft issue had been published. I did not read an earlier review verdict or implementation discussion, delegate, modify reviewed source, start a runtime, inspect credentials, or operate Azure.

   I inspected workspace navigation, handbook README, boundaries/composition/glossary and the affected Host/security/delivery contracts; CLI/Core ownership instructions and manifest documentation; Host root/module/deployment/Accounts instructions and relevant gateway/source contracts; and Robin root/playground instructions plus the candidate declarations. Broad initial reads produced some truncated output; consequential instructions and code were subsequently read in bounded sections. This is a focused authority-delivery review, not a complete review of every service or the candidate UI.

   Live GitHub reads used gh after tool discovery found no usable GitHub connector. No repository refs were fetched or changed.

   Input	Identity independently checked
   Handbook checkout	79b0c53922ce71476d96d1f2994943ef38fcbe09, clean
   Handbook live main	9724571ccf2b38af29f4cec7c29144e017c24540; the envelope ADR is byte-identical to the checkout (SHA-256 29ee87b790ae424eb250f1499cdf1a309188a9a18ee6f5b0416e5eecc47669ee)
   CLI checkout	cadaa1e69c64b586163738aa8e9fc47386edeb1d, existing build/pin/docs changes present and preserved; those patches are not accepted by this review
   CLI live main / release v0.1.202	c6dfaf58736cfd8b7747bdac137dd93b0d84f3e5; Core v0.19.6-0.20261022093222-5522c4dac804
   Core checkout / live main	checkout b81d92e6feda56ba22f1c354ec1eed25bf1e71fc, clean; live main 4c895ee5321580d8a8e7ca93d56d578b7fee31ed
   Host checkout / live main	55563cda2450dc293beaaaa0392763701eb54be3, clean
   Host tag v0.0.105	eab3919f9139fa77cc3157025dfe853510ac57c0; Accounts Core v0.19.6-0.20261018171306-0a8d16c5e32d
   Platform-core v0.0.39 / live main	42d592a84742bc77b263f66299323ac1c92fe003; selects Host 0.0.105, Documents 0.1.12, Model 0.1.20, Robin 0.1.29
   Candidate	Robin checkout daa50e1aad52ff10e6befe6255a859364c677127 plus existing staged/unstaged hosted-playground changes; workspace.codefly.yaml imports platform-core 0.0.39 and declares only local

   Host uses deploy-counter tags separately from GitHub Releases. gh release list misleadingly ends at v0.0.32; the tag API establishes v0.0.105. A tag demonstrates publication identity, not successful qualification.

   Findings and disposition

   1. The real administrator route is a valid alternative, with concrete limits

   The governing SP-CELL-16 permits either release-custody delivery or a platform administrator behind a second factor. The accepted ADR expressly says that pinning a principal to one organization remains an administrator's interactive write. The “emergency brake” description does not make initial writes invalid: the same public operation admits revision 1 over expected revision 0.

   The public adapter checks authentication and super_admin, then uses fresh MFA for a session. The business method independently requires the platform role, validates the complete envelope, requires revision == expected_revision + 1, and calls the shared writer. That writer preserves optimistic concurrency, transactional audit, installation revocation and witnessed narrowing. See adapter and business writer. The owner also shipped the administrator UI; I did not visually qualify it.

   This route still requires signed module manifests, pinned release custody, attested workload identity, actual organization installations and member access. GetModuleEnvelope exposes the applied manifests' requests; operators should review those owner-derived requests, not invent another grant resolver. Because PutModuleEnvelope replaces the whole host ceiling, the writer must preserve unrelated principals and re-read on conflict.

   Tenant pinning is suitable only where those principals legitimately serve that organization. Pinning shared Documents/Robin/Model principals on an existing multi-organization Host could revoke other installations. A dedicated authorized demo installation/Host or evidence that the affected principals are exclusive to this organization is therefore a prerequisite; no current Azure isolation fact was established here. Do not substitute a tenant-pinned demo for proving the general shared-module contract.

   Classification: correct existing reuse, omitted from the evidence record's alternatives. Closure: identify the authorized operator and isolated target; review exact grants and revision; qualify the real member and refusal paths. No new delivery code is justified by this finding.

   2. The signed-envelope path is implemented and packaged, but owner support is unresolved

   Core's closure explicitly drops the second-document direction. It does not prove that the branch implementation cannot operate. CLI's producer and Host's consumer merged. The later CLI dependency change deliberately preserves those symbols; released CLI go.mod and tagged Host Accounts go.mod confirm actual pins. GitHub compare 0a8d16c5e32d...5522c4dac804 reports two added commits and no changed solutionhost/ files. This is positive protocol-continuity evidence, not merely the absence of a failing test.

   However, Host's own tagged instructions call candidate Core dependencies development-only and explicitly prohibit shipping a Host release on an untagged pseudo-version. The tag contains one. The handbook also still describes the Core/Host implementation as unmerged, although Host merged and Core closed. Those are consequential support/release-policy inconsistencies, not findings of an invalid wire format.

   The smallest remedy is a joint owner disposition of the extant release chain: identify the supported CLI/Core/Host combination and qualification evidence, and reconcile the Host release guidance and handbook status. If the existing signed-envelope path is retired, its owner must provide migration and consumer disposition; neither the playground nor this reviewer can replace it with a one-document design on the strength of a PR comment. For the MFA operator route, no second signed authority document is necessary, but the shipped Host dependency/support contradiction still needs an honest disposition before a readiness claim.

   3. Tenantless delivered grants plus selectorless clients are a real conditional failure

   Host v0.0.105 moduleMintOrganization has two accepted branches: a pinned tenant (an absent selector is allowed; a different selector is refused), or cross_tenant with an explicit canonical organization UUID. A tenantless grant lacking either required shared input fails before installation authorization. Delivered envelopes refuse tenant pins.

   Thus the existing tenancy issue identifies a real failure for that combination, but its “two choices” framing is incomplete: an interactive tenant pin is an accepted third path. It also does not establish that every relevant client lacks an organization selector. Current in-flight owner work explicitly corrects an earlier SDK diagnosis: released saas-sdk-go already supports Credentials.OrganizationID; qualification/adoption is separate. The owner work remains open, and is not a released repair to assume available.

   The candidate itself delegates transport/authority to solution-runtime-go v0.0.14 and uses viewer bearer for Robin. Its source is not proof of how all selected Documents, Robin and Model module mints choose an organization. Do not infer a universal SDK gap or add an issuer/selector shim to the playground. For a shared deployment, trace each actual selected client's input and cache scope and qualify two organizations. For an isolated tenant-pinned deployment, prove the public pinned-tenant path and its refusal of another tenant.

   Classification: source-established conditional incompatibility, not blanket delivery impossibility. The Host owns mint policy; clients own correct public-contract use; the composition owns intended tenancy. Existing owner work changes the assumptions of any proposed new mint fix and must be reconciled first.

   4. A separate API-key writer conflicts with the stated two-writer guarantee

   The same tagged adapter also admits credentialKindAPIKey with exact module_envelope:write, instead of recent MFA. Its comment calls that scope the second factor's replacement. The super_admin check remains, so this is not anonymous or unrestricted access. Nevertheless a scope is neither a second factor nor the release-signed delivery carrier required by SP-CELL-16. I found no corresponding accepted exception in the targeted handbook search.

   This is a pre-existing source-established contract conflict, relevant because it is an attractive automation alternative. Do not use it to close this task. The MFA session branch remains valid; this finding does not erase it. Host/handbook owners must either restore the declared writer restriction or obtain an accepted contract change and qualify it. This limits a whole-Host security-readiness claim; it is not a request to implement a local patch during this review.

   Obligations and evidence coverage

   Obligation/scenario	Owner and implementation	Evidence and verdict
   Signed presence is independent of granted authority	Core manifest; CLI render/sign/publish; Host applied manifest and ceiling intersection	Owner docs/source traced. Correct separation; a live process or delivery receipt alone proves no installation.
   Release signature and delivery identity	CLI v0.1.202; Host v0.0.105; pinned Core verifier	Existing path and matching document implementation found. Live key custody, namespace carrier admission and Azure delivery not tested.
   Human writes only through protected public authority	Host session branch of PutModuleEnvelope	Role, MFA, expected revision and shared writer source traced. Valid alternative; API-key branch excluded because of finding 4.
   Tenant and current installation jointly bound mint	Host moduleMintOrganization, then installation authorization	Pinned path exists; tenantless selectorless path fails by source. Actual composed callers and two-organization behavior unqualified.
   Ceiling is reviewed and cannot silently revert	Host shared writer; CLI minimum_revision and prior-delivery settlement	Source and owner tests cover conflict, replay, narrowing and revision ordering. Do not publish a newer broad envelope over an intentional tenant pin; catch-up documentation cannot encode a tenant pin in a delivered document.
   Revocation survives changes of installed state/key	Host shared narrowing and envelope re-verification	Tagged owner tests include delivered-key unpinning and interactive record behavior. Tests read, not run; durable/replica/deployment behavior unqualified.
   New frontend is actually admitted and installed	CLI signed payload and Host prepared-payload/apply path	Candidate README identifies ignored development archives and incompatible Robin pin. This authority review does not close those separate release gates.
   Real ordinary-member outcome	Documents owns upload/storage/indexing; Model owns Azure provider profiles; Robin owns answer/citation	Intended owner composition is sound. No live upload, semantic readiness, inference, citation, denial or restart test performed.

   The existing tests inspected are in Host module_envelope_delivery_test.go, module_envelope_test.go, and adapter authorization tests, plus CLI publish_envelope_test.go. They exercise real verifier logic with controlled in-memory collaborators. Their presence is enforcement evidence; it is not a new passing result from this review. No tests were executed because the narrow distinction is established by declarations, tagged source, dependency comparison and live owner records, and this task did not require starting dependencies.

   Smallest next owner action

   Ask the Host/delivery owners for a bounded support disposition, not another mechanism:

   For an isolated, single-organization Azure playground, may the existing release-signed module-manifest path be paired with the public super_admin + fresh-MFA tenant-pinned ceiling operation? Name the exact supported CLI/Core/Host/base selections and qualification evidence, resolve the tagged Host's prohibition on its own pseudo-version pins, and state whether signed-envelope delivery remains supported or has a defined migration. Preserve strict enforcement, installation consent and witnessed revocation; no API-key substitution or expanded cross_tenant authority is proposed.

   That question is concrete because the public path, tagged implementations and divergent instructions are now identified. It does not require waiting for a redesigned Core document. If owners confirm this existing route, the next task is normal composition/release qualification with owner-published packages and approved Azure bindings. If they reject it, they must identify the missing guarantee and owner-supported replacement. Until then the correct status is existing compliant authority operation identified; release support and composed deployment qualification unresolved, not “no authority-delivery path exists.”

   No issue was created, no message was sent outside this review team, and no source or deployed state was changed. The only new file is this report.
2. gael-obin commented on Oct 23, 2026

   

   gael-obin

   on Oct 23, 2026

   ContributorAuthor

   More actions

   Concrete release failure identified — 23 October 2026 UTC

   The selected Host tag v0.0.105 at eab3919f9139fa77cc3157025dfe853510ac57c0 did not complete its owner publication workflow. Release run failed both Codefly SDK boundary and Codefly CI plan at Install Codefly with:

   A host release requires a qualified released Codefly pin, not a source candidate

   The mandatory release gate failed; both Publish immutable module package and Publish frontend kit to GitHub Packages were skipped. A Git tag therefore does not establish successful publication of these artifacts.

   The installer at the selected revision defaults to source revision 5234ce248b092edf1138a16ec4140dfbc8745522 and explicitly refuses source candidates for tag releases. Its source-candidate comment names lifecycle/artifact-cache qualification. The installer remains identical on current main 55563cda2450dc293beaaaa0392763701eb54be3.

   The existing owner workflow already provides frontend publication, integrity-conflict checks, a clean registry consumer check and attestations. The next action is to qualify a released CLI with the required capabilities and repair the owner's normal release path, preserving its gates. Rerunning this unchanged tag, manually publishing from a consumer, or using a package-read token for publication does not resolve it. Git ancestry alone is insufficient to select a replacement after squash merges; capability and behavior checks are required. The existing Core adoption PR remains open and is related owner work to reconcile, not a completed fix for this installer.

   Authenticated registry reads now work for the playground operator, but requested @codefly-dev/saas-sdk@0.3.35 and @codefly-dev/saas-ui@0.12.15 are absent from the accessible package indexes. That observation agrees with this skipped publication; it is not proof about every principal or publication attempt. Three other exact shared kit artifacts were acquired and integrity-verified.

   This narrows one release-readiness gap in the existing issue. It does not settle the authority/support questions above or qualify the Azure composition. No owner source, workflow, tag or cloud workload was changed.
3. gael-obin commented on Oct 23, 2026

   

   gael-obin

   on Oct 23, 2026

   ContributorAuthor

   More actions

   Native qualification repair passes; release support remains unresolved

   The bounded installer/dependency repair now passes normal native CI at candidate 55272644e11977dd584bec6d91248655811cda6b. Lint, compile, test and build each report nine passed with no skips or reused results. Sync-drift passes for six supported services, with three explicit unsupported-agent skips. Accounts and gateway audits are clean; frontend and marketing production audits each report zero vulnerabilities. Repository checks, quality and release-gates aggregates pass. The synthetic merge's tree equals the reviewed candidate tree. Publication jobs correctly did not execute on the PR.

   The repair preserves the complete existing owner security commit, including generated output and attribution. Independent source review verified the eight-file scope and found no introduced ownership violation or source defect. The draft explicitly records its overlap with the owner's existing CLI 0.1.197 transition and why it selects released 0.1.202.

   The support question in this issue is still substantive. A fresh dependency review independently confirms that Accounts selects the initial envelope commit from Core's closed, unmerged proposal, while the accepted handbook still requires that design. Current Core main is not an API-compatible replacement. Gateway's manifest implementation and SDK's matching Work Context leaf are existing owner work to release/adopt; the older Core adoption proposal does not satisfy their newer API requirements. A numerically newer SDK root maintenance tag is not evidence of a matching Work Context leaf release. The existing session/MFA-gated administrative operation remains a valid design alternative, subject to exact supported selections and installed acceptance.

   One additional pre-existing qualification gap was verified: candidate-wide tracked Go searches contain no call/import of the Core consumer conformance kit required by the selected revision. Host does use the real Core implementation and has substantive custom tests plus its real-handler SDK harness; this is a coverage obligation, not an observed runtime failure or a regression from the repair. Close it at Host by exercising the existing owner kit through the relevant public verification/inspection entrypoints, with the appropriate mode and error semantics. Preserve existing client-compatibility evidence and qualify the selected released client as well; do not create another verifier or general test framework.

   No merge, tag, registry publication, supported complete release or deployed consumer is claimed. Keep this issue open for the owner contract/release disposition, compatible selections and consumer qualification. The normal CI obstacle repaired here is now evidenced separately from those remaining obligations.
4. gael-obin commented on Oct 23, 2026

   

   gael-obin

   on Oct 23, 2026

   ContributorAuthor

   More actions

   Consumer conformance needs contract reconciliation, not only test wiring

   Follow-up to the qualification gap above: the bounded next step is more specific than adding the kit unchanged and expecting a pass. The gateway and Accounts Go trees are identical between the inspected checkout 076892833dad6df59d42ad8302cbf93c60eac26d and the qualification candidate at 55272644e11977dd584bec6d91248655811cda6b; these findings are pre-existing.

   A controlled local diagnostic ran the selected Core's unchanged conformance.RunInspector through the actual gateway wrapper, using existing JWKS test helpers and its cache factory to inject only the kit's issuer, clock and fixture-key settings. Go 1.27.3, GOWORK=off, readonly modules, no integration tag; an overlay added the diagnostic without editing the checkout. It failed with 21 assertion reports: 20 lost Core error identities and one accepted missing-route presentation. This qualifies neither the production constructor nor a deployed request path.

   • Host route integration: the wrapper substitutes the token's own audience when no permitted audience is supplied. Core's contract explicitly requires a route-derived expectation and rejects that substitution. Resolve catalog routing at Host using authoritative destination semantics, or obtain an explicit owner contract decision if those semantics cannot be represented. Do not just reject every catalog request or add a second verifier.
   • Host error integration: invalidWorkContext wraps the edge sentinel but formats the Core error with %v, losing its identity. Preserve the needed internal error semantics while retaining the existing static HTTP 401 response. Error privacy does not require dropping internal errors.Is identity.
   • Accounts qualification: its documented noApprovalGrants behavior is fail-closed. The full verifier kit expects fixture grant state and an explicit fixture-key opt-in. Test construction must exercise the actual consumer path with controlled dependencies and separately prove production defaults still refuse fixture keys and unsupported grants. Do not enable production grants, switch to weaker verification, or filter/reclassify kit fixtures to claim conformance. If no acceptable consumer test seam exists, the conformance-contract gap belongs with Core.

   The existing native-CI success remains valid for the bounded installer/security repair. It does not close these consumer contract obligations, the release-support decision, or installed acceptance. No production source, release, runtime or cloud state was changed by this diagnostic.
5. gael-obin commented on Oct 23, 2026

   

   gael-obin

   on Oct 23, 2026

   ContributorAuthor

   More actions

   The internal refusal-identity finding now has a bounded draft fix at fc68431979319587d4e9fd627bd957d1bcba7197. It preserves Core and Host error identities using standard Go wrapping and retains the static HTTP 401 response. Independent actual-source architecture review closes that finding; quick and elegance reviews found no new issue.

   Local gateway race tests pass714 test/subtest results with one explicit public-client-harness helper skip; vet, naming and boundary gates pass. The unchanged Core Inspector diagnostic now has only the separate missing-route failure, down from21 assertions. It still fails overall. Native CI has started; no full pipeline or release pass is claimed.

   The remaining route repair needs an owner-controlled audience declaration in the existing method-policy/catalog projection. Public source-operation calls consume authority at their declared audience; module exchanges authenticate projected workload tokens; issuer derivation parents are carried in request bodies, and internal read-back operations are not public catalog routes. Do not substitute one universal audience or copy a procedure list into the gateway. Trace SDK header behavior and preserve those legitimate callers when defining the change.

   This PR contains only the wrapper/test correction and remains separate from the installer/security repair. Complete consumer conformance, supported releases and installed acceptance remain open.