Agent B — session report

Test counts: 904 → 1121 assertions across the session; the inherited work accounts for 443 → 904, mine for 904 → 1121.

1 · Audit — real vs stubbed vs documented-only

Walked the code, not the docs. NOT_PRESENT below means the code does not do the thing, whatever a document says.

Real, running, and verified by me this session

Present but not reachable end-to-end here

Documented but NOT_PRESENT in code

Faults I found by walking the code

Four, each with the measurement that found it. All fixed. Details in §2–§5.

2 · Website capture — what I changed and why

2a · The time budget was not enforced during the body read *(the real one)*

request.setTimeout is an inactivity timer. A server sending one byte every three seconds resets it forever and never trips it.

Measured against exactly that server: the read was still running at 25 seconds having received 20 bytes, with nothing going to stop it. One request pinning a connection is a slow leak; a handful is the server. Reachable by anyone who can type into the onboarding address box.

readCapped now takes the deadline for the whole chain, already reduced by every redirect hop, so a site cannot buy time by bouncing us around first. Running out of time is a failure, never a short page — returning what arrived would hand the extractor a partial document indistinguishable from a complete one, and the review screen would report "no phone number" about a page we stopped reading.

2b · A correction to my own first attempt

I initially wrote that decompress's empty .on('error', () => {}) silently truncated bodies, and committed that claim. It does not. Measured against a gzip stream cut off before its trailer: the async iterator still rejected with Z_BUF_ERROR. The handler only stops the error being *unhandled*.

No page was ever silently truncated. What remains is a naming fix: a decode failure fell into the catch-all and was reported as network, whose message reads *"We could not reach your site."* We did reach it. It answered and we could not read what it said — a different fact, pointing at a different cause, and the one that belongs in intake_sources.error_note. It is undecodable now. The correction is written into the commit message and the code comment.

2c · Two hostname holes — both caught by the layer below, both closed

• Trailing dot. localhost. is a fully-qualified name resolving identically (verified: ::1 and 127.0.0.1) and walked past every rule in url.ts — the suffix test does not match .local., the IPv4 pattern does not match 127.0.0.1.. The connect-time check caught it, so this was a hole and not a breach. But a layer that only works when the layer below works is not a layer, and the one below costs a DNS round trip to say no. Now refused in 0ms.
• Credentials. https://admin:hunter2@intranet.example.com/ asks our server to authenticate to somebody else's machine. Refused, not stripped — stripping quietly fetches a different page than the one asked for and says nothing, putting a fact on the review screen sourced from a page nobody knows we read.

2d · A deny-list of service ports

The address rules answer *which machine*; this answers *which service on it*, and the second still has teeth after the first is satisfied — a database on a public host whose only real defence is that strangers cannot route to it, and Redis reads the lines of an HTTP request it understands and ignores the rest.

Deliberately not an allow-list of 80/443: real small businesses publish on 8080 and 8443, and refusing those breaks honest sites to close nothing.

2e · The strongest reading of the business name was thrown away

facts.extractName reads jsonld:Organization.name first — a field whose only purpose is to state the name. extract.extractBusinessName starts at og:site_name and has never heard of JSON-LD. Both ran on every scan; only the weaker became a candidate.

So on a site with proper structured data, the strongest fact intake can find was extracted, shown to the owner as a finding, and dropped before anything could use it. Measured against live PADI:

2f · Which immediately exposed a second thing

With two candidates from one source, PADI's field went CONFLICTING against itself — "PADI" vs the full name is a material disagreement by any reading. It seeded nothing, claimed no provenance, and asked the owner to settle a dispute between a page and itself.

A conflict is a disagreement between SOURCES, not between two readings of one page. This could not arise while each source offered one candidate per field. A weak inference losing to a strong observation is the weak method being weak, and the registry already says which reading is worth more. Raising it buries the real conflicts — which is how a conflict system gets switched off; conflict.ts says so in its own header. Site-vs-bio disagreements are untouched, asserted both ways.

2g · Why the body rules moved to body.ts

Not tidiness. The address guard makes `fetchSite` deliberately unable to reach any server this repository can start — every test server binds to loopback, and refusing loopback is the guard's whole job. Pointing the fetcher at a trickling server is impossible *by construction*. Split out, the rules are driven by real streams from a real local server over plain http.get: nothing mocked.

3 · Provenance — what it looks like now

Every claim answers "where did DNA learn this?" with a machine identifier, not a sentence:

Business name   Andaman Divers
                From your own pages
                the business name published in your site's data
                https://www.andamandivers.com/     [jsonld:Organization.name]

Three separate things, and they are kept separate on purpose:

• mechanism — branched on, re-checkable (jsonld:Organization.name)
• detail — the sentence a person reads
• sourceUrl — the final URL after redirects, which is what re-checking needs

The four standings never blur: OBSERVED / USER_SUPPLIED / INFERENCE / CONFLICTING, plus a fifth — UNKNOWN — that exists only in the blueprint, because Standing describes how a claim was *obtained* and has no word for a field nobody has claimed anything about.

The load-bearing invariant, enforced structurally and hardest-tested: a line carries its provenance or it carries no value. A value the assembler cannot attribute drops to UNKNOWN. *"Here is a fact, we cannot tell you where it came from"* is worse than *"we do not know this"* — the first gets believed, the second gets fixed.

Three provenance faults I fixed

1. `business_name` said "you told us" when the website supplied it. Both scans prefill that box (setName(outcome.businessName)); the review screen printed origin="you told us" unconditionally. Identical to the fault 0919945 fixed for languages, still standing on the field this product singles out as the most visible thing intake can get wrong, in the largest type on the screen. Fixed with nameOrigin, which travels through sessionStorage and is written to source_weights at the lock.
2. `business_name` never reached `source_weights` at all. sourceWeightsForLock builds the map by walking the QUESTIONS, and no question asks the name — so a locked record could not say the website chose its own name, and *"why did this change?"* is the question that column exists for.
3. `plan.mechanisms` / `plan.sources` did not exist. The mechanism was computed and travelled as far as Resolved, then stopped at the plan boundary — so anything reading a plan rather than a merge had prose where it needed an identifier. A disputed field is deliberately absent from both: while two sources disagree there is no mechanism by which we know the value.

The provenance gap I could NOT close, named rather than papered over

The mechanism is discarded at the lock. brand_dna.source_weights records *which* source decided a field and never *how* it read it. A name that was CONFIRMED from jsonld:Organization.name during the session comes back knowing only that the website decided it.

I did not invent a certainty to fill that. The recovered claim gets a distinct mechanism — record:source_weights, OBSERVED / LIKELY — whose why reads *"the locked record names the source but not how it read it; the mechanism is not stored."* LIKELY rather than CONFIRMED because the original certainty is exactly what was lost; a title-split read comes back through the same door.

The fix is a column, not a better guess — source_mechanisms alongside source_weights, written at the lock from the same plan. That is a migration, and migrations were out of scope. This needs a human decision.

4 · SSRF — the exact cases I ran, and their results

Run live against the real fetchSite at the finishing SHA. invalid_url = refused by the hostname layer before a socket; blocked_address = refused at connect time after the resolver answered.

Bold = closed by me; the rest were inherited and re-verified.

Also verified live: example.com and a 575KB gzipped Wikipedia page both read and extracted, so none of the hardening broke real fetching.

Redirects (inherited, re-verified in the suite): every hop re-validated through both layers; a 302 → http://169.254.169.254/ is refused; five-hop limit; each abandoned redirect body destroyed to release the socket.

New adversarial cases in body.test.mts, all against real servers, nothing mocked:

What SSRF hardening still does NOT do

• DNS rebinding between lookup and connect is narrowed, not provably closed. In practice guardedLookup returns only validated addresses and the socket connects to those, so the ordinary attack has no window. Fully closing it means pinning the resolved address and carrying the hostname separately for TLS. I did not do this, and I did not claim the inherited comment was wrong — it is conservative, which is the right direction to err.
• No egress proxy or network-level allow-list. Application-layer only.
• If the fetcher is ever swapped for a headless browser, all of this must move with it. The check belongs to whoever opens the connection.

5 · Conflicts

Inherited: detection, both values kept whole, disputed fields seeding nothing.

What I found: the panel showed both answers as two lines of text. The commit that built it said the owner would "pick rather than type" — both answers arrived, the picking did not. Settling one meant reading it, scrolling to find the matching question, and answering by hand, for the one thing on that screen that only the owner can do.

Now: each answer is a button with aria-pressed, in a named role="group" — the same shape the questionnaire uses for a choose-question, because a <label> cannot point at several buttons and a tint says nothing to a screen reader.

A tap records the value as theirs, not the winning source's. They read both and chose, which is what resolveClaims means by an owner's claim ending the matter. The agreeing source gets no credit — *"the website was right"* is a different claim from *"the owner decided"*.

A settled row stays on screen (removing the evidence they just used would leave them unsure it registered) and the heading counts what is left — *"1 of 2 still to settle"*.

Two key spaces reach that panel and are answered differently: question-keyed conflicts by answering the question, business_name by writing the name box. business_name is checked first, so a future question filling the same path cannot leave the box showing a stale name. A key with neither returns none and is left alone — a misplaced value is worse than an open disagreement, because the disagreement is visible and it is not.

States used, exactly as specified: CONFIRMED / LIKELY / NEEDS_CONFIRMATION / CONFLICTING. No invented numbers anywhere.

6 · The Living Blueprint

/blueprint, plus the pure assembler in src/lib/blueprint/ (112 assertions).

• Nothing is summarised away. Every DNA field is a line, the empty ones included. A blueprint that omits what it does not know reads as complete, and the gaps are the most useful part of it.
• Provenance or no value — the invariant above.
• A disagreement prints neither answer. Showing the leader with a warning beside it is the silent pick in a friendlier font.
• "Living" is not animation. A blueprint that cannot say what would *change* it is a report, and a report gets read once. Every unsettled line carries the question that would move it, collected worst-first — a disagreement above a gap, because only the owner can settle one of them.
• No score, no percentage, no fabricated history. Versioning makes a real history possible later by comparing versions; it is not possible from one version, so there is none rather than a plausible one.
• Saved is never implied. With a database it reads the locked record and says *"Saved as version 2 · locked 20 August 2026"*. Without one it says *"Nothing is being stored on this copy"* — not "you have not locked a brand yet", which is a claim about the owner and would be false. The unsaved view says *"This is not saved"* in as many words: not "saved locally", not "saved in this browser".

Rendered server-side against real data (temporary route, since removed). Verified on screen: mechanism + URL on every attributed line; a conflict showing both values and no pick; Thai text (คู่รักที่มาเที่ยวภูเก็ตครั้งแรก) rendering; the failed Instagram attempt shown with its machine reason private_account; and every number a real fraction — *7 of 20 lines*, *1 of 2 sources*, *13 things left*.

A structural test walks the entire object and fails on any number that is not a count with a stated denominator, and on any % in any string. That is checked by walking the data, not by reading the code, because the way a number reaches a screen is that somebody adds a field six months from now.

7 · Instagram — state, and what would make it live

State: NOT_CONNECTED. Nothing is live. No Meta app, no token, no provider account. capabilities.instagram is off and the step says so plainly.

Access is a state with fixed wording (inherited, instagram-access.ts), and exactly one of seven may say connected:

NOT_CONNECTED · PUBLIC_PROFILE · CONNECTED · PERMISSION_REQUIRED · UNSUPPORTED · CAPTURE_FAILED · NO_EVIDENCE

A public read renders "Public profile analysis" and never "Connected Instagram Account" — asserted in the suite. The copy avoids the word even in the negative, since *"nothing was connected"* is read at a glance as *"connected"*.

I re-checked Meta's live documentation rather than trusting the note

Confirmed as still accurate: the three permissions (instagram_basic, instagram_manage_insights, pages_read_engagement), the Business-Manager ads_read/ads_management case, *"another Instagram Business or Creator IG User"*, read-only, and age-gated accounts excluded.

Two facts the previous pass did not have, and both change the decision:

1. `business_discovery` is not available on the Instagram Login configuration. Meta ships two — *Instagram API with Instagram Login* (graph.instagram.com) and *Instagram API with Facebook Login* (graph.facebook.com) — and the comparison table marks Business Discovery on the Facebook Login one and not the other. So the two Meta routes are not a fallback pair. Building the simpler owner-authorised route first buys nothing towards reading a prospect, and means doing the Facebook Page, the Meta app and the App Review a second time.
2. There is a rate limit. Business Discovery and Hashtag Search fall under platform rate limits rather than the Instagram business-use-case limit, which is otherwise 4800 × impressions in 24h — impressions on our own account's content. A new Bulgar account has approximately none, so that formula would yield approximately nothing; being exempt from it is the only reason this route is viable for a studio with no following.

Recorded as UNVERIFIED, not repeated: third-party write-ups describe a cap on unique accounts per rolling week. Meta's own reference does not state one. It is the kind of limit that decides whether this can serve onboarding at all — a question for whoever applies, not a number to plan around. The suite asserts the word UNVERIFIED is present so it cannot quietly become a number later.

Also, because it dates every older document: the Instagram Basic Display API was shut down entirely on 4 December 2024.

To make it live

ROUTES_TO_LIVE holds this as data, not prose, so a handoff cannot paraphrase it into something more optimistic. VERIFIED_AT = '2026-08-25' is asserted present and well-formed, so "we checked" always carries "when".

Meta `business_discovery` — a Bulgar Instagram professional account linked to a Facebook Page · a Meta app with the Instagram product · a Facebook User token with the three permissions · Advanced Access via App Review (Standard reaches only accounts we own, which is none of the ones we want). *Blocked on: no Meta app exists.*

What no route will ever provide: personal accounts · private accounts · age-gated accounts · follower lists · audience demographics for an account we do not manage. Asserted in the suite, so a screen expecting demographics fails a test rather than shipping.

Nothing was scraped. No private or authenticated page was touched. No platform restriction was bypassed.

8 · Failure states implemented

Website: invalid_url · blocked_address · blocked_redirect · too_many_redirects · http_404 · http_* · not_html · timeout · `undecodable` (new) · network · action_failed.

Every one carries a machine reason for intake_sources.error_note and a separate sentence for the owner that ends with what happens next — the step never dead-ends, and the questionnaire is always the fallback.

Instagram: the seven access states above, with retryable decided per state — paperwork and privacy are not retryable, a timeout is.

Blueprint: no database · not signed in · no brand · brand not locked · no draft · draft present but unsaved. Each says something different and true.

9 · Tests and gates

Before (my starting point after the fast-forward): 904. After: 1121. *(443 → 904 was the inherited chain.)*

No test was weakened, skipped or deleted. Three assertions changed and each is a tightening, not a loosening. No eslint-disable, no rule turned off.

Gates — exact vocabulary

10 · Approaches that FAILED

• Committing a claim I had not measured. I wrote that the swallowed zlib error silently truncated bodies, and committed it. Testing the old pattern showed the iterator still rejected. Corrected in the commit message and the code; §2b. The lesson is the one this repo already teaches: run it.
• Two `LineSpec` ids did not match any `Question.fills` path (audience.primary, offer.main_offer). The lookup returns undefined, which is indistinguishable from "no question asks this" — every value the owner typed on those lines would have silently lost its "you told us". Caught by a test, not by the compiler. The join is now asserted line by line.
• End-to-end testing the body rules through `fetchSite` is impossible by construction. The address guard refuses loopback, which is where every test server lives. Split to body.ts rather than weakening the guard or mocking.
• Wiring `facts` into candidates immediately broke conflict detection (§2f) — a fix that needed a second fix, found by running it against a live site rather than by reading the diff.
• `setState` in an effect for the blueprint draft read — correctly blocked by react-hooks/set-state-in-effect. Rewritten with useSyncExternalStore, matching the pattern 5693432 established. Nothing suppressed.
• A temporary `app/__probe` route did not build — Next ignores _-prefixed folders. Renamed, used, removed.
• `pkill -f "next start"` silently misses the process — exactly as NOTES.md warns. It cost me a 404 on a route I had just built. fuser -k 3210/tcp.

11 · What I deliberately did NOT change

• The visual language. The brief asks for luminous violet / electric blue / turquoise. docs/16-design.md is the project's stated visual law, and CLAUDE.md says to read it before any UI work. The existing system is warm cream with green and amber — light surfaces, generous whitespace, no sharp corners, contrast ratios measured with the product's own contrastRatio(). It is emphatically not a black/red war room, which is the constraint the brief actually names. Rewriting the palette unilaterally would overwrite a documented decision to satisfy an adjective. /blueprint is built to the existing law and invents no new colour. If the violet direction is wanted, it is a change to `docs/16-design.md` first — a human's call.
• No migration, per the hard rules — which is why the discarded mechanism (§3) is *named* rather than fixed.
• No production database, credentials, writes or deployment. Nothing pushed; seven commits sit on the branch for a supervisor.
• The palette line reads "Our best guess" when a scan seeded it, even though the owner passes a style screen where they can edit it. The review screen says "from your site, checked by you". I chose to understate rather than claim approval from someone who may have clicked past. Worth a human's opinion.
• `docs/13-stack.md`'s Playwright reference — left alone; a stack decision.
• The composite/M5 code — outside these priorities, untouched.
• Priorities 6 (identity direction) and 8 (collaboration/mobile) — not started. The brief said depth over breadth and named 1–3 as the ones to make excellent.

12 · What a human must review

1. `record:source_weights` is a judgement call. A field recovered from a locked record is reported OBSERVED/LIKELY because the original mechanism was never stored. LIKELY is my choice of the honest middle. If it should be NEEDS_CONFIRMATION instead, that is a one-line change — but the real fix is a source_mechanisms column, which is a migration.
2. The visual direction conflict in §11. It needs deciding, not guessing.
3. The Instagram route decision is now sharper and still Ivan's. The two Meta routes are not a fallback pair (§7), so choosing the simpler one first costs the whole setup twice. Against: an official route reads professional accounts only, and in Phuket a real share of businesses post from personal accounts, which a scraper reads and Meta never will.
4. The unverified weekly cap on business_discovery — ask Meta during App Review. It may decide viability.
5. Nothing has run against a database this session. blueprintFromLockedRow is tested as a pure function; the Supabase round trip is NOT_RUN, and so is npm run test:db.
6. The blueprint's unsaved path is NOT_RUN in a browser. No browser here. The pure function has 112 assertions and the view rendered server-side, but the sessionStorage read itself has not been exercised.
7. Thai typography still needs a Thai reader. Thai text renders in the blueprint and the extractor declines to guess Thai phrases (no segmenter) — but whether it *looks right* is not something I can check, and CLAUDE.md says Ivan cannot either.
8. I fast-forwarded onto another agent's branch (§0). If that chain was not meant to be built on, this branch inherits it and the supervisor should know before merging.