# tipoc-tv Agent Entry

## Source Of Truth

This repository is the implementation target for third-version `tipoc`. Project-level TiForge context, active ledgers, and run evidence live outside this product repository, for example under `/Users/benjamin2037/Desktop/project/poc-three-version/`. Before changing code, read the relevant external project context when it is available, plus the repo-contained design capsule in `docs/DESIGN-CAPSULE.md` and the critical path map in `docs/CRITICAL-PATH-MAP.md`.

As of 2026-06-18, the first recovery-visible active mainline for this worktree is `internet-simulation-load`, not D10. If external project context is mounted, future sessions should load `/Users/benjamin2037/Desktop/project/poc-three-version/context/internet/context-truth-pack.json`, `/Users/benjamin2037/Desktop/project/poc-three-version/context/internet/active-recovery-checkpoint.json`, `/Users/benjamin2037/Desktop/project/poc-three-version/context/todo.md`, and `/Users/benjamin2037/Desktop/project/poc-three-version/dev/internet/**` before treating older D10 text in this file as current. Those files are project context, not product-repository source. The active internet gate is `INT-E2E-010G-LOCAL`; it requires a clean non-`master` delivery branch or worktree, committed clean source, a fresh `init -> prepare -> run -> cleanup` internet 10G attempt, and `statement_qps >= 15000` before 50G is released.

The D10 premium `1T` material below is historical/inactive unless the user explicitly switches the project back to D10 and updates durable truth first. Do not use D10 as the recovery entry, active node, first legal action, or formal-delivery blocker for the current internet mainline.

Path-scoped `AGENTS.md` files are mandatory context. Before editing files under a subtree that has its own `AGENTS.md`, read that file after this root file. The current critical path entries are:

1. `core/execution/AGENTS.md` for four-stage execution, live prepare, live runtime, receipts, reports, and E2E closeout integration.
2. `industries/securities/AGENTS.md` for TPC-E catalog, schema adapter, securities materialization, runtime model, query evidence, and validators.
3. `industries/securities/bootstrap/AGENTS.md` for generated TPC-E CSV source objects, LCG/cardinality materialization, direct S3 publication inputs, and prepare-load semantics.
4. `industries/securities/runtime/AGENTS.md` for CE/MEE/BrokerageHouse/DM/TradeCleanup actor ownership, CE deck mix, temporal state machine, and runtime closeout.
5. `projections/tidb/AGENTS.md` for TiDB DDL, `IMPORT INTO`, S3 object publication, statistics validation, BR checkpoint, live SQL, and runtime statement generation.

## Mandatory Critical-Path Implementation Quality Gate

This gate is persistent and non-bypassable before implementation, review,
build, deployment, or E2E. When external project context is available, load
its `PROJECT-RULES.md`; this section remains authoritative if it is absent.

Before editing product code, freeze one implementation capsule containing:
the single outcome; direct runtime and durable-data root-cause evidence; the
complete production call chain from public entry through scheduling, state
machine, SQL/transaction, receipt, and report; invariants; ordinary Run,
pre-run recovery, and closeout boundaries; SQL/algorithmic complexity at
target scale; allowed and forbidden paths; and acceptance checks. A symptom or
assumption is not a root-cause conclusion. Missing facts block product edits.

Repair the proved cause, not only the first symptom. Inspect the complete
sibling impact surface once and return one aggregated defect list before
coding. A shared selected-Internet change requires Ride, Food, and Mart impact
analysis together; a domain-local change requires every affected production
entry and outcome branch. Reviewers must return all violations in one pass and
must not stop at the first P0.

Choose the smallest production design: reuse a stable path, derive action from
durable current state, execute an existing legal successor, and keep
coordination bounded. Do not add states, edges, caches, coordinators,
recovery-only business concepts, or concurrency branches for implementation
convenience. Recovery defects must not change ordinary Run, and reporting
defects must not weaken business invariants.

Every changed SQL path must be checked against real DDL, leading index columns,
expected cardinality, and representative TiDB `EXPLAIN` before build. Review
total cost as `single-operation cost x maximum fan-out`, plus partition
coverage, ownership, cancellation, and deadlines. Empty-state discovery must
be bounded; concurrency belongs to execution after durable work is found.
Formal pressure concurrency must not be mechanically reused for recovery
probes. Unverified SQL plans and unbounded scans cannot enter E2E.

Keep one issue, one proved cause, and one independently reviewable commit. Do
not mix state-machine behavior, recovery scheduling, reports, RU collection,
or unrelated cleanup. If a repair reveals more than one adjacent design
defect, leaves the frozen call chain, needs a new state/shared coordinator, or
repeated review finds the same defect class, stop and return to design for
explicit user approval.

Before E2E, one clean immutable exact HEAD must pass a complete implementation
review with zero P0/P1. Review root-cause removal, scope, lifecycle separation,
transactions, idempotency/replay, commit-unknown behavior, conservation, SQL
plans, concurrency, and every affected production path. Acceptance tests must
use the real production entry, engine, transaction, durable result, and
verifier. Fake state, direct business-row seeding, scripted results, and
SQL-shape-only assertions are diagnostic aids, not acceptance evidence. E2E
validates integration and performance; it must not discover basic code-path,
schema, index, or state-machine errors.

Every runtime attempt has one hypothesis, expected signal, stop condition, and
hard time bound recorded before launch. Persist its verdict before starting
another attempt. Attempt numbers are not progress. Recovery targets 30 seconds
and stops at 60 seconds; at 5 and 10 seconds it must show decreasing durable
residue or a forward transition, otherwise stop for evidence collection. A
formal comparison keeps data, binary, duration, concurrency, and pressure
configuration fixed; only the approved experimental switch may differ.

Release metrics are: every repair commit maps to direct root-cause evidence;
no unreviewed SHA enters formal E2E; recovery stays within its hard bound; and
off/RU results are rejected unless pressure is equivalent and reaches the
frozen QPS target or proves database saturation.

## Mandatory Internet Rerun-Recovery Closure Gate

This is a persistent, non-bypassable rule for every change or verification of
the Internet Ride/Food/Mart workload. It is deliberately in this root entry
file so a future agent must load it before reading any narrower instructions,
even after context compaction or a session restart.

The task is not complete when one observed failure is repaired. A domain is
eligible for a local candidate only after a complete, evidence-backed closure
over its state machine and all production recovery callers:

`transition registry source state + legal edge -> resource effect -> recovery
entry (ready / point / expired) -> legal disposition
(cancel / natural successor / winner stale-closeout / replay) -> outcome
(success / commit-response-lost / stale / failure) -> exact execution class,
queue state, and resource result -> real production-transaction test`.

For every row, the delivery record must name the code path and executable test.
Static registry inspection, SQL-shape tests, a package-level green result, or a
reviewer's reasoning is not evidence for an uncovered row. Every caller that
handles a retained non-restartable/fatal execution must prove one of exactly
two outcomes: it propagates and exact-CAS-preserves the original class through
completion/replay/stale closeout, or it fails closed without changing business
state, queue state, class, or resource ownership. It must never silently
downgrade the class, release the item to ordinary ready retry, or overwrite the
root class with a derived marker.

Each edge's production-path test must additionally derive its identity/lease
requirements from the **actual transaction mutation set**, not from a handler
family name. The test must prove that every table/resource written by the edge
is leased before execution and that the matching durable resource effect is
observed afterward. A Finance- or Delivery-labelled handler is not evidence
that it writes only finance- or delivery-labelled resources.

Every business precondition in an acceptance test must be produced by the
frozen production entry point and its real predecessor transactions. Tests may
not hand-seed an order state, assignment/trip/leg graph, payment/ledger shape,
queue/execution row, winner proof, resource balance, or version combination and
then claim that the state is production-reachable. A transaction adapter may
provide copy-on-write commit/rollback storage, independent durable readback,
and fault injection, but it must execute the production publisher,
`DomainEngine`, transaction handlers, CAS statements, and verifier; it must
not implement or pre-decide business transitions on behalf of production code.
FIFO row/result scripts, direct map/table mutation, SQL-shape assertions, and
test-only state switches are diagnostic aids only and never acceptance proof.
If production cannot create a required predecessor graph, that is a production
defect to isolate and report, not a fixture gap to fill manually.

A natural transition that legitimately leaves its business aggregate active is
not a ready proof. A per-edge fixture must never report ready merely because
that one transition committed. The same production DomainEngine must execute
the legal successor chain until the aggregate is terminal and resources reach
their required baseline; only then may the production
`Verify*RerunStateReady` query be used as the aggregate proof. Test-side
state switches, prefilled readiness maps, or helper verdicts must not bypass
that query.

These rules are exclusive to **pre-run rerun cleanup**. Normal benchmark Run,
ordinary scheduling/retry, QPS/RU collection, and post-window closeout must
not invoke recovery. A normal measurement window may end with in-flight
business; that is not a benchmark failure and is reconciled only before a
later Run/rerun. Normal Run fails only for a proven business invariant/SQL
failure, metrics/telemetry failure, or infrastructure failure.

No contributor may label a domain repaired, create a combined candidate, run
E2E, or publish a QPS conclusion until the closure table and its real tests
are complete for Ride, Food, and Mart, and an independent exact-HEAD review
finds no P0. This gate can change only through an explicit user-approved
design change; time pressure, a clean import, a new dataset, a fail-closed
placeholder, or a partially passing recovery path is not a bypass.

Any change to shared Internet selected-run/recovery orchestration, a common
domain contract, or a reusable recovery test skeleton is a three-domain
change. It must be designed and reviewed against Ride, Food, and Mart
together, name each domain's production caller and proof, and carry
production-path regression coverage for every affected domain. A domain-local
repair must not silently change a shared contract, and a shared change must be
kept in its own reviewable commit rather than being hidden inside one domain's
implementation commit.

State-machine closure is also subject to a mandatory **production minimality
gate**. A persisted state or legal edge is justified only when its real
production semantics differ from adjacent alternatives in at least one of:
resource ownership/effect, legal successor set, transactional or ledger
effect, authoritative actor, or externally observable business disposition.
Different raw reason strings, report labels, test cases, or recovery routing
convenience alone do not justify separate states or edges; represent those as
sealed reason classes on the same production transition when their business
effects and successors are otherwise identical. Conversely, do not merge
states whose distinct resource or finance effects are required for truthful
replay and conservation. Every Internet registry review must therefore prove
both production reachability and minimality, identify redundant or overlapping
edges/states in one complete pass, and prefer the smallest state machine that
preserves the real Ride, Food, or Mart business model. Tests must derive the
approved registry rather than preserve an inflated tuple count for historical
test compatibility.

Reviewers are subject to this same gate and must load this section before
reviewing. A review must traverse the entire closure before returning: it must
aggregate every violation by domain/path/entry/class/outcome and every missing
test, rather than stopping after the first P0 or treating a partial review as
approval. The repair owner then fixes the complete aggregated list in one
domain-scoped change; only a fresh review of that exact post-repair HEAD may
approve it. A reviewer must trace every acceptance fixture backward to its
production predecessor transaction and reject any row that exists only because
the test assembled it directly.

## Product Front Door

The public product flow is exactly:

1. `init`
2. `prepare`
3. `run`
4. `cleanup`

Do not add `validate`, `report`, `archive`, or `closeout` as public product stages. Validation, reporting, and archive packaging are later `run` closeout concerns. `cleanup` only preserves or removes resources according to policy.

## Historical D10 Implementation Scope

The `D10-premium-1t-e2e` slice below is historical/inactive for the current
`internet-simulation-load` mainline. It may only become active again if the user
explicitly switches durable truth back to D10. While internet remains active,
agents must not use this section as the recovery entry, current node, first
legal action, or formal-delivery blocker.

For the historical `D10-premium-1t-e2e` slice, agents were allowed to create and
modify only these implementation surfaces:

1. `runs/**`
2. external project output such as `/Users/benjamin2037/Desktop/project/poc-three-version/output/D10-premium-1t-e2e.md`
3. premium environment probe evidence under the external project output tree
4. product code needed to close the current D10 product gap, which is the multi-node horizontal-pressure execution path and its hotspot-compatible closeout flow
5. this `AGENTS.md`

`D10-premium-1t-e2e` must not start a new-build formal pressure run until all of the following are true:

1. the current premium `1T` prepare reaches terminal success
2. one prepare-end backup baseline is taken and recorded
3. the `run` path supports real distributed physical pressure drivers rather than one-process logical workers
4. that distributed pressure path is generic to larger pressure-node pools, not a fixed two-node special case
5. hotspot pressure can use the same distributed path without falling back to one physical pressure node

Premium import must use generated source objects in the current user S3 bucket and must not pass a user-side Global Sort URI. Premium/TiDB owns Global Sort temporary placement.

## Drift And Bypass History

These are already observed failure modes in this project. Future changes must preserve the repaired behavior unless the frozen design is explicitly reopened and accepted.

1. Do not replace true numeric target sizing with readiness, smoke, customer-count overrides, fixed small counts, or any other reduced target.
2. Do not put TiForge, task, gate, workflow, readiness, smoke, planned execution state, or review-process semantics into product Go runtime concepts.
3. Do not generate formal S3 prepare data as complete local CSV files and upload them afterward. Formal S3 prepare uses direct bounded-memory source-object publication.
4. Do not use large complete-object in-memory single PUT for formal S3 source objects. Use streaming multipart behavior with receipts.
5. Do not move the frozen index placement back to all post-import DDL. Keep the inline runtime indexes in `CREATE TABLE` and only the frozen supplemental post-import indexes in `ADD INDEX`.
6. Do not drop table-level prepare/import checkpoint validation, stale-residue fail-closed behavior, statistics validation, BR boundary evidence, or 33-table prepare-load reporting.
7. Do not use `SELECT COUNT(*)`, review SQL, placeholder SQL, no-op SQL, or query-only probes as runtime fallback for unimplemented TPC-E statements.
8. Do not execute every SQL family on every pressure iteration. Runtime must follow TPC-E actor sequencing and CE deck selection; `Trade-Result` and `Market-Feed` are MEE byproducts of `Trade-Order`, not CE deck families.
9. Do not weaken timeline, semantic proof, blocked-statement, throughput, or attempt-root closeout guards to make a failed run look like a pass.
10. Do not treat old attempts created by previous binaries as current pass evidence after guard or receipt requirements changed.
11. Do not combine unrelated changes into one broad commit or use design ids, task ids, machine names, scale labels, or slash paths as commit subject prefixes.

## Frozen Prepare Contract

The current supported prepare source is:

1. `prepare.source_kind=generated_tpce`
2. `prepare.source_format=csv`
3. `prepare.import_executor=tidb_import_into_file`
4. `prepare.import_mode=import`

`prepare.csv_object_target_bytes` defaults to `536870912` bytes and is configurable. Treat it as a CSV source object target, not a scheduling chunk and not a product hard limit.

Future-declared but currently unsupported source combinations must fail closed before side effects. `IMPORT INTO ... FROM SELECT` is not a `tipoc` source kind; if configured, return `unsupported_prepare_source` because it reads existing TiDB query results rather than generating TPC-E data or migrating upstream MySQL.

Prepare data must not enter target tables through `INSERT`, `INSERT ... SELECT`, `LOAD DATA`, stage-table merge, `CREATE TABLE AS SELECT`, `IMPORT INTO ... FROM SELECT`, application row writers, or manual fill. Same-attempt table skip is valid only when run id, attempt id, run profile id, projection binding, table plan digest, and terminal imported state all match the current attempt checkpoint.

When `object_store.uri` is S3-compatible, formal prepare must stream generated CSV source objects directly into that object store. It must not create complete local CSV source files under the attempt root and then upload them, and large formal source objects must not be implemented as complete in-memory single PUT uploads. The S3 sink contract is bounded-memory multipart upload with rolling checksum, part receipt, complete/abort behavior, and `s3://...` dataset source URIs from generation time. Local filesystem CSV output is only for the no-object-store local development path.

Secondary index placement is frozen. Required inline indexes must appear in `CREATE TABLE` and be built with `IMPORT INTO`; the prepare-end ADD INDEX plan is intentionally limited to `i_dm_s_symb_date`, `i_t_s_symb_dts`, and `i_holding_ca_symb_dts`. Do not reintroduce an all-secondary-indexes post-import plan.

TiDB Global Sort workspace paths are internal import execution details. Scenario and testcase inputs provide only a base workspace URI. The TiDB import plan must derive and persist one table-scoped `global_sort_uri` per table, use that table URI in `CLOUD_STORAGE_URI`, and include it in the table import digest so checkpoint reuse cannot cross incompatible workspace bindings.

BR checkpoint commands must record the selected TiUP BR component in the
compiled manifest, checkpoint receipt, and restore plan. Empty configuration
means the default TiUP component `br`; live D8 attempts against a known
TiDB/TiKV version must set a matching component such as
`br:v9.0.0-beta.2.pre-nightly` instead of relying on an unversioned default that
can drift to an incompatible BR release.

The run receipt must report prepare load as benchmark evidence. `run-receipt.json` and `global-run-closeout.json` must both contain `prepare_load` with 33 catalog tables, 32 imported non-empty tables, and `trade_request` as the explicit empty prepare table. Empty prepare tables still count as created and prepared catalog tables.

## Runtime Actor Contract

Runtime work must preserve one global TPC-E securities world. Horizontal pressure nodes may own different CE deck token ranges, trade id leases, MEE shards, DM leases, and TradeCleanup ranges, but they must not invent independent worlds or query-only substitutes. TiDB remains the system under test; the pressure control plane must not introduce an unsharded hot-path coordinator.

Before any formal D10 E2E pressure run starts, the `run` path must support multi-node horizontal expansion in the same class as distributed generation. The legal split boundary is the worker slot and its attached actor ownership, deck range, and trade-id lease. Do not split one securities business-time causal chain into disconnected SQL fragments just to spread pressure.

The first accepted D10 distributed-run shape is static slot partition at run
start. Each physical pressure node executes its assigned slot set locally and
publishes one partial runtime report; the coordinator merges node reports and
performs one global closeout, but it must not become a per-statement hot path.

Hotspot pressure is not a separate shortcut path. A hotspot workload profile must continue to flow through the same worker-slot, actor, deck, and trade-id ownership model, and the distributed pressure path must remain valid when hotspot concentration requires more than one physical pressure driver.

D6 code must make state-machine and temporal-order constraints executable. At minimum, tests must cover Trade-Order before SendToMarket, SendToMarket before MEE-derived Trade-Result, ticker entry before Market-Feed, global DM sequence rotation before TradeCleanup, and pressure-node temporal bindings that connect deck range, trade id lease, MEE owner, and DM owner.

The `run` stage must execute a duration-based pressure window, not one state-machine pass per worker. The run receipt and global closeout must expose elapsed seconds, executed statement count, measured statement QPS, and the minimum required statement QPS. Semantic evidence may be sampled to stay bounded, but aggregate throughput counts must reflect the full pressure window.

The `run` stage must also expose prepare load evidence in both `run-receipt.json` and `global-run-closeout.json`: 33 catalog tables, 32 imported non-empty prepare tables, and `trade_request` as the explicit empty prepare table. Empty prepare tables still count as created and reported tables.

Workload hotspot simulation must be implemented as an explicit workload profile, not as hardcoded SQL literals. The canonical profile must preserve the default TPC-E lineage. Hotspot profiles may bias customer, account, security, symbol, broker, or recent-trade selection through manifest-visible profile parameters and deterministic lineage seeds, while still consuming CE deck tokens and preserving MEE, DM, TradeCleanup, timeline, and horizontal ownership semantics. Manifest, receipt, and report output must expose the selected profile and observed distribution summary before a hotspot run can be accepted.

## Naming And Comment Rules

Do not use `50G`, `premium`, machine names, run ids, attempt ids, task ids, gate ids, week ids, or TiForge workflow labels as Go package names, identifiers, fixture names, command names, or product runtime concepts.

Go comments may explain product or test semantics only. Do not write comments about TiForge gates, task ids, workflow status, or process bookkeeping inside Go files.

Formal product code must not use `readiness`, `smoke`, customer-count override fields, or fixed small customer counts as prepare/run sizing logic. Bounded preflight and unit tests must use explicit numeric byte targets, and D8 must use calibration-first sizing from sampled CSV row widths plus TPC-E cardinality formulas.

Live runtime SQL must not fall back to `SELECT COUNT(*)`, review SQL, placeholder SQL, or query-only probes for unimplemented TPC-E statements. Unimplemented statements must be explicit blockers until their securities semantics are implemented.

Generated artifacts under `runs/**` may contain stale evidence from earlier blocked attempts. Do not treat old `runs/**` receipts or manifests as current product behavior; create a fresh attempt after product code changes.

## Executable Guard Lines

Before continuing product implementation or D8 execution after a correction, run the project-level guard from the parent project root:

`python3 tools/tiforge_execution_guard.py`

Before any formal `build`, `deploy`, or `rerun`, run the formal delivery gate from the parent project root:

`python3 tools/tiforge_execution_guard.py --formal-delivery`

For a focused Go lint check, run from the parent project root:

`python3 tools/go_lint_guard.py`

From this product repository, the same product-scoped lint entry is:

`python3 tools/go_lint_guard.py`

## Commit Rules

Use small reviewable commits whose subject starts with the smallest unique package/module/capability prefix, for example `executor: wire prepare stage`, `objectstore: stream source objects`, `tidb-schema: add catalog projection`, or `securities-schema: add TiDB adapter`. Commit prefixes must not contain `/`, must not use broad ambiguous names when a smaller unique prefix exists, and must never use design or DAG labels such as `D1`, task ids, gate ids, week ids, evidence ids, machine names, scale profiles, or deployment labels. Do not leave a broad product implementation as untracked files and commit it as one large blob; split by package/module or named sub-slice and run the relevant checks before each submitted sequence is treated as ready.

Once a bounded fix or optimization slice passes its relevant focused checks, commit that slice before starting the next independent issue. End-to-end verification may be the final check for a slice when needed, but verified code must not remain uncommitted while later optimizations begin. Do not let multiple proven fixes accumulate in one dirty worktree and separate them afterward.

Formal `build`, `deploy`, and `rerun` must use committed source only. They must not start from `main` or `master`, from staged-but-uncommitted diffs, from unstaged tracked diffs, or from untracked product files. If the active workspace must stay dirty for other in-flight work, create a clean review branch or clean worktree for the committed revision and run the formal delivery gate there first.

Future repository changes must use the issue-driven, review-gated PR path: create or reference a GitHub issue with the user-visible objective and acceptance criteria, create a clean local worktree on a non-`master` branch, commit and verify the bounded change there, open a PR linked to the issue, start code review, wait for at least one approving review with required conversations resolved, and only then merge the reviewed PR into `master`. Do not self-merge unreviewed PRs. Direct pushes to `master` are not the normal path and require explicit emergency approval.

This guard runs `gofmt -l`, `go vet ./...`, `staticcheck ./...`, and the pinned Revive safety profile in `tools/revive.toml`. Revive replaces the deprecated golint binary; the reviewed decision and rule scope are recorded in `docs/LINT-TOOLING-DECISION.md`.

For real D8 attempt closeout, run:

`python3 tools/tiforge_execution_guard.py --attempt-root <attempt evidence root>`

The guard must fail if Go formatting, `go vet`, or staticcheck fail, or if formal product Go source contains workflow/process pollution, readiness or smoke sizing, fallback substitutions, planned execution states, review SQL fallbacks, blocked live runtime statements, missing `50G` calibration, incomplete four-stage evidence, missing 33-table prepare load evidence, missing throughput evidence, `statement_qps < 10000`, or a non-passing run closeout.

## Environment Operation Profiles

Reusable environment-specific operation profiles live under `scripts/env/**`.
For the active D10 staging premium `1T` `a005` lane, use
`scripts/env/premium/d10-a005/README.md` as the operator entry point. That
profile records the fixed pressure-node addresses, remote attempt root, remote
binary path, remote DSN secret-file path, TiDB schema, Clinic cluster binding,
four-node startup script, run evidence collection script, SQL evidence
collection script, and Clinic metric collection script.

Human operators and AI agents must use the profile scripts instead of
rediscovering or hand-rebuilding those paths during each optimization loop.
When another deployment environment needs different cluster ids, nodes, remote
roots, schema names, Clinic endpoints, or monitoring expressions, create or
update the matching environment profile and record the proven delta there.
Preserve old working profiles unless the deployment is explicitly retired.

User process feedback is an execution input, not chat memory. Accepted
feedback about repeated mistakes, wasted benchmark time, missing worker
reaping, missing SOP use, missing early-stop behavior, or missing evidence
classification belongs in the external project context, not in tracked product
source. When a formal delivery needs a process-feedback ledger, set
`TIPOC_PROCESS_FEEDBACK_LEDGER` to that external ledger path. D10-specific
execution checklists and recovery digests should likewise be provided through
`TIPOC_D10_EXECUTION_CHECKLIST` and `TIPOC_D10_RECOVERY_DIGEST` when that
historical lane is active. `tools/process_feedback_guard.py`,
`tools/d10_execution_checklist_guard.py`, and `tools/formal_delivery_guard.py`
validate configured external context but a fresh product checkout does not
track those context files.

For the D10 200K QPS loop, each concrete code or configuration fix must be
validated through the proven `scripts/env/premium/d10-a005/README.md` path as
soon as the fixed build is ready. After the run stabilizes, if it does not
exceed the r11 `105410.39333333333 statement QPS` high-water baseline, stop it,
preserve evidence, classify the miss, and move to the next repair instead of
waiting for a full window. Heavy side work such as process-rule sedimentation,
long evidence analysis, or independent review must run in bounded workers and
must be consumed into future-loaded surfaces before the worker is closed.

For the active D10 a005 lane, every optimization loop must also load
`scripts/env/premium/d10-a005/negative-optimization-rca.md` and run
`python3 scripts/env/premium/d10-a005/optimization-direction-guard.py` before selecting
a repair direction, committing to a build, or launching a formal rerun. The
`start-4node-run.sh` launcher enforces this by requiring a per-label
`optimization-direction.guard` receipt. This is an active convergence guard:
already disproved split/preflight work, provenance-free warmup attribution, and
cross-object hot-write transaction grouping must not be rediscovered as fresh
ideas, and slow-query repair must proceed by query class with runtime evidence.
One failed tactic does not dethrone its slow-query or slow-transaction class:
if that class remains the current MaxHead, the next optimization must stay
inside the class with a corrected cost model instead of jumping to a lower
ranked query family.

## TPC-E Fidelity Guard

The product target is a TPC-E-derived securities brokerage simulation. Query-only workloads, old nine-table projections, independent per-pressure-node pseudo worlds, and SQL execution without securities lineage are not valid completion substitutes. Downstream nodes must preserve CE, MEE, BrokerageHouse/SUT, DM, TradeCleanup, history-first state, global deck ownership, trade id leases, and distributed runtime topology as frozen in the parent design.