verify-megha

---

name: verify-megha description: "Prove a megha change works on its real surfaces: drive the ACP agent the way T3 Code does (read-only by default, real cloud turns only on krida), run it inside a real T3 thread through the codexCloud and claudeCloud providers, and check the site in Chrome at 390 and 1440 px in light and dark. Use before saying any change to packages/megha or apps/site is done, and when a cloud thread or the site looks wrong."

Verify megha

megha has two surfaces. Pick by what changed; a change to both needs both.

• The agent (packages/megha): a stdio ACP process. T3 Code spawns one per thread as node.exe <checkout>\packages\megha\index.mjs --backend codex|claude with cwd = the thread's repo. Three levels, cheapest first: the read-only ACP drive, a real cloud turn over ACP, a real T3 thread.
• The site (apps/site): one Next.js page. Run it on this checkout's port and check it in Chrome.

The feature map in features/README.md lists every user-facing feature and how to drive it. Read the feature file for what you changed before driving; a proof covers every entry point its file lists.

Cost rules

• Read-only is free. initialize, session/new, set_config_option, session/list and session/load create nothing in either cloud. Use them freely.
• A cloud turn costs the user's quota. Run one only when the change is in the prompt/turn path (prompt, follow-up, cancel, steer, slash commands, streaming, diffs). Always on the krida repo (C:\Users\kaust\OneDrive\Documents\dev\krida, Codex environment labelled krida), always a read-only prompt that ends "Do not change any files.", always with "Apply diff locally" off. One turn per backend per proof, not a loop.
• Never touch ~/.codex/auth.json or ~/.claude/.credentials.json beyond what megha itself reads. When a login has expired, tell me to run codex login status or claude auth status; refreshing the tokens yourself logs the CLI out.

Doctor

Run first, and again whenever anything looks off. All read-only.

bun run doctor                                  # deps vs bun.lock, node, git, both logins, gh, PORT, origin/main
node packages/megha/index.mjs doctor            # the agent's own view: node, git, both logins, data dir

A login line marked FAIL blocks only that backend. The Claude token lives about an hour; if it expired mid-run, the drive fails at session/new with a login message.

Known doctor gap: the PORT check test-binds 127.0.0.1 only, and Next listens on 0.0.0.0/[::], so on Windows it reports a port free while a dev server is on it (seen 2026-10-14). Before using a port, confirm nothing answers: curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:<port>/ must print 000.

The agent over ACP

There is nothing to keep running: each drive spawns its own agent from this checkout and tears it down.

node .agents/skills/verify-megha/scripts/acp-drive.mjs --backend codex            # read-only: initialize, session/new, session/list
node .agents/skills/verify-megha/scripts/acp-drive.mjs --backend claude
node .agents/skills/verify-megha/scripts/acp-drive.mjs --backend codex --load <task_e_...>    # replay a cloud task (read-only)
node .agents/skills/verify-megha/scripts/acp-drive.mjs --backend codex --allow-cloud-task \
  --prompt "In two sentences, what does src/main.tsx render? Do not change files."           # ONE real turn on krida
node .agents/skills/verify-megha/scripts/acp-drive.mjs --backend claude --steps <file.json>   # custom sequence

• It sends T3's exact initialize, answers permission requests like T3's read-only test (allow read/search/fetch, reject the rest), and points MEGHA_DATA_DIR at a throwaway folder so the session store the live T3 threads use (%LOCALAPPDATA%\megha) stays untouched. --shared-data opts out, for bugs that need the real store.
• --prompt first sets apply=off and, on Codex, the krida environment and Ask mode. The script refuses session/prompt without --allow-cloud-task or outside krida, except a prompt that is exactly /status or /open (they only read the task): --load <id> --steps .agents/skills/verify-megha/steps/load-status.json replays a task and runs both, for free.
• Ready/healthy: every step prints ok and the last line is PASSED evidence: <dir>. Exit 1 on a failed step or any non-JSON line on stdout (stdout is the protocol; a stray log line breaks T3).
• Steps files: a JSON array of {method, params, notify, async, waitMs, timeoutMs, expectError}; "$sessionId", "$cwd" and "$loadId" (the --load value) are filled in. async sends without waiting, which is how to race a cancel or a steer against a running prompt. Examples are in the feature files.
• Also available, unchanged: bun run --filter t3-megha smoke (read-only, both backends, uses the shared data dir), node packages/megha/test/e2e.mjs codex|claude (ONE live turn, writes test/e2e-<backend>.jsonl), node packages/megha/test/live-steer.mjs codex|claude (one task, three turns: image + model, cancel, steer).

The agent in real T3 Code

The T3 providers codexCloud ("Codex Cloud") and claudeCloud ("Claude Cloud") in ~/.t3/userdata/settings.json run the main checkout's packages\megha\index.mjs. A T3 thread therefore tests what the main checkout has (merged and pulled), not your worktree.

• After a ship, or for behavior already on main: launch a thread on krida with T3's MCP tools.

  t3_thread_launch {
    "projectId": "c87a3bf3-c7ba-47a6-91ab-cda5ea2d2d7e",            // krida; omit workspaceStrategy = krida's root checkout
    "title": "megha verify: codex on krida",
    "modelSelection": { "instanceId": "codexCloud", "model": "default" },   // or claudeCloud
    "message": "List the three biggest files in src/ by line count and say in one sentence each what they do. Do not change any files."
  }
  t3_thread_wait  { "threadId": "<id>", "timeoutMs": 600000 }
  t3_thread_read  { "threadId": "<id>", "view": "activity", "maxCharsPerItem": 1500 }
  

  A follow-up is t3_thread_send on the same thread; a cancel is t3_thread_interrupt. Link the thread for me as [title](t3-thread://v1/<threadId>).
• Before merge, for this worktree's code: T3 needs a provider pointed at the worktree. Ask me first. With my OK: back up settings.json, add a meghaDevCodex / meghaDevClaude entry copied from codexCloud with commandArgs[0] set to <worktree>\packages\megha\index.mjs, launch with that instanceId, and remove the entry afterwards. T3 reloads providers by itself. Write the file with a Node script using String.raw paths, never shell one-liners (backslashes break).
• What a working thread shows in activity: a command_execution titled "Ran command" whose text starts $ Codex Cloud setup (or the Claude equivalent), reasoning items, the tool calls the cloud ran, and an assistant_message ending in [Open in Codex Cloud](https://chatgpt.com/codex/tasks/task_e_...). Status completed. Then git -C C:\Users\kaust\OneDrive\Documents\dev\krida status --short is unchanged from before the run.
• Proven working on 2026-10-14: threads "Cloud test: Codex Cloud on krida" (mcp:af758377-70ec-464c-9669-1903e3672f22) and "Cloud test: Claude Cloud on krida" (mcp:66265872-2b66-4661-af4f-65bd5fcd516a) in the krida project. Read them to see a good transcript.

The site

Launch on this checkout's port, in PowerShell so you hold the real Windows PID:

bun run setup                     # prints PORT=<n>; confirm with curl that nothing answers on it (doctor gap above)
$log = "$env:TEMP\megha-site-<n>.log"
$p = Start-Process cmd.exe -ArgumentList '/c', "set PORT=<n>&& bun run dev > `"$log`" 2>&1" -WorkingDirectory <checkout> -WindowStyle Hidden -PassThru
$p.Id                             # keep this PID for cleanup

On Linux or macOS (a cloud session), start it in its own process group so stopping the group stops Next too: