Skip to content

WT-e833 · WING-454 · Egress disclosure UI, reading from the registry rather than prose

Updated: 2026-08-08T23:08:33Z Status: NOT STARTED (accepted, uncontended)

This lane landed five tickets today (WING-420, WING-403, WING-429, WING-424, plus a docs fix) and has one accepted-but-unstarted ticket. Sections 5–8 carry findings that would be expensive to re-derive; read those even if you pick up something else in this lane.

1. Goal

WING-454. The egress disclosure page must state what data leaves the machine by READING EgressSurfaceRegistry, not by restating it in hand-written prose. Done = a reader sees a list generated from the registry, and a producer added to the registry appears on that page without anyone editing copy. WING-430 found five live producers missing from the registry, so the disclosure and the reality had already drifted — a hand-maintained disclosure is a claim nobody re-checks.

Prior work in this lane (all LANDED on master): a set search filter is a promise about every row it lists (WING-372); a source that could not answer is not a source that found nothing (WING-403); cloud clients hit the server rather than the user's own machine (WING-420); USAJOBS/Jooble are configurable at all (WING-429); the survey gate stops being sampled once (WING-424).

2. Where the work is

  • Worktree for WING-454: NOT CREATED. Branch from origin/master.
  • Repo: C:\Users\fives\source\repos\WorkWingman
  • PR: NONE
  • Uncommitted right now: NONE in any landed worktree. One dirty worktree, unrelated to WING-454 — see below.

Existing worktrees in this lane (all landed, all clean, all safe to remove):

Worktree Branch Landed as
_worktrees/WT-e833-search-filters wt/WT-e833/search-filter-honesty WING-372 → f4fd03e72
_worktrees/WT-e833-wing403 wt/WT-e833/WING-403-source-outcome 8bea2dfe5 + 03aa20f42
_worktrees/WT-e833-wing420 wt/WT-e833/WING-420 1a9e98847
_worktrees/WT-e833-wing429 wt/WT-e833/WING-429 40d970954
_worktrees/WT-e833-wing424 wt/WT-e833/WING-424 5cb6f850d

_worktrees/WT-e833-wing373 is DIRTY and is NOT abandoned work you should delete. It holds an unfinished WING-373 (cross-source paging) start, on a stale base (f4fd03e72):

 M src/WorkWingman.Core/Models/JobSearchCriteria.cs
 M src/WorkWingman.Infrastructure/Sources/AdzunaSource.cs
?? src/WorkWingman.Core/Models/JobSearchCursor.cs      <-- untracked, the substantive piece

JobSearchCursor.cs is a designed-but-unused opaque cursor (per-source page positions, SkipInFirstPage, SeenKeys, base64 encode/decode, malformed token falls back to Start rather than failing). It is untracked, so a git clean destroys it. Either commit it on a WING-373 branch or copy it out before touching that worktree.

3. State — what is TRUE, with receipts

World state (from WT-0f7d): master GREEN at cd661d86c — all 13 CI jobs, and my two-track docs fix is in that green tree. CI now runs on EVERY pushed branch, so a branch no longer has to reach master to be judged. Cloud live on prod/qa/ww-yc/ww-spc at digest 953c59b1.

Cross-lane items landed today that touch this lane's files — read before editing them:

  • Adblock class closed structurally: wt/WT-429s/WING-429-structural @ 207812d1e renames the tracker-shaped controllers and adds a mutation-proven CI gate. It touches api.service, survey.service and telemetry.service — all three of which THIS lane also changed today (WING-420, WING-424). Expect conflicts there and rebase before assuming your version is current.
  • WING-458 ruling (WT-0f7d's, recorded so it is not silently re-litigated): the apply path has no destination allowlist — nothing at the browser boundary stops a real employer being contacted. It does NOT block deploys: pre-existing, ships today, and no current PR widens it. Escalated to Andrew separately, on the principle that exposure is not consent. Do not treat this as an open question to re-decide; treat it as a known, accepted, escalated exposure.

Landed and verified by me:

Claim Receipt
WING-424 on master git log --oneline origin/master → 5cb6f850d; vitest 135 files / 2034 passed | 2 skipped; ng build --configuration production exit 0
WING-429 on master 40d970954; dotnet build 0 errors; ApiKeyProviderRegistryTests 40/40; ladder contract green
WING-403 on master 8bea2dfe5 + 03aa20f42; WorkWingman.Tests 6090/6091
WING-420 on master AND deployed 1a9e98847; WT-0f7d grepped the SERVED bundle: exactly one 127.0.0.1:5211 remains, it is the api-base constant, zero call sites
USAJOBS secret now parses read back workwingman-usajobs-api-key v2 → parts=2 -> TryParse OK, part 1 is an email: True, part 2 non-empty: True (shape only; value never printed)
Secrets mounted on ww-team / ww-yc / ww-spc gcloud run revisions describe → Ready True on ww-team-00042-5gc, ww-yc-00015-6jv, ww-spc-00020-s2l. Pilot access re-verified by WT-0f7d against the current verifier d32dd9534 (versions enabled and unchanged, session key READABLE — stronger than "mounted" — ceilings 1000). An earlier version of this row credited f5cfa24f8, which is dangling; the CONCLUSION held, but only the d32dd9534 run is evidence for it
My docs sibling landed git show origin/master:docs/plain/job-search-filters.md returns content

UNVERIFIED, and what would verify each:

  1. WING-420's CSRF path on a real cloud session. Needs an authenticated session. An agent must REFUSE this — see §5. Verified only by unit contract tests + a local production bundle served on 127.0.0.1:8079.
  2. WING-403's source-status UI on a deployed revision. The peer click-through that was meant to verify this was killed with ZERO output and is UNRUN (§7) — so this is an OPEN gap, not a pending one. Verifiable by an agent: WING-423 removed the single dev-slot contention, and this needs no credential (the source table is reachable without signing in on a locally served build). Nobody is on it.
  3. Jooble flipping to a count. Predicted to flip on ≥40d970954 now that the registry entry, the mount and the IAM grant all exist. If it still reads "not set up", suspect a sibling service-account gap, NOT the registry entry.

4. Next actions, in order

  1. Create the WING-454 worktree off current master. Accept: git worktree add succeeds, git log -1 matches origin/master.
  2. Read EgressSurfaceRegistry and the existing disclosure page. Accept: you can name every field the page needs and which registry property supplies it.
  3. Render the page FROM the registry. Accept: adding a producer to the registry changes the rendered page with no copy edit. Prove it by adding a fake producer in a test and asserting it appears — a page that merely looks generated is the failure mode.
  4. Guard test that the disclosure cannot silently drift. Accept: reintroduce the defect — remove a producer from the rendered output while leaving it in the registry — and watch the test FAIL. A guard unproven by a mutation is decoration (§ the standard's last rule).
  5. Click it through. WING-423 removed the single dev-slot contention, so a worktree can serve its own port now. Never bind 5211 (Andrew's installed app) or 4200. Accept: screenshot of the rendered page + the network/console read.
  6. PR onto master, council-review the diff, CI green on its own merits.

5. Blockers — what an agent must REFUSE

  • Signing in to prod/pilot to verify WING-420's CSRF path. Reaching those screens needs an invitation code or Google OAuth — credential entry into a live surface. REFUSE IT. No amount of RAM or a better box changes what the action is. Owner: Andrew. Do not accept "agent browser-verifies X on prod" as an acceptance criterion; escalate to WT-0f7d instead.
  • Writing credential VALUES. I composed the USAJOBS email|key secret in-pipeline so the value was never printed, and that was the right shape. Do not paste a credential into a command line, a file, or a transcript.
  • Editing pilot/prod Cloud Run config directly. Route through WT-0f7d (single writer). If you ever must: --update-secrets (MERGES) and NEVER --set-secrets (REPLACES — silently unmounts an invitation hash and locks reviewers out), then run the strong pilot-access verifier — d32dd9534 on wt/WT-3145/WING-316-gate-followups, taken WITH its matching pilot-access-baseline.json. Script and baseline must come from the SAME sha.

Do not use ac08e0810 or f5cfa24f8. ac08e0810 false-PASSes on an ENABLED-but-EMPTY secret version. f5cfa24f8 was broadcast to me as the fix and is on no branch at all — a dangling pre-rebase commit missing rounds 3 and 4; I verified this myself (git branch -r --contains f5cfa24f8 → empty; d32dd9534 → origin/wt/WT-3145/WING-316-gate-followups). A wrong-but-plausible sha is worse than no sha, because it survives review by looking specific. If you are handed a verifier sha by anyone, check it is reachable from a branch before trusting it.

6. Traps in this lane

  • /(^|[^:])\/\/.*$/gm IS NOT A SAFE COMMENT STRIPPER. I published it as sound and it is not: it eats regex literals like /^[a-z]+:\/\// — four shipped files have that shape — deleting the rest of the line. Proven by poisoning skill-builder.ts:128 and layoff-evidence.ts:40 with a loopback literal and watching the guard stay silent. Across src/app the two strips deleted 12.7% of all scanned text. Use a TypeScript AST walk (ts.createSourceFile + ts.forEachChild, collecting string/template literals and identifiers). See frontend/src/app/core/api-base-usage.spec.ts.
  • Assert.All passes VACUOUSLY on an empty collection. My own WING-403 test adaptation read .Jobs then Assert.All, so a Failed outcome would have turned every happy-path test green while the adapter returned nothing. Assert the OUTCOME before reading the rows.
  • A reflection-driven [Theory] with zero cases PASSES. Assert discovery found the expected members by name, or a rename silently empties the whole guard. Generalised countermeasure for this and the Assert.All trap above: assert the COUNT, not just the contents — every "check the things" assertion needs a companion "and there were things".
  • A sha handed to you can be dangling. f5cfa24f8 was broadcast fleet-wide as the corrected pilot verifier and is on NO branch — a pre-rebase commit that will be garbage-collected, missing two rounds of fixes. It looked authoritative precisely because it was specific. Before acting on any sha someone gives you: git branch -r --contains <sha>. Empty output means it is not real work you can rely on, however confidently it was cited.
  • A killed dispatch reports nothing, and silence reads as pending. A peer job in this lane was killed with a session, captured zero output, and was described as in-flight for hours. Before waiting on any dispatched work, confirm it is RUNNING; "no result yet" and "it died" are indistinguishable from the outside, and only one of them ever resolves.
  • A fresh worktree fails the E2E suite in ~43 ms because no frontend build is present. That is an environmental failure wearing a code failure's clothes; using it as a "known good" baseline "proves" regressions that do not exist. Check the DURATION.
  • ApiSmokeTests has an order-dependent flake that ALTERNATES which test fails (DataBackupExport one run, JobSourcesResync_FromTrustedDevOrigin the next); both pass in isolation. A second flake exists in vitest (a job/discovery spec). Do not attribute either to your change without running it in isolation first. Tracked on WING-425.
  • Local green is NOT a green build. I landed four tickets reporting them green and never read CI; all four runs had failed. CI runs docs two-track, orphan-link, determinism, gitleaks and E2E gates no local suite covers. gh run list --branch <b> then gh run view <id> --log-failed.
  • Greatroom has ~1 GB free RAM. vitest worker startup times out; --pool=forks survives where the default threads pool does not. Heavy suites belong on streaming (ssh fives@10.0.0.26, 68 GB).

7. Delegated / dispatched work

I dispatched no fleet-harness jobs. Nothing of mine is in flight, and there is nothing of mine for you to re-dispatch.

Council seats I ran were local CLI invocations (codex review --uncommitted, agy, grok -p), all completed and read, outputs under …/scratchpad/wing372|wing403|wing420|wing424|wing429/. Scratchpad is session-local and will not survive; every finding that mattered is in the commit messages and Jira comments.

UNRUN — NOT in flight, NOT pending results (corrected 2026-08-08 by WT-0f7d). A peer click-through on streaming was to exercise WING-403 source status. It was KILLED when a previous session ended, captured ZERO output, and was never re-run. An earlier version of this section called it "in flight"; that was wrong and would have had you waiting on a phantom. This work is available for whoever wants it.

The design is worth reusing, because it makes the click-through an experiment rather than a look-and-see. State the predictions BEFORE looking, so the observation cannot be rationalised:

  • USAJOBS → a real COUNT. Its secret is mounted and it was already in the registry.
  • Jooble → "not set up" on any revision older than 40d970954; a count on newer, now that the registry entry, the mount and the IAM grant all exist.

Those two disagreeing IN THAT DIRECTION is the receipt. Require the report to name the exact status-label AND the revision observed on. "Shows a count" alone confirms nothing — a stale cached number, or a count rendered for a source that actually returned nothing, both satisfy it while being exactly the conflation WING-403 exists to delete. If only the pre-auth screen is reachable, the answer is NOT RUN for both sources, never a partial read of one.

8. Decisions made and why

  • JobSourceResult is Ok / NotConfigured / Failed (WING-403). WT-b845 proposed Fetched / NoResults / Broken for WING-436; we agreed on four: Fetched / NoResults / NotConfigured / Broken. NoResults is their improvement (a POSITIVE "looked and found nothing", which Ok-with-empty-list cannot express). NotConfigured must survive any rename — it is user-actionable ("add an API key") where Broken is not, and it is what made Jooble's dead state visible. A reason field on Broken was considered and REJECTED: a field a caller may ignore is weaker than a case a switch must handle.
  • The seven-link Jooble chain. Adapter, signup path, provisioned secret, mounted value, registry entry, ConfigKey, IAM grant — any one missing produces the identical symptom ("not configured", indistinguishable from a user who never set it up). ApiKeyProvider.Get returns null for an unknown registry id BEFORE consulting vault or config; that lookup is the seam that decides. Clearest presence-vs-reachability case we have.
  • Readiness proves everything a container needs to BOOT and nothing it needs to WORK. A missing IAM grant stops the revision starting, so readiness IS evidence there. A clobbered secret boots perfectly with the capability gone, so readiness proves nothing there. Do not flatten this into "healthy means nothing" — that would teach distrust of a signal that is sometimes exactly right.
  • Evidence-required filtering (WING-372): a set criterion is a promise about every row in the list. Rows without observed evidence go to a separate, counted, opt-in bucket; rows the source CONTRADICTED are dropped. "The source says no" and "the source never says" are different facts.
  • Adzuna salary is a model PREDICTION (salary_is_predicted="1", min == max on every captured row). A design council recommended pushing a salary floor down to Adzuna; I REJECTED it with the capture as the receipt. Do not re-adopt that recommendation.
  • Telemetry drops its buffer and re-mints its session id on tenant change (WING-420). Without it, a logout inside the 15 s flush window sends tenant A's events — job and run ids — under tenant B's cookie, stamped as B.
  • The survey gate probe is latest-wins and fails closed on sign-out (WING-424). Two overlapping probes let a slow boot 401 land after a fresh true and re-disable surveys for the whole session.
  • WING-425 and WING-373 are UNSTARTED and unclaimed by me. WING-454 is accepted and unstarted. Nothing in this lane is silently in flight.