Build the exact-version Global Inbox authorization feasibility harness

[KazanderDad]

Parent Goal: https://github.com/Cubid-Me/cubid-monorepo/issues/47
Depends on: https://github.com/Cubid-Me/cubid-monorepo/issues/46
Blocks: the static-revocation proof Task and final Phase 0 validation Task

Objective

Implement an isolated, non-production, exact-version XMTP harness that creates a disposable inbox and authorizes a distinct partner installation through the recovery-controller candidate approved in the decision pack, with separate keys/databases and no central Cubid/FriendR installation.

Expected Surfaces

• A dedicated unpublished harness/example such as examples/global-inbox-feasibility/ in Cubid-Me/cubid-sdk, with its own README, pinned dependency manifest, scripts, and ignored local state.
• Exact XMTP client/signer/gateway packages and lockfile entries selected by https://github.com/Cubid-Me/cubid-monorepo/issues/46.
• Deterministic unit/integration tests for canonical action validation, one-time grant binding, signer/factor policy, local database separation, state confirmation, and failure cases.
• Redacted evidence output documenting environment/network, versions, inbox state, installation identity/hash, signer boundary, gateway choice, and inbox-update consumption.
• Branch-scoped session log required by the SDK repo before commit.

Scope

• Create a disposable non-production inbox using the approved recovery-controller candidate.
• Generate partner installation keys locally and initialize a separate local database.
• Bind authorization to the exact inbox, partner/harness identity, installation, user session/factor, nonce, and expiry where supported.
• Require the approved independent user/platform factor and demonstrate that Cubid/FriendR service material alone is insufficient.
• Confirm the resulting installation through observed XMTP state, not only local return values.
• Record installation count/update consumption and safe identifiers before and after authorization.
• Cover wrong signer/factor, wrong inbox/installation, expired or replayed grant, duplicate invocation, offline/partial failure, and gateway outage behavior supported by the pinned stack.

Non-Goals

• No production SDK API, package export, public release, hosted control plane, FriendR app change, browser integration, management UI, billing, or real-user data.
• No central installation, message proxy, message/graph indexing, or reusable general-purpose signing endpoint.
• No static revocation in this Task; that is the next child Task.

Guardrails

• Do not modify cubid-monorepo/packages/core/; public SDK and harness work stays in this repo.
• Do not commit private keys, recovery shares, database keys, payer credentials, message content, raw graph data, or reusable authorization material.
• Keep recovery-controller and gateway payer material cryptographically and operationally separate.
• Use disposable identities and an explicitly non-production XMTP environment.
• If the approved signer cannot perform the canonical action without unilateral Cubid control, stop and return no-go evidence.

Acceptance Criteria

• The harness is reproducible from documented commands with exact dependency versions.
• One disposable inbox and one distinct partner installation exist with separate installation keys and local database state.
• Authorization requires the approved independent factor; Cubid/FriendR alone cannot complete it.
• Observed XMTP state matches the requested installation and produces redacted evidence.
• Duplicate/replay behavior does not silently consume another installation/update.
• Failure and outage cases do not corrupt local state or create an unapproved replacement installation.
• Tests and logs prove prohibited secrets/data are not persisted or emitted.

Validation Plan

• Run the repo's install, lint, typecheck, and test commands plus the dedicated harness command on the pinned non-production network.
• Repeat authorization from clean local state and from an interrupted/retry state.
• Inspect local storage boundaries and safe before/after network state.
• Scan tracked files and captured logs for secrets and prohibited data.
• Record exact commands/results, commit hash, changed files, network/environment, and safe evidence in the issue comment.

Stop Condition

Stop after the authorization harness, tests, README/evidence, and SDK branch session log are committed on the shared Feature branch and the issue contains implementation evidence. Do not start static revocation or choose the next Task; the orchestrator will run independent validation first.

[KazanderDad]

Vetting addendum

Implementation worktree

• Repo/base: Cubid-Me/cubid-sdk from origin/main
• Branch/worktree: codex/global-inbox-phase0 at /Users/botmaster/src/cubid/cubid-sdk-44-global-inbox-phase0
• Fetch origin/main before creating the worktree; reuse it for Prove static Global Inbox installation revocation without a local client database #34.
• Registry owner: Feature #44. No separate worktree or backup branch.

Code/docs/tests expectation

• Add isolated, unpublished harness code, exact-version dependency/config updates, deterministic tests, and a redacted README/evidence path.
• Add stable scripts named global-inbox:check, global-inbox:test, and global-inbox:authorize (or document vetted equivalents before implementation).
• Do not export the harness from the public package or publish a release.

Validation and smoke

• npm ci
• npm run build
• npm run global-inbox:check
• npm run global-inbox:test
• npm run global-inbox:authorize
• git diff --check
• Manual smoke: from clean disposable state, authorize exactly one partner installation, verify observed XMTP state and separate database custody, retry/replay once, and confirm no extra installation/update is consumed.
• UI visual evidence: N/A.

Issue Validator

After implementation, local validation, session-log update, and commit, run $issue-validator before moving this Task to In Review. Provide issue/parent URLs, commit, worktree, changed files, commands/results, smoke evidence, safe state identifiers, and non-goals. The validator checks authorization binding, factor enforcement, custody separation, replay/idempotency, failure behavior, secrets/log scans, and docs/tests. Output pass, pass-with-notes, or fail to the orchestrator and comment here. On fail, fix and revalidate #33 before #34 begins.

Stop condition: commit with the SDK repo session log, post evidence, run the validator, and stop before static revocation.