🧪 QA test plan — VSCode first (human-run), then CLI/mobile UX parity report

[zo-sol]

Rule: a HUMAN runs every test by hand — NOT an AI. AI does the unit analysis + the surface-parity report only; the doing is manual.
Scope here = the VSCode extension. After it all passes, see the final section.
Run on devnet with a Helius key set. Each checkbox = one thing to actually click/type and confirm.

§0 — Marketplace & on-chain (individual actions)

• Search an NFT skill — keyword + Skills/Workflows tabs; results rank by supply
• Buy a skill (soulbound) — SOL deducted, button flips to "Owned", celebration fires
• Use it — the bought skill's SKILL.md lands in the skills dir and actually fires in a session ("Casting …" cue), badged origin nft (registry)
• Publish ① directly (publish page) — make-skill form: name / description / category / hashtags / image (URL and on-chain address → ◆ ON-CHAIN badge) / SKILL.md body / price in SOL (default 0.1) → mints, creator auto-owns 1
• Publish ② via the agent — in chat, tell the agent "turn this into a skill and publish it" → it mints via the publish_skill MCP tool (compare the result to ①)
• Comment on a skill (holder-gated) — write + read back
• Agent comments — the agent uses post_skill_comment / post_agent_comment via MCP
• Agent directory / profile — ranked by totalSupply; open an agent → created/owned skills + blog + comments + Buy-all
• Price shown correctly everywhere — card chip / detail / "Buy · 0.1 SOL" (0 → "Free"); buy charges the on-chain config price (client never passes it)
• Onboarding latency — after publishing (① or ②), time how long until it appears in market search (indexer re-scans ~every 5 min; record the real felt delay — if too slow, it's an improvement target)
• Skill authoring + publish: let humans AND agents write a SKILL.md and mint it (publish_item exists, no authoring path) #33 before/after — confirm both the human publish UI and the agent publish_skill work end to end

§0b — Full round-trips (buy→use→commit, and make→use→commit)

• Bought-skill round-trip: buy an NFT skill → use it on a real task → commit the result to git (use one whose output is worth committing: changelog-generator, ci-cd-pipeline-builder, etc.)
• Made-skill round-trip: author that work into a new skill → publish (① or ②) → time how long until it onboards into the market → once listed, use that skill again → commit the result to git
• Report for each round-trip: did it mint / did it appear in the market (how fast) / did it fire in a session / did it produce the expected output / was it committed

§B — Wallet, cloud & session sync

• Wallet connect / disconnect (disconnect closes all chat panels)
• Google Drive connect during onboarding + later; disconnect keeps local sessions
• Session encrypted blob is written + restored; switch storage backend
• On-chain session pointer (mysessions) written once per new session

§C — RPC onboarding (efficiency UX)

• No Helius key → market reads empty + the "add a Helius key" nudge appears
• Paste a key → stored (masked), reads work; Use default RPC clears it
• rpcStatus badge reflects devnet/mainnet + key state

§1 — RPC / indexer / gateway: are all calls efficient & routed right?

• NFT indexing → `nft-index.iqlabs.dev` (repo: https://github.com/IQCoreTeam/agentnet-nft-indexer): search / profile / reputation / price go through `indexerSource`, not raw DAS
• General fetch → `gateway.iqlabs.dev` (docs: https://gateway.iqlabs.dev/docs#/ · repo: https://github.com/IQCoreTeam/iq-gateway): code-in reads (`readCodeIn` → `/data/{sig}`) use the gateway
• Audit remaining direct DAS calls in `core/skillSource.ts` (`getAssetsByGroup`, `getAssetsByOwner`) — wasteful? can they move behind the indexer? (`getAssetsByGroup` is known to return 0 for our Token-2022 group — confirm nothing in the live path depends on it)
• No redundant/duplicate RPC per screen open (e.g. balance refetched too often)

§2 — Cross-device continuity (GitHub-based, including skills)

• On a second machine/server, clone from GitHub, connect the same wallet → it resumes
• Owned skills follow (ownership is on-chain → `injectOwned` re-installs them)
• Session resume works across the device (canonical log restored from cloud)
• Continue a real task to completion on the second machine

(light) Chat core — already used daily; just sanity-check

• send / stream / image attach / model / mode / effort / interrupt / claude↔codex tab / session new·delete·resume

Approval flow intentionally excluded here (in steady daily use).

---

➡️ After all the above passes (VSCode): CLI / mobile UX parity report

For each unit tested above, an AI produces a report (analysis only, no manual runs): does the same capability exist in CLI and mobile, and how is its UX surfaced there (or missing)? Output = a per-feature × per-surface matrix with UX notes + gaps.

[zo-sol]

Codex parity update — read-only marketplace MCP just landed (branch ui/icons-and-vscode-chat)

Two things shipped that open up the Codex side of this QA plan. Both are human-runnable now.

Commits

• f38af25 — fix(skills): normalize SKILL.md frontmatter so Codex's strict YAML loads it
• 3b7953d — feat(codex): read-only marketplace MCP tools via app-server child process

What changed for Codex

Until now the marketplace MCP tools were Claude-only (Codex got the SKILL.md prose but no tools). Codex can't take an in-process MCP object, so we wire a standalone stdio MCP server as a child process of codex app-server (via -c mcp_servers.* overrides — process-scoped, never touches ~/.codex/config.toml).

Phase 1 is READ-ONLY on purpose: only search_skills + verify_skill are exposed. The write/spend tools (buy / publish / comment / unequip) are not registered on Codex yet — so there's nothing to bypass. Trading on Codex is Phase 2, gated on routing Codex's MCP-tool approval to the skill-forge approval card.

Please test on Codex (human-run, devnet + Helius key, skill-shopping ON)

• Codex: market search via MCP — switch engine to Codex, ask "search the marketplace for a skill" → confirm it calls search_skills and returns results (parity with §0 Search).
• Codex: verify via MCP — ask it to verify a specific skill mint → confirm verify_skill returns the body + rubric (the safety scan still applies).
• Codex: write tools are absent — ask it to buy or publish → confirm it has no such tool (expected in Phase 1), i.e. it can't spend/mint.
• Codex: SKILL.md loads (YAML fix) — own pptx/docx (frontmatter with : in the description), start a Codex session → confirm they now load and fire. Before f38af25 Codex rejected them with mapping values are not allowed while Claude loaded them fine.

Unchanged / still works under any engine

• Human-UI buy/publish/comment work regardless of engine (they go through the host, not the agent's MCP).
• Claude keeps the full tool set (search/verify/buy/publish/comment/unequip) with the approval card.

Verification done (not a substitute for the manual run above)

• core 303 tests pass, tsc clean; bundle runs as node dist/mcp-stdio.js and an MCP client receives exactly [search_skills, verify_skill]; real codex mcp list shows the server enabled.

[zo-sol]

Small update: both Codex changes mentioned above are now on main, not just the feature branch.

Current landed commits:

• f38af25 — fix(skills): normalize SKILL.md frontmatter so Codex strict YAML loads it
• 3b7953d — feat(codex): read-only marketplace MCP tools via app-server child process

So the Codex QA items in the previous comment can now be tested directly from the latest main build.

Please especially verify:

• Codex can call search_skills and verify_skill
• Codex still has no buy/publish/comment/unequip tools in Phase 1
• pptx / docx now load on Codex without the old YAML parse error