tracking: HAR capture and scrub -- controller queue, ordering, and in-flight work

[MarkMichaelis]

Tracking issue for the HAR capture-and-scrub work being run by a controller
session across two repos. Not a design document — every design decision
lives on the issue that owns it. This exists so the queue, its ORDERING, and the
reasons for that ordering survive a session crash or a handover.

• UPSTREAM IntelliTect-Samples/IntelliSDLC.ai
• CONSUMER MarkMichaelis/CodiwomplerSocialMedia

origin in this repo points at the old org name IntelliTect-Dev and redirects.
Always pass --repo IntelliTect-Samples/IntelliSDLC.ai.

---

The rule that orders the queue

A WIDENING change lands after the NARROWING change that constrains it.

IntelliTect-Samples/IntelliSDLC.ai#360 identifierFields alignment (narrowing)  ->  IntelliTect-Samples/web-api-discovery#57, IntelliTect-Samples/IntelliSDLC.ai#344 (widening)  ->  IntelliTect-Samples/web-api-discovery#55

Widening first puts a newly-visible population on the REPLACE path with nothing
suppressing the false positives among it — the 20-of-22 object-id corruption
measured in IntelliTect-Samples/web-api-discovery#56, applied to a fresh node class. This is beat 6 of
docs/designs/297-detector-predicates.md, and it is the single most important
constraint on this queue.

---

In flight

Item	PR	Author	Reviewer	State
#360 scrubber stops replacing at declared identifier fields	#364	Opus	Sonnet	in review
#358 gate a request body that was REPLACED, not shortened	#362	Opus	Sonnet	re-review after 2 accepted Important findings
#367 + #366 capture durability, and --describe required	—	Opus	Sonnet	authoring

#360 is the gate on the consumer audit. audit-scrub-drift.js's own
provisionalReasons() prints that its CLEAN and CORRUPTED verdicts are
provisional until this lands. UNADJUDICABLE is unaffected and is trustworthy
today.

One decision still open, on #364

When the same value sits at a declared identifier field in one place and a plain
field in another, the PR promotes it back and REPLACES it everywhere.
audit-scrub-drift.js's verdictFor calls that same case UNADJUDICABLE and
refuses to guess, "because picking one would be a guess with a repair behind
it." Beat 2 says an uncertain predicate on a replace path should fail toward a
MISS. Under review; the controller decides, not the author.

---

Done

• #766's three orphaned Important findings (consumer): already filed as
  MarkMichaelis/CodiwomplerSocialMedia#809, #810, #811 on 2026-08-29 — two days
  before the issue asserting they were never filed. Verified still true of the
  code, then recorded on #862. No duplicates created.

---

Deferred, deliberately — not dropped

• #355, IntelliTect-Samples/IntelliSDLC.ai#351 block on IntelliTect-Samples/web-api-discovery#59 Stage 10's provenance stamp. The contract is
  agreed and firm: log._scrubPolicy carrying
  { version, scrubbedAt, disabledIdentityClasses }, written LAST so presence
  means a completed scrub, replaced rather than appended, carrying no values.
  Refuse on PRESENCE, never on content. Stage 10 is unstarted and may be
  unowned.
• #330, IntelliTect-Samples/IntelliSDLC.ai#344 — widening. Queued behind fix(web-api-discovery): the scrubber replaces at declared identifier fields the gate agreed to allow #360 by the ordering rule above.
• #339, IntelliTect-Samples/web-api-discovery#58, IntelliTect-Samples/IntelliSDLC.ai#341, IntelliTect-Samples/web-api-discovery#54, IntelliTect-Samples/web-api-discovery#50, IntelliTect-Samples/web-api-discovery#48 — unassigned, none blocking.

---

Consumer queue — CodiwomplerSocialMedia#862

Held until the upstream items above merge, and in this order:

1. Sync IntelliSDLC (roughly 70 commits behind). Deliberately not started yet
   — syncing before fix(web-api-discovery): the scrubber replaces at declared identifier fields the gate agreed to allow #360/fix(web-api-discovery): no gate detects a reference whose request body was wholly replaced by a placeholder #358/fix(web-api-discovery): recording from a worktree writes raw captures where worktree cleanup destroys them #367 merge would pull a tree without them and
   force a second sync.
2. Run audit-scrub-drift.js over docs/har-reference/.
3. Re-order the rest of #862 against what the audit finds. #862 says
   explicitly not to plan off its numbers without re-running.

Its defect 1 (a request body that is only a redaction sentinel) is being fixed
upstream as #358 on purpose, so the consumer inherits it by sync instead of
maintaining a second guard that drifts.

Non-scrub work on #862 — the Facebook and Instagram conformance reviews — does
not block on upstream but is held until the audit re-orders the list.

---

Incident: a raw capture was permanently destroyed

71 MB, 666 entries, recoveredFromSnapshot: true, no description. It sat in
a consuming project's worktree at .worktrees/<issue>-<name>/.har-captures/ and
was deleted by a routine git worktree remove from a concurrent session.
git worktree remove deletes outright — nothing reached the Recycle Bin and no
copy existed. Not recoverable.

Two upstream defects made it possible, both now filed:

• fix(web-api-discovery): recording from a worktree writes raw captures where worktree cleanup destroys them #367 — the recorder writes .har-captures/ relative to the working
  directory, so recording from a worktree puts captures one routine cleanup away
  from deletion. The files are gitignored, so git reports nothing to lose and the
  operator gets no signal at any point. SKILL.md's claim that the raw capture
  is "confined to .har-captures/ by construction" is true about the NAME and
  silent about WHICH one.
• fix(web-api-discovery): a capture can be recorded with no description, leaving it unidentifiable in a shared store #366 — --describe is optional (capture-har.js:1717,
  describe: args.describe || null), so the capture was also unidentifiable.
  The bytes could in principle be re-captured; what the operator was doing
  could not. Now approved to become a required input.

Mitigation already in place, outside these repos: the full 8.42 GB store is
mirrored to C:\temp\har-capture\har-captures-mirror (257 files, verified
file-by-file), with a CAPTURE-INDEX.md carrying each capture's description,
size and SHA-256 — the hash being the durable link that survives a rename or
a move. A sweep of every worktree in both repos found no other at-risk capture.

The operational lesson, recorded because it is the reusable part: preserve
first, ask afterwards. The capture was identified as at-risk and then lost while
a question about how to LABEL it was outstanding. Copying is cheap and
reversible; deliberation is not free when another session holds the delete.

---

Invariants enforced on every worker

• REVIEWER != AUTHOR, MECHANICALLY. A subagent spawned without an explicit
  model override INHERITS the authoring model, which is self-review in costume.
  Both models are assigned explicitly and the reviewer's model is recorded per
  PR. Opus authors, Sonnet reviews; the invariant is difference, not those names.
• ABLATE EVERY ASSERTION. Break what it checks, watch it fail. Six tests in
  this subsystem shipped satisfied by something other than what they named —
  including one asserting typeof fieldTypeFor === 'function' with the message
  "so a project cannot extend it", which passed FIVE review rounds while nothing
  ever passed a policy. Mutation found all six; re-reading found none.
• Falsifiers and guards labelled separately. A test that passes on arrival is
  a guard, not evidence.
• A generator that cannot express a shape cannot falsify it. Seed it with the
  shapes ADJACENT to the one being fixed.
• Measure the residue, not the delta. 2,841 -> 176 and 1,224 -> 94 are both
  true and both misled.
• A review is ADVISORY. Triage each finding; accept and fix, or reject with a
  rationale validated against the code. Never auto-apply. Any accepted
  Critical/Important routes back to TDD and the reviewer re-reads before merge.
• Never print a detected value — finding, log, error, test failure, PR body,
  dry-run report. Kind, class, key path, entry index, count, non-reversible
  fingerprint only.
• Nothing under .har-captures/ is deleted, except by an operator's explicit
  -RemoveSource on a VERIFIED scrub.
• No new command-line options without explicit human approval, including in
  autopilot. (fix(web-api-discovery): a capture can be recorded with no description, leaving it unidentifiable in a shared store #366 makes an EXISTING flag required, which was approved.)
• Worktree + feature branch, never main. Never git add -A — a reviewer's
  scratch file was once swept into a commit that way and would have shipped to
  every consuming project.
• Green before merge; rebase merges only.

Environment notes that cost time to rediscover

• Node tests reach CI ONLY via a Pester wrapper in .github/agents/tests/;
  node-test-coverage.Tests.ps1 fails when one is missing. Local
  Invoke-Pester -Path .\.github\agents\tests\ is ~47 files, NARROWER than CI's
  .\.github at ~51 — always name which scope a result came from.
• node --test <dir> fails on Node 26; pass an explicit file list.
• gh on Windows garbles Unicode and collapses newlines in inline body text.
  Always --body-file.
• Never verify against a worktree another agent owns — it may be mid-edit and
  git log will not warn you. Pin with git show <sha>:path.
• Peer sessions work these repos concurrently. Check git log origin/main and
  the session list before dispatching; treat any stage list as a claim to
  verify, not a fact.

[MarkMichaelis]

Status update — the merge order changed, and #364 is now blocked

The queue in the issue body is superseded on one point: #360 / PR #364 can no
longer merge first. A dependency was discovered during review that did not
exist when this issue was written.

The new blocker: #369 became load-bearing

#369 (the gate reads HAR envelope property names as captured field names) was
filed as a pre-existing defect that could wait. It cannot.

PR #364's whole safety argument is a composition: the scrubber fails toward a
miss on a mixed-evidence value, and the gate refuses to pass what the scrubber
declined. That makes the gate a backstop for the first time — so a gate that
wrongly suppresses is now a leak path, not a reporting nuisance.

Reproduced against PR #364's head. A card-shaped value at body media_id, echoed
in an HTTP header:

identifierFields = shipped default
    scrub: declines, mixedEvidence=true
    gate : [{idf:false, path:"request.headers[0].value", blocks:TRUE }]
    real value ships unblocked?  NO      <- correct

identifierFields + "*value"
    scrub: declines, mixedEvidence=true
    gate : [{idf:true,  path:"request.headers[0].value", blocks:FALSE}]
    real value ships unblocked?  YES     <- the leak

request.headers[0].value yields the field name value, so under a colliding
project pattern both occurrences look like identifier hits, the gate's
promotion-back rule never sees a false, and blocksLeak returns false. The
scrub declines, the gate passes, and sanitize-har promises a verify failure
that never arrives.

The direction is what makes this blocking. On main today that value would be
REPLACED. #364 therefore converts a corruption into a leak under that
configuration. It does not trigger under the shipped default policy.

Revised order

IntelliTect-Samples/IntelliSDLC.ai#369  (gate: envelope names are not field names)   <- must land first
  -> rebase IntelliTect-Samples/IntelliSDLC.ai#364, re-verify the composition
  -> IntelliTect-Samples/IntelliSDLC.ai#364  (scrubber declines at identifier fields)
  -> IntelliTect-Samples/web-api-discovery#57, IntelliTect-Samples/web-api-discovery#52 (widening)
  -> IntelliTect-Samples/web-api-discovery#55

#362 is independent of all of this — different file
(verify-har-reference.js) — and can land on its own.

A methodological note worth keeping

The first probe run against this leak said there was no leak, and that was a
harness artifact, not a result. The merged policy object is frozen, so
p.identifierFields = [...] after loadDefaultPolicy() silently does nothing,
and identifierMatchers additionally caches compiled matchers in a WeakMap
keyed on the policy object. A real defect was nearly cleared on a probe that
never exercised it.

Any test or probe that varies policy must assert the policy is live — e.g.
isIdentifierField(p, 'value') === true — before drawing a conclusion from the
run. This belongs in the tests, not in anybody's habits.

In flight, current

Item	PR	Head	Author	Reviewer	State
#358 hollow request body	#362	75ea057	Opus	Sonnet	final review; independent, can land alone
#369 envelope field names	—	—	Opus	Sonnet	authoring; blocks #364
#360 identifier-field scrub	#364	73b0275	Opus	Sonnet	blocked on #369; otherwise complete
#367 + #366 capture durability	—	—	Opus	Sonnet	authoring

Verification recorded on the heads reviewed:

• fix(web-api-discovery): the scrubber stops replacing at declared identifier fields #364 @ 73b0275 — Invoke-Pester -Path .\.github (CI scope, 51 files):
  667 passed, 0 failed, 5 skipped. Run twice independently — by the author,
  and by the controller in a separate detached worktree. Identical.
• fix(web-api-discovery): fail a reference whose request body was replaced, not shortened #362 @ 75ea057 — same scope: 668 passed, 0 failed, 5 skipped, plus CI
  green on the exact commit in 2m12s.

A green suite did not and could not catch the #369 composition leak: #364's
property test and its 7.a/7.b/7.c cases all run under the default
policy, so none of them exercises a colliding project pattern. That gap is
#369's falsifier to close.

New issue filed since this was written

• fix(cleanup-worktree): removing a worktree destroys gitignored data with no check, and the ignored-file blindness is why #370 — Cleanup-Worktree.ps1 removes a worktree without checking for
  gitignored data, and the ignored-file blindness is why. Second line of defence
  behind fix(web-api-discovery): recording from a worktree writes raw captures where worktree cleanup destroys them #367. Includes a verified reparse-point hazard: the mitigation one
  consuming project uses is a Junction, and Windows PowerShell 5.1's
  Remove-Item -Recurse follows junctions and deletes the target's contents.
  A repo-wide grep found zero powershell.exe references, so there is no
  automated path for it to fire — the exposure is a human or an agent typing it.

Data preservation carried out

• The full raw store (8.42 GB, 257 files) is mirrored outside both repos, with an
  index carrying each capture's description, size and SHA-256 — the hash being
  the durable link that survives a rename or a move.
• A second at-risk artifact was found and preserved before loss: a capture branch
  in a consuming project was ahead 2, with run-level provenance for 23
  captures existing only on one disk. Bundled (verified complete history) plus
  loose copies. Pushing it is the owner's call and remains outstanding — a
  bundle on the same volume is a stopgap, not durability.

[MarkMichaelis]

Upstream queue complete — all four PRs merged, IntelliTect-Samples/web-api-discovery#57 and IntelliTect-Samples/IntelliSDLC.ai#344 now unblocked

Every item this issue was opened to track has landed. main is 13 commits ahead
of where this run started.

PR	Closes	Author	Reviewer	Rounds
#362	#358	Opus 5	Sonnet 5	4
#373	#366, #367	Opus 5	Sonnet 5	2
#374	#369	Opus 5	Sonnet 5	2
#364	#360	Opus 5	Sonnet 5	3

Every PR was rebase-merged with CI verified on the exact reviewed head —
checked by head_sha on the check-runs rather than by check name, because a
green run against an earlier head is indistinguishable from a green run against
this one if you only read the name.

The ordering rule held, and it changed mid-run

The queue in the issue body was:

IntelliTect-Samples/IntelliSDLC.ai#360 (narrowing) -> IntelliTect-Samples/web-api-discovery#57, IntelliTect-Samples/IntelliSDLC.ai#344 (widening) -> IntelliTect-Samples/web-api-discovery#55

It became, once review found the dependency:

IntelliTect-Samples/IntelliSDLC.ai#369 -> IntelliTect-Samples/IntelliSDLC.ai#360 -> IntelliTect-Samples/web-api-discovery#57, IntelliTect-Samples/IntelliSDLC.ai#344 -> IntelliTect-Samples/web-api-discovery#55

Why #369 became a blocker. #360 makes the gate the BACKSTOP for values the
scrubber declines to replace. That is a new role: before #360, a gate that
wrongly suppressed was a reporting nuisance; after it, the same suppression is a
leak path. Measured on #364's own head:

identifierFields = shipped default
    scrub declines (mixedEvidence)   gate BLOCKS      value ships: NO
identifierFields + "*value"
    scrub declines (mixedEvidence)   gate PASSES      value ships: YES

request.headers[0].value yields the field name value, so under a colliding
project pattern both occurrences looked like identifier hits, the gate's
promotion-back rule never saw a false, and it passed. On main at the time
that value would have been REPLACED — so #360 alone would have converted a
corruption into a leak. That direction is what made it blocking rather than a
follow-up.

The composition now holds end to end, verified on the merged result:

A   {media_id}                     kept  subs=0            gate BLOCKS: no
B   {media_id, price_note}         kept  subs=0  mixed     gate BLOCKS: YES
B'  {price_note, media_id}         kept  subs=0  mixed     gate BLOCKS: YES   (order-independent)
C   {price_note}                   replaced subs=1         no finding
D   {media_id} + header echo, identifierFields + "*value"
                                   kept  subs=0  mixed     gate BLOCKS: YES   <- the IntelliTect-Samples/IntelliSDLC.ai#369 case

Residue, not delta

• fix(web-api-discovery): the scrubber replaces at declared identifier fields the gate agreed to allow #360: on the 400-document generated corpus, 468 of 770 sites (61%) are
  still rewritten; 302 declined. The first cut of this change declined only 46.
  Reproduced independently from the generator seed by the reviewer. Explicitly an
  artifact of uniform generator placement, not a prediction about a real
  capture — there is no real corpus in this repository.
• On the repo's 10 planted fixtures: 41 replace sites, unchanged.
• fix(web-api-discovery): no gate detects a reference whose request body was wholly replaced by a placeholder #358: 208 real request bodies classified across 12 captures by the
  controller, 755 across 14 by the author. Zero belonged to no grammar, and
  no real body had fewer than two interior separators — which is what licensed
  deleting the punctuation heuristic rather than retuning it.

What was learned, in the form that survives

Recorded here rather than in a design doc because these are about METHOD, and
docs/designs/297-detector-predicates.md is closed by its own instruction.

1. A green suite is not evidence the suite can fail. #364 passed 667 tests,
run twice independently, while carrying the #369 composition leak — because its
property test and all three composition cases ran under the DEFAULT policy, so
none could express the colliding case.

2. A new test whose ablation kills a different test is not pinned. 8.a,
titled for the #369 case, threaded its policy into the scrub and then asserted
against the default policy at the gate. It passed with the defect reintroduced.
The tell was visible and missed by both author and controller: the mutant that
should have killed it reported a kill set that did not include it.

3. The fix for that was restriction, not correction. gateBlocks's policy
parameter is now REQUIRED with no default. Correcting the one wrong call site
would have left the next one free to repeat it; removing the default makes the
mismatch unexpressible. Beat 4, applied to a test harness.

4. Generator breadth is load-bearing. Demonstrated cleanly: narrow #364's
generator so it cannot emit a top-level array, and its property test STOPS
catching a regression that reintroduces #374's gap, while a dedicated case still
does. A property test that cannot express a shape is a case list wearing a
property's name.

5. A mutation that changes nothing is an absent test wearing a green tick.
Four NO-OP mutants were found in #362's matrix — three were "\s" in a JS string
being just s. A matrix reporting "all assertions covered" was partly reporting
on mutations that never altered behaviour.

6. A loud mutant hides a quiet case. #373's subdirectory anchoring was
unpinned because the mutant covering it broke several other shapes noisily, so
the sub-case never got its own probe. Attribution needs a mutant scoped to each
behaviour, not a kill count.

7. Probes need their own sanity checks. A controller probe reported NO LEAK
for a defect that was real: the merged policy object is FROZEN, so
p.identifierFields = [...] silently no-ops in sloppy mode, and
identifierMatchers caches compiled matchers in a WeakMap keyed on the policy.
Any test or probe that varies policy must assert the policy is live before its
result means anything. That is now a test in the shipped suite, not a habit.

Filed and still open

• fix(web-api-discovery): the scrub audit treats a header/cookie/query name as a JSON field name, adjudicating correct scrubs as CORRUPTED #375 — the scrub audit reads a header/cookie/query NAME as a JSON field
  name, adjudicating correct scrubs as CORRUPTED. Different mechanism from fix(web-api-discovery): the gate reads HAR envelope property names as captured field names, so one policy entry disables header/cookie/query reporting #369.
  Offline diagnostic; degrades audit accuracy rather than leaking. #862
  re-orders work against that audit, so this matters to the consumer.
• #376 — isIdentifierShaped enforces its restriction by caller convention
  rather than at the function boundary. Latent; both current callers are correct.
• #330, IntelliTect-Samples/IntelliSDLC.ai#344 — the widening changes. Now unblocked, in that order.
• #339, IntelliTect-Samples/web-api-discovery#58, IntelliTect-Samples/web-api-discovery#53, IntelliTect-Samples/web-api-discovery#54, IntelliTect-Samples/web-api-discovery#50, IntelliTect-Samples/web-api-discovery#48 — unassigned, none blocking.
• #355, IntelliTect-Samples/IntelliSDLC.ai#351 — still blocked on IntelliTect-Samples/web-api-discovery#59 Stage 10's provenance stamp, unstarted.

Consumer next steps — CodiwomplerSocialMedia#862

The sync is now worth doing, and only now: audit-scrub-drift.js's CLEAN and
CORRUPTED verdicts were PROVISIONAL until the identifierFields alignment landed
in pii.js, which it now has. UNADJUDICABLE was always trustworthy.

Order: sync -> run the audit -> re-order the remainder of #862 against what it
finds. #862 says explicitly not to plan off its numbers without re-running.

Read #375 before acting on any CORRUPTED verdict — that defect manufactures
CORRUPTED where the truth is CLEAN, for values under identifier-named headers.

#862's defect 1 (a request body that is only a redaction sentinel) is fixed
upstream by #358/#362 and arrives with the sync. It should NOT be hand-rolled
downstream.

Data preservation, carried out during this run

A raw capture was permanently destroyed mid-run — 71 MB, 666 entries — by a
routine worktree cleanup from a concurrent session, because the recorder wrote
.har-captures/ relative to the working directory. Not recoverable. #367 (the
placement fix) and #366 (--describe required) are merged; #371/#372 (the
deletion-side guard) were implemented separately by the session that caused it.

Also carried out, outside both repositories: the full 8.42 GB raw store mirrored
with an index carrying each capture's description, size and SHA-256; and a second
at-risk artifact found and bundled before loss — a capture branch that was
ahead 2, with run-level provenance for 23 captures existing on one disk only.
That branch has since been pushed with the operator's approval.

The operational rule, which is the reusable part: preserve first, ask
afterwards. The destroyed capture was identified as at-risk and then lost while
a question about how to LABEL it was outstanding.

[MarkMichaelis]

New queue — capture artifact placement, and Stage 10 finally tracked

Three issues filed from a live defect: a capture wrote scrubbed.har,
catalogue.json and digest.json to a consuming project's repository root
as an untracked, un-gitignored host directory.

Diagnosis: not the raw-placement problem #367 fixed. Raw is correctly
anchored to the main working tree. resolveDefaultOutputRoot
(lib/repo-workflow-guard.js:224) resolves OUTPUT through topLevelOf(dir), and
its own comment concedes the gap — "It makes placement PREDICTABLE, not correct.
The warning is what addresses correctness." The warning fired. The files landed
anyway.

Issue	What	Sequence
#377	Scrub output lands untracked at the repo root, is unstamped, and leaves no link back to its raw	first
#379	Make the committed reference catalogue structured, so a row's claims can be checked against the file	after #377
#381	Stamp scrub provenance into the artifact (#297 Stage 10), and define what an absent stamp means	independent; unblocks IntelliTect-Samples/web-api-discovery#49, IntelliTect-Samples/IntelliSDLC.ai#351

Two defects found while planning, neither in the original report

Output is not stamped. Raw is <host>/<stamp>/; output is <host>/ with
fixed filenames, so a second capture against the same host silently overwrites
the first scrubbed artifact.

No link from a committed reference back to its raw. This is why the audit
finds 0 of 29 references adjudicable in the consuming project: 1 of 88
preserved raws carries a substitution table, and it names a bare directory rather
than a committed filename. #377 records the promoted filename back into the
session, which creates that edge — and makes IntelliTect-Samples/IntelliSDLC.ai#381's retroactive re-scrub
findable.

IntelliTect-Samples/IntelliSDLC.ai#381 was extracted deliberately

Stage 10 sat unstarted and unowned inside IntelliTect-Samples/web-api-discovery#59 while IntelliTect-Samples/web-api-discovery#49 and IntelliTect-Samples/IntelliSDLC.ai#351 accumulated
behind it. It now carries the agreed contract unchanged, plus the retroactivity
rules that were never specified: back-stamping forbidden (a stamp written
onto an artifact some earlier policy produced is a false claim generated by a
tool); an absent stamp is a datum, meaning "pre-provenance, verdicts
provisional", rather than a gap; and re-scrub is the only honest upgrade path,
bounded by raw survival — IntelliTect-Samples/web-api-discovery#56 records that none of the 12 originally-committed
references kept theirs, so those can be re-captured or disclosed, never repaired.

One correction to this issue's earlier summary

An earlier update here implied the audit's CLEAN/CORRUPTED verdicts would stop
being provisional once #360 landed. They do not. #364 rewrote the reason
rather than removing it: a reference scrubbed BEFORE the alignment may carry
replacements today's rules would decline. That provisionality is a property of
old artifacts, not of missing code, and IntelliTect-Samples/IntelliSDLC.ai#381 is what makes it answerable.

[MarkMichaelis]

Session close — what merged, what is open, and what the next session must know

Recorded so nothing here depends on this session's memory.

Merged this run

PR	Closes	Author	Reviewer	Rounds
#362	#358	Opus 5	Sonnet 5	4
#373	#366, #367	Opus 5	Sonnet 5	2
#374	#369	Opus 5	Sonnet 5	2
#364	#360	Opus 5	Sonnet 5	3
#372	#371	peer (Opus)	Sonnet 5	2

All rebase-merged with CI verified on the exact reviewed head, checked via
head_sha on the check-runs rather than by check name — a green run against an
earlier head is otherwise indistinguishable from a green run against this one.

Open, in priority order

#384 — verified, frozen, unowned. Safe to merge.
Recognises the Copilot desktop worktree layout as safe, gated on
git worktree list registration rather than path shape. The authoring session
has closed. I verified four properties against it and they hold: my two #372
fixes are preserved; the capture-guard interleaving still holds (3 guards, 3
--force, correctly ordered); the reordered location check throws or falls
through and can never gate the capture guard; and param() is byte-identical
to main, so no new CLI option. Its body carries a post-merge action — see below.

#377 — placement. Plan approved, one question open.
Carries a design correction posted after planning: §5's promote step is wrong
as originally written. References are 3-60 KB trimmed extracts; raw captures
are 277 MB - 1.6 GB, and extract-har-reference.js already implements the
promote step including the <provider>-<action>-<yyyy-MM-dd>.har convention.
The open question — where --match comes from, since the extractor refuses to
run without a selector — is recorded as its own comment and must be settled
with the operator before §5 is implemented.

#379 — structured committed catalogue. Sequences after #377.
#382 — generated per-provider server API document. Sequences after #379.
#381 — IntelliTect-Samples/web-api-discovery#59 Stage 10 provenance stamp. Independent; unblocks IntelliTect-Samples/web-api-discovery#49 and IntelliTect-Samples/IntelliSDLC.ai#351.
#375 — the scrub audit reads a header/cookie/query NAME as a JSON field name,
adjudicating correct scrubs as CORRUPTED. Read before acting on any CORRUPTED
verdict.
#376 — isIdentifierShaped enforces its restriction by caller convention
rather than at the function boundary. Latent; both current callers are correct.
#330, IntelliTect-Samples/IntelliSDLC.ai#344 — the widening changes, now unblocked by #360. Note the finding
below before starting IntelliTect-Samples/web-api-discovery#57.
#339, IntelliTect-Samples/IntelliSDLC.ai#323, IntelliTect-Samples/IntelliSDLC.ai#341, IntelliTect-Samples/web-api-discovery#54, IntelliTect-Samples/web-api-discovery#50, IntelliTect-Samples/web-api-discovery#48 — unassigned, none blocking.

Findings the next session should not have to rediscover

#330's population is NOT covered by #360's narrowing. The ordering rule was
satisfied on paper by #360 landing, but for query strings specifically:
capturedFieldName resolves a query-string finding to the envelope word
value, and the field-name-gated detectors inside detectInValue
(person-name, city, region, dob, device-id) never call
atIdentifierField at all. The actual protection against the sort_city
class is #329's qualifier allowlist, not #360. Verify that allowlist covers
query-string naming conventions before widening.

The audit's verdicts stay provisional, permanently. #364 rewrote
provisionalReasons() rather than removing it: a reference scrubbed BEFORE the
alignment may carry replacements today's rules would decline. That is a property
of old artifacts, not of missing code. IntelliTect-Samples/IntelliSDLC.ai#381 is what makes it answerable.

0 of 29 committed references are adjudicable in the consuming project —
1 of 88 preserved raws carries a substitution table, and it names a bare
directory rather than a committed filename. #377's HarFile link is what closes
that.

Frozen policy objects. p.identifierFields = [...] after loadDefaultPolicy()
silently no-ops in sloppy mode, and identifierMatchers caches compiled matchers
in a WeakMap keyed on the policy. A controller probe reported NO LEAK for a real
defect because of this. Any test or probe that varies policy must assert the
policy is live first. This is now a test in the shipped suite, not a habit.

Post-merge action carried on #384

After #384 merges, delete markmichaelis/cleanup-safe-locations (ecba473).
git cherry will keep reporting it as carrying unique work because #384 is a
reimplementation, not a replay — patch-ids differ. A future audit would burn real
effort re-deriving the same conclusion.

Done already: its worktree is removed (clean, and clean under --ignored too),
and the branch is bundled at
C:\temp\har-capture\at-risk-branches\cleanup-safe-locations-ecba473.bundle
(verified complete history). The branch itself is retained until #384 lands.

Verify behaviourally before deleting — confirm main actually recognises the
Copilot layout. git cherry cannot tell you that; running it can.

Consumer — CodiwomplerSocialMedia#862

Still held, deliberately, and now worth doing:

1. Sync (108 commits behind; 79 touch HAR/scrub). Doing it once brings fix(web-api-discovery): fail a reference whose request body was replaced, not shortened #362,
   fix(web-api-discovery): the scrubber stops replacing at declared identifier fields #364, fix(web-api-discovery): recording from a worktree writes raw captures where worktree cleanup destroys them #367, fix(cleanup): refuse to remove a worktree holding raw captures #372, fix(web-api-discovery): put the raw capture where a worktree cleanup cannot reach it #373 and fix(web-api-discovery): the gate stops reading HAR's own property names as field names #374 together.
2. Run audit-scrub-drift.js — expect everything UNADJUDICABLE, for the
   structural reason above. That is itself the finding.
3. Re-order the rest of #862 against the result. #862 says explicitly not to plan
   off its numbers without re-running.

main is RED there — a video fixture was swapped on 2026-08-30 without updating
tests written the day before; three failing since. Flagged to the operator by the
peer session.

#862's acceptance item "file issues for #766's three orphaned Important
findings" is already satisfied — #809/#810/#811 were filed 2026-08-29, two
days before #862 claimed otherwise. Verified still true of the code and recorded
on the issue.

Method notes worth keeping

Six ways a standard command reports "nothing here" when something is there —
recorded on #372 by the peer session, with the code that acts on them:
git status --porcelain (omits ignored), ls (hides dot-directories),
git cat-file -e <rev>:.dotpath (false-negatives), git cherry/patch-id
(unreliable across a rename), an absent symbol (work can land under another
name), git diff counts on a stale branch (noise). Three of the six did or
nearly did damage today.

For code, check the behaviour. For data, preserve then decide — because the
check itself is destructive if wrong.

A refusal that is not obviously correct does not make people safer; it makes
them route around you. Eight worktrees were hand-removed under
copilot-worktrees because Cleanup-Worktree.ps1 refused them — and
hand-removal is how the 71 MB capture died. Gate on a verifiable FACT
(git worktree list registration), not on SHAPE (a path pattern). Reproduced
live this session: the script still refuses that layout pre-#384.

Attention is not the mitigation; mutation is. The peer wrote the six-proxy
list, was actively thinking about it, and still shipped a proxy assertion in the
same file — plus a test loader that would have passed every test against an empty
function table. Three in one file, by the person documenting the pattern.

Data preservation state

• Full raw store mirrored: C:\temp\har-capture\har-captures-mirror
  (257 files, 8.42 GB, verified file-by-file) with CAPTURE-INDEX.md carrying
  each capture's describe, size and SHA-256.
• Two branch bundles held at C:\temp\har-capture\at-risk-branches\.
• One capture was permanently destroyed this session — 71 MB, 666 entries — by a
  routine worktree cleanup, in the window between identifying it as at-risk and
  copying it. Preserve first, ask afterwards.

[MarkMichaelis]

Queue state refresh — 2026-09-01

The In flight table above is stale. Verified against origin/main and the
issue list just now:

Merged since it was written: #358, #360, #366, #367, #369, #370, #371.
That clears the two blocks the table records:

• fix(web-api-discovery): the scrubber replaces at declared identifier fields the gate agreed to allow #360 has landed, so the widening lane (#330, #344, then #339)
  is no longer gated by the ordering rule. It is unstarted and unowned.
• The consumer audit's gate is now fix(web-api-discovery): the scrub audit treats a header/cookie/query name as a JSON field name, adjudicating correct scrubs as CORRUPTED #375, not fix(web-api-discovery): the scrubber replaces at declared identifier fields the gate agreed to allow #360. audit-scrub-drift.js
  adjudicates a header/cookie/query name as a JSON field name and reports
  correct scrubs as CORRUPTED, so re-running the audit before fix(web-api-discovery): the scrub audit treats a header/cookie/query name as a JSON field name, adjudicating correct scrubs as CORRUPTED #375 lands would
  re-order CodiwomplerSocialMedia#862 against false alarms.

Now in flight (four parallel lanes, dispatched from one controller session,
partitioned by file ownership so they cannot collide):

Item	Lane owns	Author	Reviewer
#378 live password envelope survives a (verified) scrub	har-policy.default.json, har-secrets.js	Opus	Sonnet
#377 scrub output placement, stamping, HarFile link	capture-har.js, repo-workflow-guard.js, Invoke-HarCapture.ps1, SKILL.md, .gitignore	Opus	Sonnet
#375 audit reads envelope names as field names	audit-scrub-drift.js	Sonnet	Opus
#380 six files still name the old org	CLAUDE.md, copilot-instructions.md, dev-loop.agent.md, Start-IssueAgent.ps1 + tests	Sonnet	Opus

Plus PR #384 (#383, Copilot worktree layout): green on both checks, zero
reviews, under independent Sonnet review now.

Serialised deliberately — one lane, in this order: IntelliTect-Samples/web-api-discovery#46 (harden
isIdentifierShaped at the function boundary) -> IntelliTect-Samples/web-api-discovery#57 -> IntelliTect-Samples/IntelliSDLC.ai#344 -> IntelliTect-Samples/web-api-discovery#55. All four
write pii.js / har-shapes.js, so they cannot be parallelised, and IntelliTect-Samples/web-api-discovery#46
narrows the predicate before the widening changes push a new population through
it.

Sequenced behind #377: #379 (structured catalogue), then #382 (per-provider
API document). Both are design conversations rather than mechanical work and are
being taken as separate human-led sessions.

#381 (provenance stamp, extracted from Stage 10) unblocks IntelliTect-Samples/web-api-discovery#49 and IntelliTect-Samples/IntelliSDLC.ai#351. It
writes sanitize-har.js, so it follows #378 rather than running beside it.

[MarkMichaelis]

Overnight state — 2026-09-02

Since the refresh above:

Merged

• fix(web-api-discovery): the scrub audit treats a header/cookie/query name as a JSON field name, adjudicating correct scrubs as CORRUPTED #375 (audit reads a header/cookie/query name as a JSON field name) -- PR fix(web-api-discovery): stop the scrub audit reading an envelope name as a field name #385,
  authored on Sonnet, reviewed on Opus. The fix threads capturedFieldName
  through the emit path and DELETES the local isEnvelopeKeyPath predicate an
  earlier revision had added; the reviewer agreed its own suggestion to extend
  that predicate would have been the third copy of a definition this audit exists
  to measure. Note a user-visible report change: a non-JSON body's keyPath is
  now response.content / request.postData rather than ...text. IntelliTect-Samples/web-api-discovery#56
  consumers read those.
• fix(cleanup): recognise the Copilot desktop app worktree layout as safe #383 (Copilot worktree layout recognised as safe) -- PR fix(cleanup): recognise the Copilot desktop app worktree layout as safe #384, reviewed on
  Sonnet. Rescued work that had been local-only on one disk since 2026-07-30.

Closed, not planned

• six upstream-managed files still reference the old IntelliTect-Dev org (the sync script itself is already correct) #380 -- already fixed on 2026-08-29 by beae1a1 + 504a3aa (Refs IntelliTect-Samples/IntelliSDLC.ai#313),
  three days before it was filed. Both .Tests.ps1 occurrences confirmed by
  execution to be arbitrary fixture values, not pinned assertions. Root cause of
  the false report: it was read out of .worktrees/311-publish-evidence, which is
  locked, predates both fixes, and still holds all twelve occurrences at the exact
  quoted line numbers. That worktree is retained pending Review the Publish-Evidence.ps1 CLI #315, so it will keep
  producing stale readings for anything grepping a worktree instead of main.

Still in flight

• scrub reports "verified" on output still containing a live password envelope — secretFields has no auth-flow field names #378 -- PR fix(har-policy): name the auth flow, so a login capture cannot be "verified" #389 open, both checks green, independent review not yet run.
  Do not merge until it has.
• fix(web-api-discovery): scrub output lands untracked at the repo root, is unstamped, and leaves no link back to its raw #377 -- authoring, nothing pushed.

New — filed from dogfooding the pipeline against a real 9.0 GB store
(MarkMichaelis/CodiwomplerSocialMedia#908, which triaged 97 directories to
18 PROMOTE / 65 SKIP / 14 HUMAN):

• feat(web-api-discovery): no way to scrub or catalogue a STORE -- 83 of 88 captures are unprocessed because the only motion is one at a time #386 no way to scrub or catalogue a STORE; 3 of 88 captures have ever
  produced any artifact. Sequences behind fix(web-api-discovery): scrub output lands untracked at the repo root, is unstamped, and leaves no link back to its raw #377. HIGH.
• feat(web-api-discovery): nothing reports what a capture store holds, and two of its three input classes are invisible to a host-scoped walk #387 nothing reports what a store holds, and 2 of its 3 input classes are
  invisible to a host-scoped walk. Narrowed after review: reuse
  resolveSession()'s existing enumeration rather than writing a second walk --
  and the catalogue phase cannot be the reporter, because it deliberately fails on
  an unscrubbed capture, which is exactly the population an inventory must
  describe. HIGH.
• #388 store growth, 9.0 GB measured. The concern fix(web-api-discovery): scrub output lands untracked at the repo root, is unstamped, and leaves no link back to its raw #377 explicitly deferred.
  Filed as a placeholder with a number, not a design; every wrong answer is
  irreversible because git is not the history inside .har-captures/. LOWER.
• cleanup(cleanup-worktree): a redundant (?i) flag makes the regex and the operator disagree about case sensitivity #390 redundant (?i) in Cleanup-Worktree.ps1 -- found by an ablation that
  changed nothing, which is the documented trap. Minor.
• test(web-api-discovery): pin the audit envelope-name suite's live-policy preconditions and the untested half of the 'text' collision claim #391 PR fix(web-api-discovery): stop the scrub audit reading an envelope name as a field name #385's non-blocking review findings, filed rather than dropped.

A caution the consumer campaign surfaced, worth recording here. Four captures
(3 Facebook, 1 Instagram) carry #PWD_BROWSER / enc_password markers. Under
today's rules the scrub redacts every session cookie, reports (verified), and
leaves the password envelope byte-identical -- so a bulk scrub-and-commit before
#378 merges would put live credential envelopes into source control under a green
check. #908 is blocked on #377 and #378 for exactly this reason.

[MarkMichaelis]

Queue state refresh — 2026-09-09

The Overnight state — 2026-09-02 comment is a week stale. Verified against
the issue list just now, not remembered.

Merged since that comment

#377, #378, #379, #382, #386, #387, #390, #391
— all closed 2026-09-02/04. Plus #446 (PR #455, 2026-09-07) and #435
(2026-09-05).

That clears every item the previous comment listed as in flight or sequenced.
Nothing from that table is still open except the deferred lanes below.

Two consequences worth stating explicitly

1. CodiwomplerSocialMedia#908 is unblocked. It records itself blocked on
#377 and #378; both merged 2026-09-02. The password-envelope caution in the
previous comment — that a bulk scrub-and-commit before #378 would put live
credential envelopes into source control under a green check — no longer
applies. It is now blocked only on being synced, and I am deliberately holding
that sync until #454 merges so it does not pull a tree without the fix and force
a second sync.

2. #446 / PR #455 changed what is expressible. sanitize-har.js called
main() unconditionally, so requiring it performed a live scrub and exited the
requiring process. It is now guarded (sanitize-har.js:787) and exports main,
fakeFor, PATTERNS. Sharing a traversal or a predicate between the scrubber
and the gate was not possible before that merge — which is the direct cause
of the two byte-identical private copies of looksFormEncoded
(sanitize-har.js:375, har-secrets.js:217) whose own comment says nothing can
detect their drift.

Still deferred, unchanged

• #381 (provenance stamp, IntelliTect-Samples/web-api-discovery#59 Stage 10) still unstarted; #355 and
  #351 still blocked on it. The contract recorded in this issue is unchanged.
  Note that #459 now proposes the general provenance record spanning trim,
  scrub and PII substitution — IntelliTect-Samples/IntelliSDLC.ai#381 is the scrub-stage stamp and should be
  designed against IntelliTect-Samples/web-api-discovery#30 rather than ahead of it.
• The serialized pii.js lane IntelliTect-Samples/web-api-discovery#46 → IntelliTect-Samples/web-api-discovery#57 → IntelliTect-Samples/web-api-discovery#52 → IntelliTect-Samples/IntelliSDLC.ai#339 is unstarted and
  unowned. All four write pii.js / har-shapes.js; IntelliTect-Samples/web-api-discovery#46 narrows before the
  widening changes push a new population through the predicate. The ordering
  rule at the top of this issue still governs.
• #323, #353, #357, #388 unassigned, none blocking.

Where the work actually is

The capture pipeline's live queue is now on #453, re-prioritized today.
Summary: #454 → #456(verify-scrub) → IntelliTect-Samples/web-api-discovery#38 → IntelliTect-Samples/IntelliSDLC.ai#441 → IntelliTect-Samples/IntelliSDLC.ai#408, then
#450 + #423, then #459 → IntelliTect-Samples/web-api-discovery#31 → IntelliTect-Samples/IntelliSDLC.ai#381. #454 is in flight in this session.

The reason #454 outranks IntelliTect-Samples/web-api-discovery#34 — which #453 had named its blocker — is measured,
not preferred: IntelliTect-Samples/web-api-discovery#34 makes 1 of 62 captures unprocessable; #454 gates captures at
any size, 3 of 3 in one day, and the consumer has produced an artifact from
3 of its 88 captures.

One invariant to re-state, because CI can no longer carry it

GitHub Actions is billing-blocked, so a red or absent check proves nothing and
a green one is not available. Every gate in the "Invariants enforced on every
worker" list above must be satisfied by a local run whose scope is named —
Invoke-Pester -Path .\.github (CI-equivalent, ~51 files) rather than
.\.github\agents\tests\ (~47). Independent review is not waived by this and
never has been.

[MarkMichaelis]

#491 is now a complete inventory of remaining HAR pipeline work, ordered by what blocks what.

It does not replace this issue — it indexes it. This one keeps the live queue and its in-flight assignments; #491 exists so the whole picture survives a session ending, and cross-links the pieces that are easy to lose track of across 50+ open issues.

Two things from it worth surfacing here:

• fix(web-api-discovery): looksFormEncoded tests only the first parameter, so 41% of form bodies are never descended into #487 is the current blocker. looksFormEncoded tests only the first parameter, so a body starting route_urls[0]= is never descended into — 61 of 150 form bodies rejected across three captures, 54 carrying real %XX payloads. Until it lands, Instagram captures produce no scrubbed.har at all. It is also the second time that predicate has caused this exact symptom (see scrubString's docstring on the first).
• #408 has produced at least four instances — fix(web-api-discovery): looksFormEncoded tests only the first parameter, so 41% of form bodies are never descended into #487, fix(web-api-discovery): the scrub leaves values its own substitution table says to replace, and verify-scrub cannot see them #475, IntelliTect-Samples/web-api-discovery#52, IntelliTect-Samples/IntelliSDLC.ai#323 — all "the gate reaches where the scrubber cannot". fix(web-api-discovery): looksFormEncoded tests only the first parameter, so 41% of form bodies are never descended into #487 is probably the largest single cause of fix(web-api-discovery): the scrub leaves values its own substitution table says to replace, and verify-scrub cannot see them #475, so re-measure fix(web-api-discovery): the scrub leaves values its own substitution table says to replace, and verify-scrub cannot see them #475 after it lands rather than before.

[MarkMichaelis]

Superseded -- retired in favour of priority labels + blocked-by links (#498). The current HAR order and all carried-forward state are recorded on #491: #491 (comment) . Closing.