Publish plan: ship the VS Code extension + CLI + mobile app — decide repo/release structure first, built for easy updates

[zo-sol]

Goal

The app is getting good enough to ship. Get it to the same convenience bar as Claude Code's own delivery (CLI install + VS Code Marketplace + mobile app store), and decide the repo/release structure that makes that — and the frequent updates after launch — easy.

Reference (Claude Code's delivery surfaces, the bar we're matching):

• CLI — native installer / npm / Homebrew / WinGet, auto-updates in background
• VS Code — Marketplace extension (one-click install)
• JetBrains — Marketplace plugin
• Desktop / Web / iOS — first-party apps

Ours maps to: VS Code extension (Marketplace) + CLI (npm/installer) + mobile (App Store / Play).

Current state (publish-readiness audit)

Monorepo (pnpm-workspace: packages/* + surfaces/*). Everything is 0.0.x and not packaging-ready:

Surface	name	Blocker(s) to publish
surfaces/vscode	agentnet-vscode	no publisher, no repository/icon/description; needs a vsce package step + a Marketplace publisher account
surfaces/cli	agentnet-cli	not on the @iqlabs-official scope (name inconsistency); needs files/bin/publishConfig, README, a publish channel (npm? installer script?)
surfaces/android	appId com.iqlabs.agentnet, versionName 0.1.0	no signing config, no Play Store listing/metadata, no tests yet
surfaces/localhost, surfaces/webview	private:true	internal — not published directly (webview is bundled into the others)

Hard dependency on the rename (#36): every published name (agentnet-vscode, agentnet-cli, appId com.iqlabs.agentnet, VS Code displayName) gets locked once it hits a store/registry. Decide the name (#36) BEFORE first publish — renaming a published extension/app/npm package is painful (lost installs, redirect hassle).

Decisions to make (the discussion this issue is for)

1. Repo structure — keep one monorepo, or split?
   • Stay mono (release each surface independently from one repo — simplest, shared core stays in lockstep), OR
   • Split surfaces into their own repos once they stabilize (independent release cadence, cleaner store ownership).
   • Recommendation to debate: stay mono, release per-surface — the core SDK + surfaces evolve together; splitting adds cross-repo version juggling we don't need yet.
2. Release/versioning — independent SemVer per surface? Changesets / a release script? Tag convention? How the shared @iqlabs-official/agent-sdk version flows into each surface.
3. Publish channels per surface — VS Code Marketplace (publisher account), CLI (npm under @iqlabs-official? + a curl | bash installer like Claude Code?), mobile (App Store + Play, signing/secrets).
4. Built for easy updates (the explicit ask) — after launch this updates a lot, so:
   • CI that builds + publishes each surface on a tag (no manual vsce/npm/gradle dance),
   • an auto-update story (VS Code Marketplace auto-updates; CLI: installer self-update or npm; mobile: store review lag — design around it, e.g. keep logic in the webview/core that can ship without a binary update where possible),
   • keep the webview/core as the place most changes land so a UI/logic update doesn't always require a new store binary.

Tasks

• Settle name (Rename the project: "AgentNet" no longer fits — pick a new name + plan the repo-wide rename #36) — prerequisite.
• Decide repo structure (mono vs split) + per-surface versioning/release flow.
• VS Code: add publisher/repo/icon/categories, vsce package, Marketplace account.
• CLI: scope name, packaging meta, pick channel (npm + installer), README.
• Android: signing config, Play listing, write tests, store metadata — get to App-Store-submittable.
• CI release pipeline (build + publish per surface on tag) + auto-update story.
• Write the publish runbook in plans/ once the structure is agreed.

[zo-sol]

Android deployment/debug-build policy update from the 2026-06-26 device testing pass:

• Do not distribute or install Android debug APKs from unknown, stale, or ad-hoc sources. Use a locally rebuilt APK from current main plus the fresh android-assets-arm64 CI artifact, or a team handoff APK that includes commit SHA, CI run id, and signing SHA-1.
• Debug builds should use the team-shared debug keystore out-of-band at surfaces/android/agentnet-debug.keystore. The file is intentionally not committed because this is a public repo.
• Register the shared debug SHA-1 in Google Cloud Console for Android OAuth package com.iqlabs.agentnet:
  4A:DD:0A:EC:AB:F5:55:CE:85:5C:DE:02:ED:08:82:8C:04:1A:EC:E6
• First install after switching signing keys requires uninstall/clean reinstall (adb uninstall com.iqlabs.agentnet) because Android will reject an update signed by a different key.
• Keep release signing separate. Never use or publish the shared debug key for Play Store/release builds.

Runbook added/updated:

• plans/running-guide/android-clean-reinstall.md
• plans/running-guide/README.md