Document OpenCode Go multi-workspace decision

[steipete]

Summary

• records the unresolved product and data-contract choices for Feature Request: Support multiple OpenCode Go workspaces under a single account #1626
• recommends automatic workspace fan-out with shared credentials and stacked cards
• defines failure isolation, manual override behavior, proof requirements, and acceptance tests
• blocks workspace-name persistence until an authenticated response contract is proven

Evidence

• OpenCode documents Go subscriptions at workspace scope: https://dev.opencode.ai/docs/go/
• current main discovers workspace identifiers but selects one, stores one override, and projects one snapshot
• an existing Chrome session was checked without exposing cookies or account data; the public server function remains reachable but the session is signed out, so it cannot prove workspace-name fields
• active PR Make weekly usage parsing optional for OpenCode Go #1788 overlaps the parser/snapshot implementation surface; this PR changes documentation only

Recommendation requested

Approve automatic all-workspace fan-out with stacked cards and a single-workspace override, or choose settings-based selection. This is intentionally a draft and should not merge as an implementation decision without maintainer sign-off.

Verification

• make check
• make test — all 44 shards passed
• autoreview — clean, no accepted/actionable findings
• packaged current-main CLI config validation — passed

No UI behavior changed, so there is no implementation screenshot. The brief specifies the redacted live proof and packaged screenshot required for the eventual implementation.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed July 1, 2026, 4:11 AM ET / 08:11 UTC.

Summary
Adds a 95-line markdown decision brief under docs/superpowers/specs for OpenCode Go multi-workspace usage, recommending automatic workspace fan-out while requiring maintainer approval and live proof before implementation.

Reproducibility: not applicable. this is a docs-only product-decision PR, not a bug report. Source inspection does confirm the underlying OpenCode Go feature request still maps to current main’s single-workspace fetch and snapshot model.

Review metrics: 1 noteworthy metric.

• Docs-only surface: 1 added markdown file, 95 additions, 0 deletions. The diff is reviewable as a decision brief and does not change runtime behavior, dependencies, scripts, or persisted settings.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🌊 off-meta tidepool
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• none.

Risk before merge

• [P1] Merging the brief could be read as approving automatic fan-out before maintainers explicitly choose between automatic fan-out and settings-selected workspaces.
• [P1] The workspace display-name response contract is still unproven, so future implementation must not persist names without redacted authenticated proof.
• [P1] The implementation should wait for the overlapping parser/snapshot work at Make weekly usage parsing optional for OpenCode Go #1788 to resolve before changing runtime code.

Maintainer options:

1. Decide the mitigation before merge
   Use this PR as a maintainer-reviewed planning artifact only if maintainers choose the OpenCode Go workspace direction; land runtime support later with redacted live proof, focused parser/menu tests, and compatibility around the existing single-workspace override.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

• [P2] The PR is owner-authored, draft, and explicitly asks for maintainer product/data-contract choice, so the next action is human review rather than automated repair.

Security
Cleared: The patch adds only a markdown decision brief and does not change executable code, dependencies, scripts, secrets handling, or provider authentication.

Review details

Best possible solution:

Use this PR as a maintainer-reviewed planning artifact only if maintainers choose the OpenCode Go workspace direction; land runtime support later with redacted live proof, focused parser/menu tests, and compatibility around the existing single-workspace override.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a docs-only product-decision PR, not a bug report. Source inspection does confirm the underlying OpenCode Go feature request still maps to current main’s single-workspace fetch and snapshot model.

Is this the best way to solve the issue?

Yes for documenting the decision before implementation, but not as a final solution to the linked feature request. The maintainable path is to approve or revise the product contract first, then implement against the final parser/snapshot shape after overlapping work resolves.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against d3f2d6433026.

Label changes

Label changes:

• add P3: This docs-only decision brief concerns a low-risk provider feature direction rather than a broken runtime workflow.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: Real behavior proof is not required because this PR only changes files under docs/.

Label justifications:

• P3: This docs-only decision brief concerns a low-risk provider feature direction rather than a broken runtime workflow.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: Real behavior proof is not required because this PR only changes files under docs/.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its guidance for docs, provider data siloing, focused validation, and avoiding live cookie/Keychain probes informed this review. (AGENTS.md:1, d3f2d6433026)
• PR metadata: GitHub reports this PR as draft, owner-authored by steipete, cleanly mergeable, and limited to one added docs file. (78e85fc55088)
• PR diff: The patch adds docs/superpowers/specs/2026-07-01-opencode-go-multi-workspace-decision.md with Status: needs maintainer decision and an explicit request to choose the workspace fan-out direction. (docs/superpowers/specs/2026-07-01-opencode-go-multi-workspace-decision.md:9, 78e85fc55088)
• Current main fetches one workspace: Current main normalizes a single override or fetches one workspace ID, then requests usage for that single workspace. (Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoUsageFetcher.swift:130, d3f2d6433026)
• Current main selects first discovered workspace: Workspace discovery parses candidate IDs but returns ids[0], so current main does not fan out across all workspaces. (Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoUsageFetcher.swift:336, d3f2d6433026)
• Current snapshot is scalar: OpenCodeGoUsageSnapshot stores scalar rolling, weekly, monthly, balance, and reset fields without a workspace list or workspace identity dimension. (Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoUsageSnapshot.swift:3, d3f2d6433026)

Likely related people:

• steipete: Current-main blame points the single-workspace fetch/projection lines to the v0.37.2 consolidation commit, and history also shows workspace dashboard behavior work by this account. (role: recent area contributor and PR author with owner context; confidence: high; commits: f380287041b8, 61177d789088, 78e85fc55088; files: Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoUsageFetcher.swift, Sources/CodexBar/Providers/OpenCodeGo/OpenCodeGoSettingsStore.swift, docs/superpowers/specs/2026-07-01-opencode-go-multi-workspace-decision.md)
• Ratul Sarna: Git history shows the original OpenCode Go provider support introduced the fetcher, settings, snapshot, descriptor, and parser-test surface this decision brief discusses. (role: introduced behavior; confidence: medium; commits: 31bd4812d227; files: Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoUsageFetcher.swift, Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoUsageSnapshot.swift, Sources/CodexBar/Providers/OpenCodeGo/OpenCodeGoProviderImplementation.swift)
• sopenlaz0: Recent OpenCode Go local usage work touched the provider descriptor, usage fetcher, and focused tests near the same implementation surface. (role: recent adjacent contributor; confidence: medium; commits: 7754035e6bb5; files: Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoUsageFetcher.swift, Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoLocalUsageReader.swift, Sources/CodexBarCore/Providers/OpenCodeGo/OpenCodeGoProviderDescriptor.swift)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.