Fleet-dispatch handoff — read this first if you're picking up WT-c2bc¶
Session: WT-c2bc (worktree peaceful-knuth-612faf, branch claude/peaceful-knuth-612faf)
Role: standing backlog dispatcher — Claude orchestrates, Codex/Gemini/Grok implement (Claude Max at 6% weekly cap, minimize Claude-tier reasoning).
Ticket on file: WING-72 (WW-74, closed out — see below). Board: https://workwingman.atlassian.net/browse/WING-72
Other live sessions — last snapshot, point-in-time (re-check list_sessions, don't trust this cold)¶
WT-c2bc is stopping at ~2% weekly Claude Max budget. Everything below was true as of this session's last look — verify before acting on it, sessions land/finish fast.
Confirmed landed since this session started (their sessions are likely idle/done now, safe to route new work their way if you check first): WW-146/147 queue buckets, WW-105/106 Skills & Growth, WW-148 Levels.fyi deep-link, the Hendricks Big Leap/Genius Zone "Know yourself" fold-in, and an Excelsior/WGU/Franklin degree-completion snapshot-provider set (just landed as this session closed — UmpiCreditPolicySnapshotProvider/WguCreditPolicySnapshotProvider + honesty tests).
Sessions seen active earlier this session (titles only, no live status — some may be done by now too): "UI efficiency overhaul for the Study page," "Architect Simple Mode coverage for tonight's 8 epics," "Feasibility: Glassdoor/Levels.fyi login" (likely superseded/done — see WW-148 above), "Evaluate WW recommend-jobs-to-save feasibility spike." The various "Architect WW docs/BOARD.md's Done rows — treat those as finished unless you see fresh commits otherwise.
Don't re-derive this by re-reading the whole session list cold — it's an expensive call (500+ lines). Use docs/BOARD.md's Done rows (cheap, targeted) plus a list_sessions call filtered/grepped for keywords when you actually need current truth.
Build-breaker fixed, and a live governance violation caught (WT-5d11/WING-167)¶
If your checkout predates 9f34b96, pull. Commit 40c9c72 left an unclosed <!-- HTML comment in power-shell-nav.html (opened, never closed), swallowing the rest of the template incl. </nav> — broke ng build for everyone (NG5002 unexpected EOF) since. Fixed in 9f34b96.
Real-time proof the worktree-isolation policy matters, not just theory: while WT-5d11 fixed the above, another session editing that same file directly in the shared main checkout (C:\Users\fives\source\repos\WorkWingman, not a git worktree add branch) clobbered the fix back to broken mid-edit. Had to reapply fast to lock it in. Any session — Claude, Codex, Gemini, Grok — doing WW code edits must work in its own assigned worktree, never the main checkout, especially with this many parallel epics running. This isn't a hypothetical risk; it happened tonight.
Known gotcha (cross-fleet, applies to ANY WW dev/test session, not just this one)¶
A stale debug-build WorkWingman.Api.exe can squat port 5211 and silently answer instead of the real app. Reported by WT-5d11 (WING-167, fleet-reinstall duty): after a fresh WW install, Andrew saw "API isn't working, can't find my vault or anything." Root cause wasn't the installer — a leftover WorkWingman.Api.exe from an earlier dotnet run/dev-debug session (bin\Debug\net10.0\) was still holding port 5211, answering with a different working directory/vault path than the real installed app, making everything look broken/missing.
Before assuming an installer, build, or reinstall is broken:
netstat -ano | findstr 5211
Get-Process -Id <pid> | Select-Object Path
Path points into bin\Debug\ or bin\Release\ instead of the installed app's location, kill that PID and relaunch the real app. Any session that ran the API locally for dev/testing owes it to the next person to make sure that process is dead before Andrew or a tester launches the packaged build.
This file is harness-agnostic — Codex/Gemini/Grok can drive this role directly, not just Claude¶
If you are codex exec, agy, or grok reading this file (as your own dispatched task, or because Andrew pointed a fresh session at it), you can run this coordinator role yourself. Everything below only needs a shell + git + this file — none of it depends on Claude Code specifically. This session's Monitor/Task/ScheduleWakeup calls (mentioned below) are just this harness's own polling convenience; substitute plain shell wherever you see them:
# poll-until-exists — works from any shell any harness can run, no special tooling
while [ ! -f "<path/to/expected/output/file>" ]; do sleep 30; done
To dispatch the next backlog ticket yourself (same pattern this session used — copy-pasteable from any CLI):
# isolated worktree off current master, per this repo's worktree-isolation policy
git worktree add /path/to/_wt/workwingman-<ticket> -b wt/WT-<id>/<ticket> origin/master
# hand it to ONE OF THE OTHER fleet CLIs — never dispatch to yourself, that's not delegation
codex exec --skip-git-repo-check "<full task prompt: scope, exact file paths, test commands, explicit do-not-touch-master rule>"
# or (agy's -p style flag needs the prompt inline/from a file, NOT stdin — see gotcha below)
agy --cwd "<worktree-path>" --prompt-file "<prompt.txt>" --always-approve --output-format plain
# or
grok --cwd "<worktree-path>" --prompt-file "<prompt.txt>" --always-approve --output-format plain
Then: verify the build/tests actually ran (don't trust a clean exit alone — see the codex-sandbox gotcha below, it silently degrades), run the council-code-review gate if the change is code (skip that for docs-only spikes), commit, git pull --rebase origin master && git push origin HEAD:master, update the ticket's row in docs/BOARD.md, and — most important — rewrite this file's STATUS section before you stop, so whichever tool reads it next (Claude, Codex, Gemini, or Grok — doesn't matter which) gets accurate state instead of a stale doc. A stale status line is exactly what made WW-74 look unfinished for who-knows-how-long when it had actually landed.
Same rules apply to you as applied to WT-c2bc: don't start new backlog scope while the finish-line directive below is active, dispatch one ticket at a time to a sibling fleet CLI (you're the orchestrator the moment you're reading this file — hand real implementation to someone else), and treat this file as the shared source of truth across every harness, not a Claude-only note.
STATUS AS OF LAST UPDATE (2026-07-24, ~15:35 CDT)¶
Andrew sent a FINISH-LINE DIRECTIVE mid-session: land everything in flight, do NOT start new scope. This session is currently obeying that — the backlog-dispatch queue below is PAUSED, not abandoned. Both items that were in flight are now landed. Nothing is currently running. Whoever reads this next should re-confirm with Andrew whether the finish-line directive is still active before dispatching anything new — do not assume it lifted just because the queue is empty.
Done this session¶
- WW-74/WING-72 — turned out to already be fully on
origin/master(commite622315, backend+frontend+controller all present). BOARD.md had a stale "NOT merged/pushed" row. Corrected + pushed directly to master as8ef836b. No further action needed on WW-74. - WW-83/WING-80 (SAM.gov opportunities recon spike) — Grok wrote
docs/technical/ww-83-samgov-opportunities-recon.md(CONDITIONAL-GO verdict, Kerr-clean, matches sibling spike-doc format — reviewed before landing). Committed + pushed straight to master asaa96b91. BOARD.md row updated to Done. No further action needed on WW-83.
In flight — check this first on resume¶
- Nothing. Both dispatches above are landed. If you're resuming and see something running that isn't in this section, it was started by someone/something else — investigate before touching it.
NEXT PRIMARY FOCUS (once the current epic wave lands): live-ATS Playwright verification¶
Andrew's own words (2026-07-24): once tonight's epics (tax/COL, benefits, federal, education, total-rewards, company-intel, simple-mode, recommend-jobs, skills-growth, degree-completion) are done, the primary technical focus shifts to testing that Playwright actually goes through the ATS systems well on the real live page — not just the fixture-based lab tests that already pass. This section briefs every fleet CLI (Codex, Antigravity/Gemini via agy, Grok) and the fleet-harness dispatch mechanism on what that means before it starts, so nobody has to rediscover the shape of this work cold.
What already exists (don't rebuild it)¶
src/WorkWingman.Infrastructure/Automation/ has a real ApplyEngine + Selectors pair per ATS: ADP, Amazon, Avature, Dayforce, Google, Greenhouse, iCIMS, Lever, Microsoft, Oracle, Paycom, Paycor, SuccessFactors, UKG, Workday (+ Meta, handled slightly differently). Each one already has a lab under tools/WorkWingman.ScraperLab.<Name>/ (a Fake<Name>Site deterministic fixture server + <Name>AutomationEngine + a headless LoopRunner/Program for repeated runs + LabMetrics/LabVault) and a matching *Tests project (some under tests/, some under tools/, inconsistent — check both). Per memory: 11 ATS labs already reported done overnight; PageAgent (LLM-driven fallback for pages the deterministic selectors can't handle) is the hybrid-fallback verdict, already built.
The gap this next phase closes: those labs test against Fake<Name>Site — a hand-built clone of the real ATS's DOM shape at the time it was written. Real ATS vendors change their DOM. The next phase is running the same engines against real, live employer application pages on each ATS platform and confirming the selectors/flow still hold, without ever completing a real submission.
HARD SAFETY BOUNDARY — this is non-negotiable, not a style preference¶
This repo's own binding ground rule (docs/BOARD.md header, restated in memory as [[workwingman-safety-promises]]): the automation never clicks Submit, never types stored passwords into a real account-creation flow, and never creates real accounts. RunResumeGates and the existing judgment-pause pattern (see JudgementPauseTests in the Meta lab) exist specifically so a human confirms before the point of no return. Any live-ATS verification task dispatched to Codex/Gemini/Grok must say this explicitly in the prompt, every time — stop at the last safe checkpoint before submission, screenshot/log the state there, and hand back a report rather than completing the flow. Treat a fleet CLI that "helpfully" clicks through to a real submission as a bug in the dispatch, not the CLI — the prompt is what's supposed to prevent it.
Concrete starting points (already-filed tickets, not new scope)¶
These are exactly what this phase is — no need to invent new ticket numbers when it's time to start:
- WW-92 — AmazonLabTests.cs's one browser test still needs the SharedBrowser adoption pattern (tools/WorkWingman.TestSupport/SharedBrowser.cs) that Meta.Tests already has (11 browsers → 1). Was already In Review with commit edf2904 as of the last board read — check git log origin/master -- tools/WorkWingman.ScraperLab.Amazon.Tests before assuming it needs more work (same "verify before trusting the board" lesson as WW-74).
- WW-89/WING-13 — vitest worker starvation silently drops frontend tests from the count while still exiting green. Not ATS-specific but same trust-the-test-signal theme; worth fixing before leaning hard on CI green during the live-verify push.
- WW-94/WING-86 — the wider triage of unguarded Playwright waiting calls across Automation/ (~78 candidate calls, most legitimately need to stay unguarded). This is exactly the kind of per-site judgment call that matters more once engines are pointed at real, slower, less predictable live pages instead of fast local fixtures.
- WW-63e (Needs Andrew) — fresh NVDA/Narrator accessibility listen. Explicitly not fleet-dispatchable — flagged human-only in the board itself. Don't attempt it via Codex/Gemini/Grok.
Per-harness prep¶
- Codex (
codex exec) — best fit for the .NET-side engine/selector verification work (it's already doing C#-heavy dispatches like WW-74 tonight). Watch for the Windows-sandbox gotchas logged above (CreateProcessWithLogonW failed, read-only linked-worktree git metadata, NuGet-config sandbox-write failures) — they showed up on a plain rebase+test task, so expect them on live-browser Playwright runs too and budget for a closer watch, not fire-and-forget. - Antigravity/Gemini (
agy) — use--prompt-file, not stdin, and--cwdfor the worktree (see the corrected invocation above — the first attempt this session failed on the equivalent grok mistake, don't repeat it for agy). Good fit for the broader survey/triage-style tickets (WW-94's per-site classification) where research + judgment matters more than deep .NET refactoring. - Grok (
grok --prompt-file ... --always-approve --output-format plain) — proved itself tonight on research-heavy, doc-producing work (WW-83). For live-ATS verification, a good fit for the adversarial angle: given a report of "selector X still matches," try to find where it's brittle (multi-req employer variations, A/B-tested DOM, mobile-vs-desktop layout) rather than just confirming happy path. - Fleet-harness (cross-PC dispatch) — 15 ATS engines is naturally parallelizable one-engine-per-dispatch across the house PCs, same shape as tonight's per-epic worktree fan-out. Route through the same
fleet-dispatchskill/queue already in use; each PC's listener runs its own Claude/Codex/Gemini/Grok CLI against a distinct ATS engine's worktree. Keep the safety-boundary prompt language above identical across every dispatch — don't let per-PC prompt drift quietly drop the "never submit" instruction.
Do not start any of this now — it's next-phase prep, not current scope, and the finish-line directive above still governs what's allowed to run today.
Paused — do NOT start until Andrew lifts the finish-line directive¶
Full unclaimed-backlog worklist (still valid, still unclaimed as of last check — re-verify against docs/BOARD.md + a fresh list_sessions before resuming, sessions move fast):
1. WW-102/WING-107 — Education T5 import-diff wiring (deps WW-100/101/98 all Done — ready to dispatch).
2. WW-108/WING-113 — Internship-track queue facet (deps WW-103/98 Done — ready).
3. WW-75/WING-73 — Offer Review & Decision epic. Full council spec exists at docs/technical/offer-review-design.md. Too big for one dispatch — needs a T0..Tn split first (same pattern every other epic used tonight) before handing slices to the fleet.
4. WW-69..72 (TROI epic: model router, caveman-compression boundary, DurableOutcomeLinker, multi-BYOK council) — unclaimed, but no architect spec doc found for this one — may need a quick council-architect pass before fleet dispatch.
5. WW-89/WING-13 — real masked-CI-failure bug (vitest worker starvation drops tests silently, still exits green). Unclaimed, real work.
6. WW-92 — already has a commit (edf2904) sitting In Review — check if it just needs the same "is it actually already on master" verification WW-74 needed before assuming it needs more work.
7. WW-94/WING-86 — Playwright unguarded-wait triage. Investigation-heavy, lower priority for fleet dispatch (not really implementable by a single CLI shot).
Confirmed claimed by other live sessions — do not touch, even after finish-line lifts, without re-checking they're still active:
WW-105/106 Skills & Growth (this landed too — f698628 "WW-105/106 Skills & Growth + Skill Builder, simple-mode-first" is already on master as of this session's fetch — board row for it may also be stale, worth a quick check next time), Study page overhaul, Simple Mode coverage architecture, Glassdoor/Levels.fyi feasibility spike, recommend-jobs feasibility spike, exam-out degree-completion follow-up (Excelsior/WGU/Franklin).
Correct CLI invocations (learned the hard way this session)¶
docs/technical/llm-harness.md's preset table says grok -p reads the prompt from stdin — that is WRONG for the currently-installed grok CLI (grok --help shows -p, --single <PROMPT> wants the prompt as an inline argument, not stdin; piping to stdin gives error: a value is required for '--single <PROMPT>'). Use instead:
grok --cwd "<worktree-path>" --prompt-file "<path-to-prompt.txt>" --always-approve --output-format plain
--prompt-file avoids the ~32KB arg-length cap mentioned in memory too.)
codex exec --skip-git-repo-check "<prompt>" works, but in a linked git worktree (i.e. anything created with git worktree add, which is every worktree this repo uses per the isolation policy) it hit real friction under Windows sandboxing:
- Can't write to the linked worktree's .git/worktrees/... metadata (read-only under codex's sandbox) — it self-healed by cloning into an isolated writable location and working there instead.
- CreateProcessWithLogonW failed: 2 errors when spawning subprocesses (unclear if this blocked real work or was transient — codex kept retrying and making progress in the log, but never got far enough to actually run dotnet build/tests before this session moved on because the rebase turned out to be moot).
- Also hit a NuGet-config sandbox-write failure on its first build attempt.
Takeaway: codex-in-worktree dispatches need closer babysitting than a fire-and-forget background launch — check the log for these sandbox errors specifically, don't just trust "still running = fine."
Lesson for the week: verify board claims against git, don't relay them¶
BOARD.md said WW-74 was "NOT merged/pushed." It was wrong — the work had landed under its own cited commit hash and nobody updated the row. Before spending a fleet-model dispatch "finishing" a ticket the board calls incomplete, do a 30-second git log origin/master -- <the files that ticket touches> check. Might save the whole dispatch.
If you're a fresh session/harness with zero context¶
- Read this file fully first.
git -C <repo root> log --oneline -5 origin/master— see what's landed since this doc was written (things move fast, multiple sessions active).- Check
docs/BOARD.md"Active sprint" section for⚪ Backlog/🔵 In Review/🟡 Needs Andrewrows — that's the real open worklist, cross-reference against this file's "paused" list above (some may have landed since). - Check whether the finish-line directive is still in effect — if you don't know, ask Andrew rather than assuming either way.
- Resume from "In flight" above if WW-83 is still open; otherwise pick up the paused queue in the order listed, one worktree + one fleet-model dispatch at a time, verifying-before-trusting at every landing step like the WW-74 lesson above.