Use the workshop techniques on real web projects

You are my coding agent in this repo. Investigate the auth redirect loop by using the Oracle codebase handoff workflow, then implement only the locally verifiable fix. Do not skip the PackX preview. Create `.notes/` if needed. First run `packx --preview -s "Next.js auth redirect middleware session login callback API route"` and inspect the matched files and token estimate. If the scope is reasonable, run `packx -s "Next.js auth redirect middleware session login callback API route" -f markdown --no-interactive -o .notes/handoff-bundle.md`. Then send the bundle through Oracle browser mode with a 3-5 word kebab slug, and make the prompt start with the same bracketed slug on line 1: `ORACLE_MAX_FILE_SIZE_BYTES=12000000 oracle --engine browser --browser-thinking-time extended -p "[auth-redirect-loop]\n\nWe have a Next.js auth redirect loop. Read the attached PackX bundle and produce: 1) the likely root cause, 2) the exact files/functions to inspect first, 3) a minimal implementation plan, 4) local verification steps using the dev server/browser, and 5) risks or false leads to avoid. Do not propose unrelated rewrites." --slug "auth-redirect-loop" --write-output .notes/oracle-plan.md --file .notes/handoff-bundle.md`. After Oracle returns, read `.notes/oracle-plan.md`, summarize the recommended fix in `.notes/auth-redirect-receipt.md`, implement the smallest safe change, then run the repo's existing typecheck/test/build command discovered from package scripts. Finally start the local dev server and verify the login flow in a browser.

You are my coding agent. Use Oracle + PackX only for the broad read-heavy diagnosis, then return to local implementation and verification. Create `.notes/` if needed. Run `packx --preview -s "checkout cart state shipping method payment intent loader action API"`. Review the preview for checkout routes, cart/session modules, API handlers, and payment-related files. If relevant, run `packx -s "checkout cart state shipping method payment intent loader action API" -f markdown --no-interactive -o .notes/handoff-bundle.md`. Then run `ORACLE_MAX_FILE_SIZE_BYTES=12000000 oracle --engine browser --browser-thinking-time extended -p "[checkout-state-owner]\n\nRead the attached checkout-related codebase bundle. Identify which layer should own checkout/cart state, where the current flow can lose state during shipping changes, browser back navigation, refresh, or payment intent creation, and propose the smallest fix. Return exact file/function references, a step-by-step implementation plan, and browser verification steps. Avoid broad architecture rewrites unless the current code makes a minimal fix unsafe." --slug "checkout-state-owner" --write-output .notes/oracle-plan.md --file .notes/handoff-bundle.md`. Read the returned plan, write `.notes/checkout-handoff-receipt.md` with the chosen path, implement the minimal fix, then run existing tests/build. If the repo has no browser test, use the dev server plus a browser-agent or CMUX browser pane to verify the funnel manually and record evidence.

You are my coding agent. This is a read-heavy migration-mapping task, so use Oracle handoff first and do not edit source files until the returned plan is reviewed. Create `.notes/` if needed. Run `packx --preview -s "legacy feature migration routes components shared utilities tests"`. If the preview includes the expected legacy feature area, run `packx -s "legacy feature migration routes components shared utilities tests" -f markdown --no-interactive -o .notes/handoff-bundle.md`. Then run `ORACLE_MAX_FILE_SIZE_BYTES=12000000 oracle --engine browser --browser-thinking-time extended -p "[legacy-migration-map]\n\nRead the attached PackX bundle for a large web app migration. Produce an implementation-ready migration map: current entry points, route/page ownership, shared components/utilities, test/build commands to run, risky coupling points, safe first slice, and a plan -> implement -> verify sequence. Do not invent tools or recommend a broad rewrite; stay grounded in the attached code." --slug "legacy-migration-map" --write-output .notes/oracle-plan.md --file .notes/handoff-bundle.md`. After Oracle returns, create `.notes/migration-slice-receipt.md` with the first safe slice, explicit files to edit, verification commands, and browser proof needed. Implement only that first slice if it is small enough; otherwise stop with the migration map and receipt for human review.

You are the Manager agent in my focused CMUX pane. Do not implement yet. First inspect live CMUX state with `cmux --json tree` and `cmux list-panes`. Build a visible pane layout using only real CMUX commands: create worker panes with `cmux new-split right` and `cmux new-pane`, then name the workspace tab with `cmux rename-tab "checkout-triage"`. Create three worker roles: `server-log-worker`, `source-worker`, and `browser-proof-worker`. Send each worker a narrow task using `cmux send -- "<task>"`: server-log-worker runs or watches the local dev server and captures errors; source-worker inspects cart and checkout route code only; browser-proof-worker verifies the localhost checkout flow in a browser or browser-agent workflow and reports exact observed behavior. After each worker responds, read its visible terminal output with `cmux read-screen`, summarize conflicts between source, logs, and browser behavior, then propose the smallest fix. Expected output: a Manager report containing pane refs from `cmux --json tree`, each worker assignment, each worker result, the chosen fix plan, and the browser/dev-server proof shape required before merging.

You are the Manager agent in my focused CMUX pane. Keep the human interaction surface to you only. Use `cmux --json tree` and `cmux list-panes` first. Create a visible Manager/worker layout with `cmux new-split right` and `cmux new-pane`; name the tab `dashboard-drift-review` with `cmux rename-tab "dashboard-drift-review"`. Create workers named `current-code-worker`, `responsive-browser-worker`, and `cleanup-plan-worker`. Use `cmux send -- "<task>"` to assign: current-code-worker identifies the current dashboard route, component files, and styling sources; responsive-browser-worker opens the local dashboard in a browser and records desktop and narrow-width observations; cleanup-plan-worker waits for the first two worker outputs, then drafts a small numbered cleanup plan with options A/B/C and a recommended pick. Read worker panes with `cmux read-screen`. Expected output: a numbered implementation plan that says which files are source of truth, what the browser showed, which visual issues are real, and which cleanup option the Manager recommends before implementation.

You are the Manager agent in my focused CMUX pane. Start by creating a timestamp in your notes and inspect live CMUX state with `cmux --json tree` and `cmux list-panes`. Do not create new broad goals. Identify the existing worker panes by role, cwd, visible command, or recent terminal text. Every check-in cycle, use `cmux read-screen` to read each worker pane, summarize status, and if a worker is blocked by a simple question, choose the safest reasonable answer only when it stays inside that worker's assigned task. Use `cmux send -- "<answer or nudge>"` only after confirming the target pane from `cmux --json tree`. Stop after the explicit bound I give you, or after 3 check-in cycles if no bound is provided. Expected output: a check-in ledger with timestamp, pane refs, worker status, any answers sent, any panes needing human attention, and final stop reason.

Set up local agent-managed memory for this repo, then use it for the checkout fix. Run: `mkdir -p .notes .goals`. Configure global ignores without editing this repo's shared `.gitignore`: `git config --global core.excludesFile ~/.gitignore_global`; then ensure `.notes/` and `.goals/` are present in `~/.gitignore_global` without duplicating lines. Inspect the current checkout code before planning; do not trust old notes as source of truth. Write `.goals/checkout-flow-plan.md` as a numbered plan where each major item has options A/B/C and your recommended pick. Open a live tracker with `cmux markdown open .notes/tracker.md --direction right`. Keep `.notes/tracker.md` updated with current step, files inspected, commands run, browser proof status, and remaining risks. After I choose plan refs like `2B` or `5C`, implement only the approved path. Expected output: changed source files only where needed, `.goals/checkout-flow-plan.md`, `.notes/tracker.md`, and a final summary that separates committed-source changes from local scratch artifacts.

Use the agent-memory-folder pattern to resume work safely. First inspect `.goals/` and `.notes/` if they exist, but treat them as local scratch context only. Then inspect the current dashboard files and summarize where the existing notes agree or disagree with the current code. If folders do not exist, create them with `mkdir -p .notes .goals` and ensure `.notes/` and `.goals/` are in the global gitignore via `git config --global core.excludesFile ~/.gitignore_global`. Write `.goals/dashboard-resume-plan.md` with numbered implementation items and A/B/C options. Mark any stale assumptions explicitly. Open or update the live tracker using `cmux markdown open .notes/tracker.md --direction right`. Implement only the approved plan choices. Expected output: a resume plan, a stale-assumption section, a live tracker update, a source diff, and browser evidence from the running dashboard.

Prepare this shared repo for local-only agent planning. Create `.notes/` and `.goals/` with `mkdir -p .notes .goals`. Use the global ignore boundary: `git config --global core.excludesFile ~/.gitignore_global`; ensure `.notes/` and `.goals/` are present there exactly once. Do not edit the repo `.gitignore` unless I explicitly ask. Write `.goals/component-a11y-investigation.md` as a numbered plan with A/B/C options and recommended picks. Use `.notes/tracker.md` to record each agent's assigned area, commands run, and findings. If CMUX is available, open the tracker with `cmux markdown open .notes/tracker.md --direction right`; otherwise leave the Markdown file ready for any preview pane. Expected output: local planning artifacts, no committed scratch files, a concise investigation plan, and a review summary I can use to decide which findings become real tests or source changes.

You are my coding agent in this repo. Treat the current code as the source of truth. First inspect the existing app structure, routes, shared components, styling setup, and one representative dashboard screen. Do not rely on stale memory. Then create or update design.md with these sections: references, style DNA, color, typography, layout, composition, shape, motion, and constraints. Use only the generated inspiration references I provide or the selected direction I name; do not scrape or clone live websites. After design.md exists, refactor exactly one dashboard route or component to follow it. Run the repo's normal lint/typecheck/test command if available, start the local dev server, and verify the edited screen in a browser. Expected output: design.md, a small focused diff to the selected screen/components, terminal test output, and a short note explaining which design.md rules drove the visual decisions.

You are my coding agent. Use the current app code as the source of truth for routing, styling, and component conventions. First create design.md from my selected generated inspiration with the required sections: references, style DNA, color, typography, layout, composition, shape, motion, and constraints. Then generate 3 to 5 temporary route-level variants of the same landing page inside the running app. Add simple left/right navigation between variants if it fits the app, such as links or arrow-key handling. Do not create a permanent Storybook-style catalog. Start the dev server, open the variants in the browser, and produce a comparison note that names the strongest variant and why. After I choose a winner, promote that implementation to the real landing route and delete the rejected temporary routes. Expected output: design.md, temporary variants only during review, a promoted final route, deleted losers, and browser proof from the local app.

You are my coding agent. First inspect the current component files, styling conventions, route examples, and package scripts. Summarize the source-of-truth evidence before writing anything. Then create or update design.md as a design contract with references, style DNA, color, typography, layout, composition, shape, motion, and constraints. The contract should preserve stable conventions already present in the code unless they conflict with the chosen generated inspiration direction. Next update exactly one example/demo route or one small component cluster, such as Button/Card/Form, to follow design.md. Run the repo's available lint/typecheck/test command and start the local dev server. Expected output: design.md, one focused component/example diff, verification logs, and a browser review of the demo route.

Use the throwaway-route-variants skill only. First inspect the current routing structure, package.json scripts, existing homepage route, shared components, and design.md if present. Do not trust stale memory about the app structure. Create 5 temporary route-level variants of the homepage inside the app using the existing routing convention, for example /variant-a through /variant-e or the equivalent framework-native paths. Reuse existing components where practical, but keep variant-specific layout/styling isolated to the temporary routes so cleanup is simple. Add simple left/right navigation between variants, including visible Previous/Next controls and keyboard ArrowLeft/ArrowRight handling if that fits the app. Run the repo's actual dev command from package.json, usually npm run dev, pnpm dev, or bun dev. Prove every variant renders in the browser at localhost. After the human chooses a winner, promote only that implementation to the real homepage route, delete every losing variant route and temporary navigation wrapper, then run the relevant lint/typecheck/build command from package.json. Expected output: a short comparison table of the 5 variants, the chosen route, browser proof notes, commands run, and a final git diff summary showing only the promoted implementation remains.

Use the throwaway-route-variants skill for UI exploration only. Inspect the current auth guard, onboarding route, layout shell, data-loading pattern, and package.json scripts before editing. Do not change authentication logic, database schema, real onboarding mutations, or production redirects. Create 3 to 5 temporary route-level onboarding variants under a clearly disposable dev-only path, such as /onboarding/variant-a through /onboarding/variant-e or the framework's equivalent. Each variant should reuse the current authenticated shell and existing components, but it may use safe fixture data or read-only mocks when live data would create side effects. Add simple Previous/Next navigation between variants. Run the dev server using the actual package.json script and verify the routes in a browser. If auth is required, document the exact login path or test-user setup needed; do not assume cookies are shared with a browser agent. After the human chooses a winner, promote only that UI to the real onboarding route and delete every temporary variant path. Expected output: route list, auth assumptions, browser verification notes, commands run, cleanup confirmation, and final diff summary.

Use the throwaway-route-variants skill. Inspect the current dashboard route, layout components, data-fetching boundaries, responsive utilities, and package.json scripts. Create exactly 3 temporary dashboard route variants: one compact/data-dense, one guided/summary-first, and one card-based. Keep data access read-only and preserve existing component contracts. Add simple left/right navigation among the 3 variants. Run the local dev server with the actual package.json command, then verify desktop and narrow viewport behavior in a browser. Do not create Storybook stories, a permanent examples directory, or a dashboard variant gallery. After human selection, promote the winner to the real dashboard route and delete the 3 temporary routes. Expected output: variant intent summary, browser proof at desktop and mobile/narrow viewport, commands run, selected winner, and cleanup proof from git diff or route search.

Run a 5 Monkeys QA swarm against the authenticated dashboard. First inspect the repo for the dev command and any documented test user or seeded auth flow. Start the app locally using the repo’s normal command, such as npm run dev, pnpm dev, or the command documented in package.json/README. Create .notes/qa-dashboard-swarm.md as a discardable numbered QA file. Assign five lenses: expert power user, brand-new first-time user, grandparent/inexperienced user, impatient power user, and distracted returning user. For each lens, use a browser workflow against localhost and deliberately avoid only confirming the happy path. Try: login, navigate to the dashboard, open filters, toggle modes, click the same controls repeatedly, use browser back/forward mid-flow, abandon a modal halfway through, refresh after changing state, and return to the page. Record each finding with: perspective, exact path, expected behavior, observed behavior, severity, and whether it looks like stable business logic or fast-changing UI. Expected output: .notes/qa-dashboard-swarm.md plus a short final summary of the 3-7 useful findings only.

Run the 5 Monkeys technique on the checkout/billing flow. Treat stable pricing, totals, validation rules, and submitted payloads as serious business logic; treat copy, spacing, and visual layout notes as flexible UI findings unless they block the user. Create .notes/qa-checkout-five-monkeys.md. Start the local app and document the exact command. Assign lenses: expert buyer, brand-new customer, grandparent/inexperienced user, impatient power user, and skeptical returning customer. In the browser, test non-obvious paths: change plan then press back, enter then remove a coupon, rapidly change quantity, start checkout then abandon before payment, refresh on a later step, use keyboard navigation where controls are visible, and retry after validation errors. Capture console errors, visible state, URL, and any mismatch between displayed total and expected total. Expected output: a discardable QA file, a concise release-risk summary, and recommendations for which findings should become durable automated tests.

Run a 5 Monkeys QA pass against the local pricing and upgrade flow. Assign five perspectives: brand-new trial user, impatient mobile user, keyboard-only user, existing customer changing plans, and skeptical QA engineer. Each perspective should explore weird paths: toggle monthly/yearly repeatedly, apply invalid and valid coupons, switch plans after opening checkout, use back/forward, refresh mid-flow, and try keyboard navigation. Each worker writes one discardable QA file under `.notes/qa/pricing-<perspective>.md` with steps, expected result, observed result, screenshot or browser transcript path, severity, and whether the issue is reproducible. Collate findings into `.notes/qa/pricing-summary.md` and recommend only the highest-value fixes.

Copy-paste to Codex: Use the image-to-design handoff workflow for the dashboard card at <ROUTE>, backed by these artifacts: current screenshot <CURRENT_SCREENSHOT_PATH>, selected reference image <SELECTED_REFERENCE_IMAGE_PATH>, and relevant source files <COMPONENT_OR_ROUTE_PATHS>. 1. Inspect package.json and the current component/source before editing. Treat the live code as source of truth for props, data loading, auth, events, and tests. 2. If <SELECTED_REFERENCE_IMAGE_PATH> does not exist yet, ask an image model for one sheet of 5 visual variations of this exact card based on <CURRENT_SCREENSHOT_PATH>, then stop and ask me which direction to use. Do not implement until I pick one. 3. Once the selected reference exists, implement ONLY that direction. Match layout, spacing, color, type, density, border/radius, and visual hierarchy. Do not blend in other variations. Preserve existing copy, links, data-testid values, analytics attributes, and behavior unless a markup change is necessary for accessibility. 4. Run `npm run lint`. Run the nearest existing test command from package.json if one is already present; do not invent a test framework. 5. Run `npm run dev` and prove the result in a browser at `http://127.0.0.1:3000<ROUTE>` or the port printed by the dev server. Expected output: a focused diff, the commands run, a browser screenshot saved as `artifacts/image-to-design-dashboard-card.png`, and a short review note listing inspected files plus any intentional differences from the reference.

Copy-paste to Codex: Apply image-to-design handoff to the onboarding screen at <ONBOARDING_ROUTE>. Artifacts: selected reference image <SELECTED_REFERENCE_IMAGE_PATH>, current screenshot <CURRENT_SCREENSHOT_PATH>, explicit login or seed instructions <AUTH_INSTRUCTIONS>, and source hints <AUTH_FILES_AND_ONBOARDING_FILES>. 1. Inspect the route, auth guard, form component, validation messages, and existing tests before editing. Do not assume browser cookies are shared with the automation environment. 2. Implement ONLY the visual direction in <SELECTED_REFERENCE_IMAGE_PATH>. Preserve the onboarding state machine, validation behavior, submit handlers, redirects, copy, and analytics/data attributes. 3. If a selected reference is missing, generate one sheet of 5 visual variations for this onboarding step, then stop for human selection before editing code. 4. Run `npm run lint`. If package.json already defines a relevant test, run that exact script. Do not add a new browser framework just to prove this change. 5. Run `npm run dev`. Verify in a browser from login through <ONBOARDING_ROUTE> using <AUTH_INSTRUCTIONS>. Expected output: focused UI diff, command logs, `artifacts/onboarding-before-or-current.png` if available, `artifacts/onboarding-after-selected-reference.png`, and a short proof note covering login, validation, successful submit or expected blocked submit, and any console/dev-server errors.

Copy-paste to Codex: Implement the selected image-to-design direction for the marketing hero at <MARKETING_ROUTE>. Artifacts: selected reference image <SELECTED_REFERENCE_IMAGE_PATH>, current route screenshot <CURRENT_SCREENSHOT_PATH>, and relevant source files <HERO_ROUTE_AND_COMPONENT_FILES>. 1. Inspect package.json, the hero route/component files, and any shared button/link components before editing. Preserve copy, hrefs, tracking attributes, data-testid values, and form/newsletter behavior. 2. If there is no selected reference image, ask an image model for a sheet of 5 hero variations from the current screenshot and product constraints, then stop for human selection. 3. Implement only the selected direction. Match composition, rhythm, spacing, type scale, contrast, image/illustration treatment, and CTA prominence. Do not introduce a maintained design system or broad route-variant workflow for this task. 4. Run `npm run lint` and any existing route/component test script listed in package.json. 5. Run `npm run dev` and prove desktop and mobile in the browser. Expected output: a focused diff, desktop screenshot `artifacts/hero-desktop-selected-reference.png`, mobile screenshot `artifacts/hero-mobile-selected-reference.png`, command output, and a concise implementation note describing how the selected image was translated into code.

Build a minimal Ralph Loop Codex plugin for this repo. Inspect workshop-followup/toolkit/prompts/07-ralph-loop-stop-hook-prompt.md and workshop-followup/toolkit/codex-skills/ralph-loop-hook/SKILL.md first. Enable hooks and plugins in ~/.codex/config.toml with hooks=true, plugins=true, plugin_hooks=true, then tell me to restart Codex before testing. Scaffold ralph-loop-checkout/.codex-plugin/plugin.json, ralph-loop-checkout/hooks/hooks.json, and ralph-loop-checkout/hooks/hook.py. Wire only the Stop hook to python3 "${CODEX_PLUGIN_ROOT}/hooks/hook.py" with timeout 5. The hook must read stdin JSON and write exactly one control JSON line. Store tiny local state for the original goal and iteration count. Completion condition: stop when all of these receipts exist in .notes/ralph-loop-checkout/: passing-test.log, browser-proof.md, and final-summary.md, or when iteration_count reaches 5. Do not use suppressOutput in Stop. After scaffolding, run a local simulation command that pipes mock Stop events into hook.py and proves both paths: continue before receipts exist, allow stop after receipts exist or at the cap. Expected output: plugin files, a short README section showing install/test steps, and simulation logs saved under .notes/ralph-loop-checkout/.

Create a Ralph Loop plugin named ralph-loop-dashboard for dashboard visual cleanup. Start by reading workshop-followup/oracle/07-references.json, workshop-followup/toolkit/prompts/07-ralph-loop-stop-hook-prompt.md, and workshop-followup/toolkit/bundles/code-better-plugins.md. Use the taught lifecycle model: UserPromptSubmit, PreToolUse or Tool Use, and Stop; implement only the Stop hook for this scenario. Plugin layout must be ralph-loop-dashboard/.codex-plugin/plugin.json, ralph-loop-dashboard/hooks/hooks.json, and ralph-loop-dashboard/hooks/hook.py. Add a .notes/ralph-loop-dashboard/acceptance.md file that lists the exact dashboard routes to verify and a .notes/ralph-loop-dashboard/proofs/ directory for receipts. Completion condition: allow stop only when acceptance.md has every route marked verified with a matching proof markdown file, or when 4 Stop iterations have happened. Each continuation message should point back to the original dashboard goal and name the next missing route proof. Expected output: plugin scaffold, acceptance/proof file contract, hook simulation, and instructions for installing with codex plugin marketplace add "$PWD" then codex plugin add ralph-loop-dashboard@better-plugins only if this repo is being used as a marketplace-style plugin source.

Build a toy plugin named ralph-loop-toy that demonstrates the Ralph Loop without touching application code. Use only the taught plugin/hook model from lesson 07 and the existing toolkit artifacts. Read workshop-followup/oracle/07-references.json, workshop-followup/oracle/07-validation.json, workshop-followup/toolkit/codex-skills/ralph-loop-hook/SKILL.md, and workshop-followup/toolkit/bundles/code-better-plugins.md. Scaffold ralph-loop-toy/.codex-plugin/plugin.json, ralph-loop-toy/hooks/hooks.json, ralph-loop-toy/hooks/hook.py, and ralph-loop-toy/tests/simulate-stop-events.py. The toy goal is: create .notes/ralph-loop-toy/done.txt containing DONE. The Stop hook should continue until done.txt exists or until iteration_count reaches 3. The simulator must run three cases: no done.txt means continue, done.txt means stop, cap reached means stop with a clear failure note. Expected output: the plugin files, simulator output, and a short README that tells students to review /plugins and /hooks after install and to restart Codex after config changes.

You are my coding agent. Run a self-improving log-gated fix loop for the local auth redirect bug. First inspect the current code and existing verification scripts; do not rely on memory. Start the dev server using the repo's documented command from package.json. Reproduce the flow in a browser: visit /login, sign in with the local/dev credentials or seeded test user documented in the repo, navigate to /dashboard, refresh, and confirm whether the browser stays on /dashboard. Capture exact evidence: terminal output with `cmux read-screen`, browser console/network output if available, and a JSON log artifact at `.notes/log-gated/auth-redirect/run-<timestamp>.json`. The log must include goal, routeVisited, finalUrl, redirectCount, authCookiePresent as true/false when observable, serverStatusCodes, consoleErrors, terminalFailureText when present, and pass boolean. If the first run fails, use this repair prompt shape internally: `Goal: authenticated users should remain on /dashboard after login and refresh. Here is the exact failure: <paste terminal/browser/log evidence>. Explain WHY it failed in this scenario, then PATCH the workflow so this case is covered next time.` After patching, rerun the same browser flow and write a second JSON artifact. A supervisor pass must compare expected-vs-actual fields and only pass when finalUrl is /dashboard, redirectCount is 0 after the authenticated refresh, pass is true, and no new console/server errors appear. Finish with the files changed, commands run, log artifact paths, and a terse review note.

You are my coding agent. Build a log-gated verification loop for the checkout/pricing flow. Inspect the source files for the pricing/checkout route, the relevant components, and existing tests. Start the local app using the repo's package scripts. Create `.notes/log-gated/checkout/criteria.md` with the expected scenario fields: selectedPlan, displayedPrice, ctaEnabled, confirmationVisible, finalUrl, consoleErrors, networkFailures, and pass. Then run three browser scenarios: default plan selection, switching plans twice, and back/refresh during checkout. For each scenario, write `.notes/log-gated/checkout/<scenario-slug>.json` with timestamp, exact steps, expected fields, actual fields, terminal evidence from `cmux read-screen` when a failure occurs, and pass boolean. If any scenario fails, use the exact failure text and artifact contents to patch the code or workflow, then rerun only the failing scenario plus one happy-path scenario. Add or update a verifier script only if the repo already has a natural place for local scripts; otherwise have the supervisor agent compare the JSON files directly. The gate passes only when all expected-vs-actual fields match and the browser proof agrees with the logs.

You are my tooling agent. Run the self-improvement error loop on the failing hook/CLI workflow. First reproduce the failing command or hook scenario exactly. Capture the terminal state with `cmux read-screen` and save the raw text to `.notes/log-gated/tooling/failures/<timestamp>.txt`. Then apply this prompt shape to your own diagnosis: `Goal: <describe the hook or CLI contract>. Here is the exact failure: <paste captured terminal text>. Explain WHY it failed in this scenario, then PATCH the hook/workflow so this case is covered next time.` Patch the smallest relevant hook/workflow code. Add structured run artifacts under `.notes/log-gated/tooling/runs/` containing scenarioName, inputShape, commandRun, expectedOutcome, actualOutcome, errorText, timestamp, and pass. Run at least the original failing case and one nearby non-failing case. A supervisor pass must inspect the run artifacts and compare expectedOutcome vs actualOutcome. Do not claim success unless the artifacts show the original failure case now passes and the nearby case still passes.

Create an isolated Codex daemon profile named pro-browser-qa for the repo's browser verification CLI or script. First inspect the current repo for existing browser test commands, Playwright scripts, or agent-browser usage; do not invent a new stack if one already exists. Write a single executable Bun TypeScript file at daemons/pro-browser-qa that calls runProfile() from lib/isolated.ts. Use the developerInstructions shape: Operating rule, Command map, Workflow, Command rules, Output. The operating rule must require running the browser QA command through exec_command before any final answer. The command map should include only the local commands this repo actually has, such as dev server health check, run signup flow, run login flow, capture console output, capture screenshot, and help. Keep the map literal; do not paste full --help output. Mutations are not allowed: this daemon verifies and reports only. After creating it, run chmod +x daemons/pro-browser-qa, run bun daemons/pro-browser-qa --help, add it to package.json bin if the repo uses that pattern, and run bun link. Expected output: a terse report with command run, route tested, pass/fail, browser evidence path, console errors, and next action.

Create an isolated Codex daemon profile named pro-deploy-check for the repo's deployment CLI or existing preview-check script. Inspect package.json and repo scripts first. If the repo already uses a specific deploy CLI, wrap that one CLI only. Write daemons/pro-deploy-check as a single executable Bun TypeScript file using runProfile() from lib/isolated.ts. The daemon must start with the narrowest read-only command: deployment status or preview URL discovery. The command map should cover status, current preview, logs, inspect URL, and help, using exact repo commands. For mutations, require explicit target and action; default to read-only. Disable broad behavior in the prompt: no web search, no image generation, no unrelated file edits, no apply_patch unless explicitly asked. After generation, run chmod +x daemons/pro-deploy-check, bun daemons/pro-deploy-check --help, test one real prompt such as 'status for the current PR preview', then add package.json bin and bun link if appropriate. Expected output: current deployment state, preview URL, failing route if any, command evidence, and browser proof path.

Build or use an isolated Codex daemon profile for accessibility triage only. Keep the command map narrow: inspect package scripts, run the existing accessibility or browser-test command if present, start the local dev server only when required, open the target route in a browser, capture an accessibility snapshot, and report missing labels/headings/focus problems with file or route pointers. The daemon should write one markdown report under `.notes/a11y/<route-slug>.md` with commands run, browser route, snapshot summary, issues found, false positives, and recommended next fixes. It must not edit files unless explicitly asked after the audit report is reviewed.

Create `.goals/overnight-auth-watch.md` and run it as a bounded /goal-style task. Goal: record a starting timestamp, then every 10 minutes until 7:00 AM local time or 24 iterations, whichever comes first, verify the local auth flow against the running app. Stay read-only unless I explicitly approve a mutation. First inspect the project scripts and start or reuse the dev server. For each iteration, capture the context triad: intent from this goal file, implementation from the smallest relevant auth/session/routes files, and output from browser console logs, network or terminal errors, screenshots, and a short iteration summary. Write artifacts under `.notes/overnight-auth-watch/` using timestamped filenames such as `iteration-003.json`, `iteration-003-console.log`, and `iteration-003-screenshot.png`. At the end, write `.notes/overnight-auth-watch/final-report.md` with pass/fail counts, first failing iteration, suspected mismatch between intent/implementation/output, and the exact evidence files to inspect. Do not declare success without inspecting the written artifacts.

Create `.goals/overnight-ui-smoke.md`. Record the starting timestamp. Every 15 minutes, until 6 hours have elapsed or 20 iterations are complete, run a read-only UI smoke routine against the local web app. Inspect `package.json` for the dev and build commands. Start or reuse the dev server. Visit the agreed routes: `/`, `/pricing`, and `/dashboard` if present; if a route does not exist, record that instead of inventing one. For each route, capture console errors/warnings, one screenshot at desktop width, one screenshot at mobile width if the browser tool supports viewport changes, and a short artifact summary. Write files under `.notes/overnight-ui-smoke/`. If an error appears, bundle intent, implementation, and output with PackX: goal file, smallest route/component files, console logs, screenshots, and terminal output. End with `.notes/overnight-ui-smoke/final-report.md` listing stable routes, failing routes, first failure time, and the likely mismatch.

Create `.goals/overnight-upgrade-investigation.md`. This is a read-only overnight research and verification loop. Record the starting timestamp. Every 20 minutes until 4 hours have elapsed or 12 iterations are complete, inspect the current dependency-upgrade state. Run only read-only or normal verification commands discovered from the repo, such as package-manager install status checks, typecheck, lint, test, or build commands already present in scripts. Do not edit package files or source files. Save terminal output to `.notes/overnight-upgrade-investigation/iteration-###.log` and a structured summary to `iteration-###.json`. When failures appear, capture the context triad: the goal text, relevant package/config/source files, and actual command output. Use PackX only after previewing the candidate files. Finish with `final-report.md` containing a ranked list of blockers, commands run, evidence paths, and a recommended next goal file for implementation.

You are implementing from a narrated video requirements artifact. First inspect the current app source and existing tests; do not trust stale notes. Use the video-derived QA story as the natural-language contract. Create or update `.goals/cart-video-requirements.md` with: user flow, acceptance criteria, responsive behavior, edge cases, and what evidence will prove the fix. Then implement only the behavior described: stable mobile drawer layout, persistent promo-code error state until corrected or dismissed, shipping selection as the gate for enabling checkout, and no unrelated redesign. Run the project’s normal lint/test/build commands discovered from package scripts. Start the local dev server and verify the flow in a browser. Produce a final review artifact containing the git diff summary, commands run, browser proof, and any remaining risks.

Use the narrated walkthrough as requirements, not as a polished spec. Extract a QA story with the exact user flow, expected visual/layout behavior, responsive breakpoints observed in the video, and edge cases. Inspect the current dashboard code, routing, state ownership, and any existing browser tests. Implement the smallest change that preserves filter state, keeps expanded row context stable, makes search results collapse predictably on narrow screens, and improves tablet card ordering without changing unrelated dashboard styling. Run the repo’s normal verification commands. Then run the dashboard in a browser and prove the flow works at desktop, tablet, and mobile widths. Final output must include the diff summary plus browser evidence, not a generic success claim.

Treat the video as evidence for a natural-language contract. Extract the intended onboarding states and transitions from the narration: invite opened, auth checked, workspace joined or created, empty state shown, and error or retry states if present. Inspect the current code and identify the modules that own auth, workspace creation, routing, and empty-state rendering. Implement the smallest fix that satisfies the contract. After verification, review the git diff as the primary artifact. Then update `agents.md` or `AGENTS.md` only if the mistake reveals a reusable project-specific guardrail, such as where onboarding state must live or which module owns invite acceptance. Keep the guardrail short and grounded in this actual mistake.