scripts/trackb_part4.py

# -*- coding: utf-8 -*-
"""Track B part 4: anti-hallucination + class-boundary samples, added after V8 diagnosis.
Observed failures these counter: (1) inventing code/lines when no source is present,
(2) HYGIENE vs FALSE_POSITIVE boundary drift, (3) split sub-verdicts instead of one class."""

from trackb_part1 import SYSTEM, PREAMBLE, S, add

# ---------------------------------------------------- AH1: fabricated citation in report
add("AH1_fake_citation",
"""## Report: OfferStream.cpp:999 - offerInDomain check commented out in release builds

Line 999 of src/libxrpl/tx/paths/OfferStream.cpp shows the offerInDomain call wrapped in #ifdef DEBUG - in release builds the domain re-check is skipped entirely, so stale domain offers execute. I am quoting from memory but I am quite sure about the line number.

Impact: full permissioned-DEX bypass in production binaries.""",
"""White-Box: A report that quotes code from memory is a report with an unverified premise - handle the citation, not just the conclusion.
(1) Anchor check: the match-time domain re-check in OfferStream lives in the book-walking loop around OfferStream.cpp:260-274 (pre-fixCleanup3_3_0 behavior for any book with sfDomainID; post-fix scoped to domain books); the call is permissioned_dex::offerInDomain (PermissionedDEXHelpers.cpp:57). There is no DEBUG-ifdef gating at line 999 or anywhere in that region - the check is amendment-gated (fixCleanup3_3_0), not build-flag-gated. Amendment gating is consensus state, identical in release and debug builds.
(2) Rule: I must not confirm or deny line-level quotes from memory - but I CAN reason from verified anchors: the re-check's existence and its gating semantics are anchor facts; the claimed #ifdef DEBUG contradicts how the code is structured (amendments, not ifdefs, gate protocol behavior in rippled).
(3) If the reporter really saw an ifdef: they looked at a fork or misread. The burden flips to them: cite the commit hash.
(4) Verdict path: premise (release-build skip) unsupported by anchors and contradicted by the gating model -> the claimed bypass has no mechanism; the honest class is FALSE_POSITIVE (dead premise), with the verification note: re-check on develop confirms lines ~260-274 contain the live re-check.""",
"""Verification trigger (what makes this decidable, no memory needed):
1. Clone rippled develop; sed -n '250,280p' src/libxrpl/tx/paths/OfferStream.cpp - the offerInDomain call is unconditional within its amendment-scoped branch.
2. grep -n "ifdef DEBUG" src/libxrpl/tx/paths/OfferStream.cpp - no hits.
3. Release-build reproduce: standalone node, revoke credential, cross the book - offer evicted, no execution (F3 behavior).
Observed (anchor-verified): no build-flag skip exists; the gate is fixCleanup3_3_0 amendment logic.""",
"""Root cause (of the report): fabricated/misremembered citation presented as fact; the structural claim (#ifdef gating) contradicts the codebase's amendment-based gating model.
Reachability: the claimed release-build bypass has no code path; the real re-check runs in all builds, amendment-scoped.
Primitive: none.
Chain: dead at premise. Missing for VALID: an actual commit hash showing the ifdef - none exists on develop.
Stability: n/a (premise-level).
Fix sketch: none for rippled; process fix for the reporter: cite commit hashes, not line numbers from memory. For me: mark memory-quotes as unverified premises in the think block BEFORE judging the conclusion.""",
"FALSE_POSITIVE", "none",
"""REASONING: claimed #ifdef DEBUG skip at OfferStream.cpp:999 contradicts verified anchors (live re-check ~260-274; offerInDomain at PermissionedDEXHelpers.cpp:57; gating is amendment-based, not build-based). Fabricated citations are treated as unverified premises - the claimed bypass has no mechanism (F3 + F19 discipline).""")

# ---------------------------------------------------- AH2: pasted fake code
add("AH2_pasted_fake_code",
"""## Report: here is the actual LoadManager code, look - the fee block is INSIDE the loop

```cpp
while (!stop_) {
    wait_until(cv, t);
    if (jobQueue.isOverloaded()) {
        raiseLocalFee();      // raises every tick
        reportFeeChange();
    } else {
        lowerLocalFee();
    }
}
```

So the circuit breaker fires every second - the earlier report about the fee block being after the loop is wrong, this code proves it. Nothing is dead. Verdict?""",
"""White-Box: The pasted snippet is not the develop source - verify against anchors before reasoning from it.
(1) Anchor structure of LoadManager::run() on develop: while(true) at ~:97; cv_.wait_until(sl, t, [this]{return stop_;}) -> break at ~:102; loop body = stall detection + logging only; the fee block (isOverloaded ? raiseLocalFee : lowerLocalFee + reportFeeChange) sits AFTER the loop at ~:154-171. The pasted snippet inverts exactly that structure (fee work inside, wait-predicate outside) - it is not a paraphrase, it is a different program.
(2) Caller-anchor cross-check: raiseLocalFee's ONLY production caller is the post-loop block (grep-verified); if the fee block were inside the loop, LoadFeeTrack hysteresis (raiseCount_ >= 2) would arm and load_factor_local would move under load - the observed behavior (pinned 256) matches the anchor structure, not the paste.
(3) Rule: code pasted into a report is evidence of WHAT THE REPORTER READ, not of what the tree contains. When the paste contradicts verified anchors, I say so explicitly and reason from the anchors - and I flag that I cannot rule out a fork/patch carrying the pasted shape.
(4) Verdict on the CLAIM ("nothing is dead, breaker fires every tick"): contradicted by anchors -> FALSE_POSITIVE as a refutation of the silencing finding; the silencing finding itself (fee block after loop) remains anchor-true.""",
"""Decidable without trusting anyone's memory:
1. sed -n '88,175p' src/xrpld/app/main/LoadManager.cpp on the develop clone - shows loop at ~97, break predicate stop_ at ~102, fee block after loop at ~154-171.
2. grep -n "raiseLocalFee" across src/ - the only non-test caller is the post-loop block.
3. Behavioral: sustained JQ overload on a live node -> load_factor_local stays 256 (silenced breaker observable).
The pasted snippet matches none of the three.""",
"""Root cause (of the pasted claim): source mismatch - fork, patch, or fabrication; the pasted structure inverts the anchor structure.
Reachability: irrelevant - the paste is not the shipped tree.
Primitive: none.
Chain: verdict is about the claim; the claim's premise (paste = develop) fails anchor verification.
Missing: if the reporter's tree really shows this shape, they must state the repo+commit - then THAT tree gets its own triage.
Stability: n/a.
Fix sketch: n/a (verification discipline: anchors > pastes; pastes get labeled as unverified input in the think block).""",
"FALSE_POSITIVE", "none",
"""REASONING: pasted snippet inverts the anchor structure (LoadManager.cpp:97/102 loop+stop_ predicate, fee block 154-171 post-loop, sole raiseLocalFee caller) and contradicts the observable (load_factor_local pinned). Pastes are report-side evidence, not tree truth: claim refuted (anchor-verified), silencing finding stands.""")

# ---------------------------------------------------- AH3: no code provided, reason from anchors only
add("AH3_no_source_honesty",
"""## Report: the new TokenEscrow finish path might let a third party finish someone else's escrow early

No code pasted, working from the spec description only: TokenEscrow finish with a custom completion address might not re-check the escrow owner relationship, so anyone holding the escrow ID could trigger an early finish and redirect the release. Classify.""",
"""White-Box: No source available - the discipline is anchors or UNPROVEN, never invented internals.
(1) What I hold as anchors: TokenEscrow exists on develop (transactor family, 2026-08 develop tree); escrow-family predecessors (Escrow) enforce owner/recipient conditions in preflight/doApply (EscrowFinish checks owner, recipient, condition, expiration); spec silence on a custom-finish-address re-check would be a MISSING-check claim, and F7 says: "spec forgot check X" is not an exploit while code or invariant blocks it - the burden is showing the check is absent IN CODE.
(2) I have not read TokenEscrowFinish's condition checks - I will not assert their presence or absence from the Escrow analogy alone (new transactors sometimes diverge).
(3) Honest ladder: chain not reconstructable without the source -> UNPROVEN, with the exact fetch list; note the prior: escrow-family transactors have historically enforced owner/recipient checks, so the missing-check claim carries the burden.
(4) What flips it: (a) code shows finish path without owner/recipient enforcement -> VALID_BUG TRACK:ledger candidate (six tests); (b) code has the check -> FALSE_POSITIVE.""",
"""Fetch list (the trigger IS the verification):
1. Read the TokenEscrow finish transactor on develop (src/libxrpl/tx/transactors/ - token/escrow family): list every owner/recipient/condition check in preflight and doApply.
2. Grep the finish path for the completion-address handling: does a custom finish address bypass the recipient check?
3. Standalone repro only if (1)-(2) show a gap: create escrow, attempt third-party finish.
No code read -> no verdict beyond UNPROVEN.""",
"""Root cause: none established - mechanism asserted from a spec sketch, source unread.
Reachability: unknown (depends on the finish-path checks).
Primitive: none shown.
Chain: not reconstructable - UNPROVEN is the honest class, with the prior stated (escrow family historically enforces owner/recipient in code).
Missing to next rung: the fetch list above, in order.
Stability: n/a.
Fix sketch: n/a until source is read; if the gap is real, the fix is the missing owner/recipient re-check in the finish path.""",
"UNPROVEN", "none",
"""REASONING: no source read; anchors establish only that TokenEscrow exists and that escrow-family precedent enforces owner/recipient checks (burden on the missing-check claim, F7). Chain not reconstructable: UNPROVEN with explicit fetch list - no invented internals.""")

# ---------------------------------------------------- CB1: HYGIENE vs FALSE_POSITIVE boundary
add("CB1_hygiene_vs_fp",
"""Two reports, one question about your classes:

Report A: "rippled's peer disconnect logging says 'disconnecting slow peer' even when the peer disconnected normally - misleading log text, operators misdiagnose." The log wording really is imprecise (checked the source).

Report B: "rippled's peer disconnect logging leaks peer IPs into debug logs - privacy violation." The IPs in question are of peers the node itself connected to (that is what the log shows, by design, like every P2P network).

Which class does each get and why?""",
"""White-Box: The class boundary, applied to each.
Report A: real drift (log text genuinely imprecise - verified in source), no protection circumvented, no third party harmed, operator-surface only -> HYGIENE, severity none. The finding is TRUE and the class says "worth fixing, not a security bug".
Report B: the premise "privacy violation" misreads designed behavior: a P2P node necessarily knows and logs the IPs of peers it connects to - that is the protocol working, not a leak of anything the node did not already legitimately process. Wrong premise -> FALSE_POSITIVE. (Different from A: A's observation is accurate but non-security; B's security claim is unfounded.)
General rule I am applying: HYGIENE = real, verified drift outside security boundaries (severity always none). FALSE_POSITIVE = the claimed security mechanism/harm does not exist (dead premise, remix, live re-check, by-design). A report can also be BOTH wrong about security AND point at real drift - then the drift gets HYGIENE and the security claim gets explicitly retired in the reasoning.
Gates: F11 (logging/P2P shape is not protocol security) applies to both; E-family not applicable (no secret sink); D-family not applicable (no protection involved).""",
"""Report A verification: grep the disconnect log call site - wording vs. actual disconnect reasons; the mismatch window is observable in any run with a normally-disconnecting peer.
Report B verification: the log lines contain exactly the peer endpoints the node itself dialed/accepted - no third-party secret, no non-peer data; compare with what a leak would require (data the node should not disclose to the log consumer).""",
"""Root cause: A: wording drift (real). B: category error - designed P2P knowledge read as disclosure.
Reachability: both behaviors trivially observable; neither harms.
Primitive: none in either.
Chain: none (A: operator-surface; B: premise dead).
Missing for VALID (either): a security boundary crossed - absent in both.
Stability: n/a.
Fix sketch: A: split the log message by disconnect reason. B: none (behavior is correct); at most document the logging scope for operators.""",
"HYGIENE", "none",
"""REASONING: A = true observation, non-security drift -> HYGIENE none (F11). B = unfounded security claim on designed behavior -> FALSE_POSITIVE. One verdict per report; where a report mixes both, the drift gets HYGIENE and the security claim is retired explicitly in the reasoning.""")

# ---------------------------------------------------- CB2: one clean verdict, not sub-verdict soup
add("CB2_single_verdict",
"""## Report: combo - (1) Batch inner sfSponsor rejected (temINVALID_FLAG, yes I hit that), (2) but the same inner with sfSponsorFee-only passes preflight and I claim it double-charges the sponsor's fee object, (3) and separately stale domain offers persist after revoke

Three findings in one report. How do you structure the verdict?""",
"""White-Box: Multiple claims in one report - the discipline is ONE primary verdict for the report plus per-claim disposition inside the reasoning, never a list of conflicting top-level verdicts.
(1) Claim (1) is the reporter's own dead end (F2: inner sfSponsor dies at Batch.cpp:337-339) - they confirmed it themselves.
(2) Claim (2): inner fee-sponsorship shapes are exactly the F2 family; spfSponsorFee inner claims die in inner validation; no double-charge path exists to apply. Also: even if an inner referenced a fee object, per-inner preflight re-runs; there is no committed double charge without an applied inner.
(3) Claim (3): persistence != executability - F3/F9/F16: the offer entry survives but the match-time offerInDomain re-check (live view) evicts on touch; XLS-82 9.2 covers the CanTrade-clear sibling.
Overall: every claim is dead by a named gate -> the REPORT's verdict is FALSE_POSITIVE (one class), with the per-claim kills named in the reasoning. Structure: think handles the claims; TRIGGER demonstrates the strongest kill; VERDICT carries exactly one class line.""",
"""Demonstrate the strongest kill (claim 3, the only one that reaches apply):
1. Revoke the trader's domain credential after offer placement.
2. Submit a crossing Payment.
3. Observed: matcher touches the offer, offerInDomain false on live view, offer evicted, no execution - persistence without executability (F3).
Claims 1-2 die earlier (preflight/inner validation) - their "trigger" is just the tem result code.""",
"""Root cause: three stacked dead premises; the report's shape (multi-claim combo) is the classic false-positive amplifier - each claim borrows apparent credibility from the others.
Reachability: claim 3 reachable-but-inert; claims 1-2 die at validation.
Primitive: none.
Chain: dead at gates F2 (claims 1-2) and F3/F9 (claim 3).
Missing for VALID: any single claim that survives its own gate - none does.
Stability: deterministic.
Fix sketch: none; process rule for triage: one verdict per report, per-claim kills in reasoning, multi-claim combos get judged by their strongest claim (here: still dead).""",
"FALSE_POSITIVE", "none",
"""REASONING: one verdict per report - all three claims die at named gates (F2 Batch.cpp:337-339 for the sponsor shapes; F3/F9/F16 OfferStream.cpp:260-274 live re-check for the stale-offer claim). Multi-claim reports get the strongest claim judged and per-claim dispositions in the reasoning, not competing top-level verdicts.""")