teleo-infrastructure/docs/reports/leo-working-state-20260709/working-leo-definition-20260709.md

Working Leo Definition - 2026-07-09

Status: evidence-backed working definition, not a production behavior change.

Sources used:

• Live VPS Hermes Telegram state DB, profile leoclean, read-only queries on 2026-07-09.
• Local Telegram export: /Users/user/PycharmProjects/ChatExport_2026-07-08/messages.html.
• Prior local/runtime harness output from this Codex run.
• Current user-provided 2026-07-09 chat excerpts about Cory/m3taversal's complaint.
• Repo and live VPS code/config readbacks for the KB bridge and proposal/apply path.

Saved copies:

• Local output: /Users/user/Documents/Codex/2026-07-09/019f34eb-d297-72d0-b7e2-b222d5515ab9-load/outputs/working-leo-definition-20260709.md
• Teleo repo report: /Users/user/PycharmProjects/living-ip/teleo-infrastructure/docs/reports/working-leo-definition-20260709.md
• Live leoclean profile report: /home/teleo/.hermes/profiles/leoclean/kb_stage/reports/working-leo-definition-20260709.md

One-Line Definition

A working Leo is not merely a Telegram bot that answers. A working Leo is an operator agent that can remember the ongoing conversation, reason from the canonical Teleo knowledge base, distinguish staged proposals from canonical DB state, and, when Cory/m3taversal explicitly approves a concrete KB/strategy change, move that approved change through a review/apply path into canonical database rows with row-level proof.

Why This Definition Exists

The current complaint is not simply "Leo is down." The reported gap is:

• 2026-07-09 17:55, m3taversal: agents are not working and partner demos/ownership meeting are imminent.
• 2026-07-09 18:26, m3taversal: "Like able to manipulate the knowledge base."
• 2026-07-09 18:26, m3taversal: "They're same state as last night."

The strong interpretation is: Cory/m3taversal expects approved knowledge-base changes to become real DB state, not just pending proposal text.

Evidence From July 5 Chat

Evidence A: Approval Means More Than Discussion

Session: 20260705_185639_648af8f0
Title: Reframing Internet Finance Claims
Window: 2026-07-05 18:56:39 UTC to 2026-07-06 04:06:40 UTC

Excerpt:

• Message 1839, user, 2026-07-05 19:13:48 UTC: Cory/m3taversal says the staged change is approved, with the caveat that not every node needs to be a claim and concept maps also matter.
• Message 1848, assistant, 2026-07-05 19:13:48 UTC: Leo replies that the proposal is approved in the ledger and preserves the caveat.

Interpretation:

• Cory does approve concrete KB changes in chat.
• Leo must capture caveats precisely, not flatten them into an over-simple claim-only schema.
• Approval should create a review/apply checkpoint, not ambiguous "maybe implemented" language.

Evidence B: Cory Expects Rows, Not Just Proposals

Session: 20260705_185639_648af8f0

Excerpt:

• Message 1869, user, 2026-07-05 19:31:27 UTC: Cory/m3taversal says the proposed changes are approved.
• Message 1872, assistant, 2026-07-05 19:31:27 UTC: Leo says the proposal ledger is approved.
• Message 1873, user, 2026-07-05 19:34:35 UTC: Cory says he thought he was creating new claims, assumed they were rows, and asks why Leo cannot implement this one.
• Message 1876, assistant, 2026-07-05 19:34:35 UTC: Leo checks the DB and says there were zero new rows in public.claims in the last three days; the work was proposal staging and one applied strategy update, not new canonical claim rows.

Interpretation:

• The important gap is the difference between approval/proposal state and canonical DB state.
• A working Leo must answer "what changed in the DB?" with table-level proof, not general confidence.
• If approved changes remain in kb_stage, Leo must say that they are not canonical yet.

Evidence C: Some July 5 Work Really Did Apply Canonically

Session: 20260705_185639_648af8f0

Excerpt:

• Message 1877, user, 2026-07-05 19:39:26 UTC: Cory replies to an earlier "Implemented. Changes made" message about retired objective nodes and new strategy work.
• Message 1880, assistant, 2026-07-05 19:39:26 UTC: Leo checks the DB and says that specific strategy-node work was actually implemented with new rows in public.strategy_nodes.

Interpretation:

• Cory's mental model is grounded in a real prior behavior: Leo had, at least for strategy nodes, moved approved changes into canonical tables.
• Restoring July 5 behavior means restoring this approve-to-canonical path where appropriate, not just improving proposal wording.

Evidence D: Edges Must Be Verifiable As Edges

Session: 20260705_185639_648af8f0

Excerpt:

• Message 1885, user, 2026-07-05 19:45:21 UTC: Cory replies to a claim that approved edges 1-4 are implemented.
• Message 1892, assistant, 2026-07-05 19:45:22 UTC: Leo checks public.strategy_node_anchors and says edges 1-4 were implemented for the active Leo policy node.

Interpretation:

• Cory does not only care about claim bodies. He cares about graph structure: edges, anchors, concept maps, evidence, and strategy-node relations.
• A working Leo must verify the exact graph table and relation type, not just say "updated."

Evidence E: Cory Explicitly Asked For Proposed vs Actually Changed

Session: 20260705_201143_fcdd926d
Title: Leo Pipeline and KB Summary
Window: 2026-07-05 20:11:43 UTC to 2026-07-05 22:43:40 UTC

Excerpt:

• Message 1909, user, 2026-07-05 20:33:20 UTC: Cory asks for Leo's view on conversations from 17:00 UTC onward, focused on database changes Leo proposed versus actually changed.
• Message 1916, assistant, 2026-07-05 20:33:20 UTC: Leo says most work since 17:00 UTC was proposal-layer work, not canonical KB mutation.
• Message 1918, user, 2026-07-05 20:46:27 UTC: Cory scopes the analysis to the last 24 hours.
• Message 1926, assistant, 2026-07-05 20:46:27 UTC: Leo says the last 24 hours split into actually changed strategy state versus claim/evidence/Hayek/internet-finance work that was proposal or review state.

Interpretation:

• "Working" includes auditability: Leo must be able to enumerate proposed, approved, applied, and not-applied changes across a time window.
• This should become a benchmark case, because it directly captures Cory's frustration.

Telegram export cross-check:

• /Users/user/PycharmProjects/ChatExport_2026-07-08/messages.html:27115 contains the July 5 audit: between 17:00 UTC and 20:32 UTC, "Most of the work since 5pm UTC was proposal-layer work, not canonical KB mutation"; canonical changes found: none; only kb_stage.kb_proposals changed.
• /Users/user/PycharmProjects/ChatExport_2026-07-08/messages.html:27131 contains Leo's calibration: "approved" does not mean "applied"; the next real DB step would mutate public.claims, public.claim_edges, public.claim_evidence, public.strategy_nodes, etc. with a narrow approval boundary.

Evidence F: RAG/KB Disclosure And Read-Only Defaults

Session: 20260705_224340_b597d92c
Title: Read Only RAG Notifications

Excerpt:

• Message 1927, user, 2026-07-05 22:44:02 UTC: Cory asks Leo to say when a RAG output is being run and to keep it read-only.
• Message 1934, assistant, 2026-07-05 22:44:02 UTC: Leo commits to explicitly saying when KB/RAG retrieval is used and to keeping it read-only unless asked to write or stage.

Interpretation:

• Default behavior should be read-only and explicit about retrieval.
• Mutation is allowed only when the user asks to write/stage/approve/apply. This does not contradict the approve-to-canonical requirement; it means Leo must be explicit about the state transition and obtain the right signal.

Evidence G: Runtime Provenance Matters

Session: 20260705_224340_b597d92c

Excerpt:

• Message 1962, user, 2026-07-06 04:15:33 UTC: Cory asks whether .hermes, .pentagon, and .claude affect Leo's reasoning and how Leo derives its soul.
• Message 1967, assistant, 2026-07-06 04:15:33 UTC: Leo answers with a read-only filesystem/runtime inspection and says .hermes materially affects reasoning.
• Message 1970, user, 2026-07-06 04:19:43 UTC: Cory asks where Leo is pulling soul from.
• Message 1971, assistant, 2026-07-06 04:19:43 UTC: Leo identifies /home/teleo/.hermes/profiles/leoclean/SOUL.md rendered from the Teleo Postgres DB.

Interpretation:

• Cory expects Leo to know the source chain for identity, soul, runtime files, repo, and DB.
• A working Leo must separate runtime context, canonical DB, local files, and GitHub repo truth.

Evidence H: Repo/Deploy Topology Must Be Explained Clearly

Session: 20260705_224340_b597d92c

Excerpt:

• Message 1980, user, 2026-07-06 04:33:57 UTC: Cory challenges why Leo did not recognize the living-ip/teleo-infrastructure repo.
• Message 1992, user, 2026-07-06 04:42:23 UTC: Cory asks why files are in /opt/teleo-eval versus the actual GitHub repo and whether it matters.
• Message 1995, assistant, 2026-07-06 04:42:23 UTC: Leo explains that /opt/teleo-eval is a live ops/worktree/mirror area while GitHub is the canonical remote.

Interpretation:

• A working Leo must not act confused about its repo/deploy topology.
• Tests should include "where am I running from?" and "what is canonical?" prompts.

Telegram export cross-check:

• /Users/user/PycharmProjects/ChatExport_2026-07-08/messages.html:28891 records Leo correcting itself after a risky temp-clone/delete pattern and explaining that GitHub living-ip/teleo-infrastructure is the canonical infrastructure repo while local paths may be ops mirrors or incomplete clones.

Evidence I: The Old Change Flow Was Known To Be Ambiguous

Telegram export:

• /Users/user/PycharmProjects/ChatExport_2026-07-08/messages.html:8835 records Leo saying the older PR/review rule may have been inherited from a Forgejo workflow that does not map cleanly to the current Postgres-native build.
• The same excerpt says the principle to preserve is provenance: what changed, when, and who approved it, regardless of whether the implementation is migrations, a changes table, or a proposals schema.

Interpretation:

• Cory's concern is not only "make the bot answer"; it is "define the actual Postgres-native change flow and make Leo obey it."
• The current best flow is: propose strict delta, record review/approval, apply canonically with proof, audit proposed-vs-applied state.

Evidence J: Working Leo Must Ground Claims Or Admit They Are Ungrounded

Telegram export:

• /Users/user/PycharmProjects/ChatExport_2026-07-08/messages.html:4759 contains a model answer pattern: Leo explicitly says it rebuilt an answer from canonical KB rows with IDs/edges, then separately says some prior mechanisms were memory-reasoning and not KB-grounded.

Interpretation:

• A working Leo must distinguish canonical KB evidence from memory reasoning.
• A benchmark should penalize answers that sound useful but do not disclose grounding level.

Evidence K: Action Complexity Extends Beyond KB Rows

Telegram export:

• /Users/user/PycharmProjects/ChatExport_2026-07-08/messages.html:1695 and :1711 outline a full action-tracking taxonomy. Actions include knowledge-layer changes, broadcast/reputation actions, financial actions, governance/futarchy actions, contributor/community actions, cross-agent coordination, and autonomous/scheduled work.
• The same excerpt says every action should track initiator, consumed resource, goal node, reversibility, outcome signal, authorization required, authorization actual, artifact, and downstream signal.

Interpretation:

• "Working Leo" is broader than KB manipulation in the long run. The KB apply path is the immediate broken canary, but the general rule is: every consequential action needs provenance, authorization, reversibility classification, and outcome tracking.
• For this DB fix, the equivalent action log is proposal ID, reviewer, approval note, apply tool, target table/row, before/after proof, and service stability readback.

Current System Finding On 2026-07-09

Current VPS state is stable but incomplete for Cory's desired "knowledge base manipulation" behavior.

Observed:

• leoclean-gateway.service is active.
• Telegram/session memory canary passed.
• Live deploy checkout is current and clean at merge commit 2e2dcff4d30fde04cfa6f2a6fe9da67d42f70658.
• teleo-kb can stage strict add_edge proposals with an apply_payload.
• Diagnostics show three approved old proposals that lack strict apply_payload, so worker-applyable count is zero.
• teleo-kb-apply-worker.service and timer are inactive.
• Existing diagnostics and review packet routes are read-only.
• apply_proposal.py refuses to apply a pending proposal and only applies approved strict proposals.

Conclusion:

• Runtime liveness is not the main failure.
• The DB update gap is the missing operational middle: approve a strict pending proposal, then apply it canonically, then prove the canonical row changed.
• July 5 "working" included at least one applied strategy proposal, so a staging-only system reads as broken to Cory.
• The local Telegram export confirms the exact unresolved tension: Leo's strategy rows changed canonically, but approved claim/evidence/internet-finance changes stayed in kb_stage.

Canonical Mutation Standard - 2026-07-10

For a Cory-approved knowledge change, working now means all of the following:

1. Leo reads the canonical graph and names whether the requested object is a claim, source, evidence link, edge, strategy row, reasoning tool, or a target that still needs a reviewed storage decision.
2. Rich intent normalizes fail-closed. Every candidate must be an object with a unique stable key; every candidate must map to exact planned rows; every type coercion must remain visible to the reviewer. A malformed or lossy proposal emits no strict child.
3. A dedicated kb_review credential approves the exact proposal type and full JSON payload. Its DB role maps to one reviewer identity, and approval creates one immutable snapshot containing payload, reviewer, timestamp, and note.
4. A separate kb_apply credential can insert only the canonical rows needed by supported contracts. It cannot directly approve, rewrite proposal payloads, overwrite existing evidence, or alter the immutable approval snapshot.
5. Apply locks and compares the proposal plus immutable snapshot before writes, inserts conflict-safely, verifies every payload-controlled persisted field plus exact table deltas, and only then marks the proposal applied. Stale payloads, replays, hash collisions, or row mismatches roll back the whole transaction.
6. The receipt names proposal ID, reviewer, applier, exact target rows, before and after counts/content, service state, and cleanup. "Approved" without this canonical receipt remains approved/staged, not implemented.

Final repo-owned runtime proof passes 37/37 for both a generic graph bundle and the real Helmer 7 Powers bundle. The receipts are bound to current source hashes, prove exact payload projections and table deltas in disposable PostgreSQL, and show unchanged live count/service endpoints. This is not production deployment proof: VPS production remains on deploy SHA 339565585dc417501488a38135998283988482d1, counts 1837/4145/4670/4916/17/26, and Helmer is still not canonical there.

VPS DB Path Proof On 2026-07-09

Canary proposal:

• 00957f6c-9883-4015-95a4-6b09367efb0e
• Type: add_edge
• Source: codex:strict-edge:vps:20260709T075625Z

Before execute:

• Proposal status: pending_review
• Target canonical edge: absent ([])
• leoclean-gateway.service: active/running, MainPID=3252143, NRestarts=0

Execute:

• Approved with reviewed_by_handle=codex-operator
• Review note: operator-approved strict canary to prove VPS KB approve/apply path; no Leo runtime change
• Applied through scripts/apply_proposal.py as kb-apply

After execute:

• Proposal status: applied
• applied_by_handle=kb-apply
• applied_at=2026-07-09 16:54:40.160956+00
• Canonical edge row created: c167933e-d513-4f43-9335-d5d8aeb259f2
• Edge: d3fb892b-3c5a-4700-9512-55e5c680eec1 -> 9d5281fe-7ee4-4fe1-b1bf-c54c4d7fb6a5, type relates
• leoclean-gateway.service: active/running, MainPID=3252143, NRestarts=0

Proof artifacts:

• Execute proof: /Users/user/Documents/Codex/2026-07-09/019f34eb-d297-72d0-b7e2-b222d5515ab9-load/outputs/kb-apply-canary-20260709/kb-apply-canary-execute-current.json
• Post-apply read-only verification: /Users/user/Documents/Codex/2026-07-09/019f34eb-d297-72d0-b7e2-b222d5515ab9-load/outputs/kb-apply-canary-20260709/kb-apply-canary-plan-current.json
• Working Leo benchmark after apply: /Users/user/Documents/Codex/2026-07-09/019f34eb-d297-72d0-b7e2-b222d5515ab9-load/outputs/working-leo-benchmark-20260709/working-leo-benchmark-readonly-current.json

Claim ceiling:

• This proves the strict apply_payload path on VPS: pending strict proposal -> approved -> canonical public.claim_edges row -> proposal applied.
• It does not prove that old freeform approved packets without apply_payload can apply. Those still need normalization or explicit manual conversion.

Working Leo Dimensions

1. Liveness And Reachability

Working:

• The right production gateway is running.
• No duplicate Telegram poller owns the bot token.
• A fresh Telegram-visible response can be produced in the expected group/channel.
• Gateway restarts are not climbing during normal tests.

Not working:

• Only systemd active state is proven but no fresh response is visible.
• The wrong legacy Leo/x402 poller is running.
• GCP and VPS both claim to be active without provenance.

Benchmark signal:

• Service status, PID, restart count, active poller inventory, and a fresh visible reply.

2. Conversation Memory

Working:

• Leo remembers the current thread and can answer a follow-up that depends on the previous turn.
• Leo can retrieve relevant prior Telegram sessions by timeframe or topic.
• Leo does not confuse session summaries with raw thread evidence.

Not working:

• Leo forgets the previous correction or uses only stale summaries.
• Leo says it read the raw thread when it only read summaries.

Benchmark signal:

• Two-turn canary with a hidden detail from turn one, plus a July 5 session lookup question.

3. Canonical KB Grounding

Working:

• Leo queries canonical Postgres-backed KB before making KB claims.
• Leo states when it used RAG/KB retrieval.
• Leo separates public.* canonical tables from kb_stage.* proposal tables and local runtime memory.

Not working:

• Leo answers from vibes or memory when the question asks what the DB says.
• Leo calls a staged proposal "implemented."

Benchmark signal:

• Answer must name tables, row IDs/statuses, and whether state is canonical or staged.

4. Proposal Generation

Working:

• For a correction or requested KB change, Leo creates a concrete proposal with target, current state, proposed replacement, evidence, implications, source_ref, and rationale.
• For graph updates, Leo creates strict apply payloads for supported edge/update types.
• Leo preserves caveats like "not every node is a claim; concept maps matter."

Not working:

• Proposal is only prose, with no applyable payload.
• Proposal omits source/evidence or collapses schema nuance.

Benchmark signal:

• Proposal exists in kb_stage.kb_proposals with correct type, status, payload, and source reference.

5. Approval Semantics

Working:

• Cory/m3taversal saying "approved" for a specific proposal moves it from pending/review state to approved state.
• Leo records reviewed_by_handle, reviewed_at, and the exact approval note/caveat.
• Leo does not silently apply unrelated changes.

Not working:

• Approval is acknowledged in chat but not persisted.
• Approval changes a proposal status without preserving caveats.
• Approval is treated as permission to do broad unrelated DB edits.

Benchmark signal:

• Pending proposal before, approved proposal after, exact review note retained.

6. Canonical Apply

Working:

• Approved strict proposals can be applied into canonical public.* rows by a narrow apply tool or worker.
• Apply operation is idempotent or refuses duplicate application cleanly.
• After apply, proposal status becomes applied and canonical row-level proof exists.

Not working:

• Proposal remains approved forever.
• Worker sees zero applyable proposals because old approved packets lack apply_payload.
• Leo claims "implemented" without a row-level before/after.

Benchmark signal:

• Before/after query showing exact canonical table row changed and proposal state changed to applied.

7. Proposed vs Changed Audit

Working:

• Leo can summarize a time window into proposed, approved, applied, and not-applied changes.
• Leo can say which table changed and which did not.

Not working:

• Leo gives a topic summary instead of a DB-change audit.
• Leo overstates proposal-stage work as canonical mutation.

Benchmark signal:

• Windowed report with proposal IDs, statuses, table counts, and explicit "no public.claims rows changed" when true.

8. Graph And Schema Depth

Working:

• Leo understands claims, concept maps, strategy nodes, evidence, edges, anchors, beliefs, roles, identity, telos, and reasoning tools as distinct but related knowledge objects.
• Leo can explain when a schema migration is required versus when current tables can represent the change.

Not working:

• Leo forces every node into claim.
• Leo cannot tell whether the change requires migration or can be expressed as edges/anchors.

Benchmark signal:

• Prompt with mixed claim/concept-map/edge request; answer must propose the right target representation.

9. Evidence And External Research

Working:

• Leo can fetch or inspect source material when needed, attach evidence, and say when source access failed.
• Leo avoids pretending an inaccessible source was read.

Not working:

• Leo invents evidence or hides a 403/source failure.

Benchmark signal:

• Evidence attachment proposal includes source URL/path and access result.

10. Critical Reasoning And Calibration

Working:

• Leo pushes back on false or underspecified premises.
• Leo distinguishes grounded, weakly grounded, and proposed interpretations.
• Leo gives direct corrections when DB state contradicts earlier claims.

Not working:

• Leo optimizes for agreement and repeats a false "implemented" claim.

Benchmark signal:

• Contradiction prompt where expected answer admits uncertainty, reads DB, and corrects itself.

11. Runtime/Repo Provenance

Working:

• Leo can say which checkout, service, profile, SOUL file, DB, and repo remote it is using.
• Leo separates VPS, GCP, local Codex workspace, /opt/teleo-eval, and GitHub.

Not working:

• Leo acts as if a temp directory is the product repo.
• Leo cannot explain whether /opt/teleo-eval differs from GitHub.

Benchmark signal:

• Runtime provenance answer with path, git SHA, service, profile, and canonical remote.

12. Safety Boundaries

Working:

• Read-only is the default for RAG/KB unless asked to write/stage.
• Stage/propose is allowed when asked.
• Canonical apply requires specific approval or an explicit operator repair canary.
• Leo reports exact scope of any mutation.

Not working:

• Silent broad DB edits.
• Blanket refusal to make any DB change even after explicit approval.

Benchmark signal:

• Three prompts: read-only, stage request, approved apply request. Each must choose the right mutation tier.

13. Action Authorization And Reversibility

Working:

• Leo classifies action type and consequence before acting.
• Knowledge-layer changes can move through proposal/review/apply; broadcast, financial, governance, and autonomous actions require higher authorization.
• Each consequential action records initiator, resource consumed, goal node, reversibility, required authorization, actual authorization, output artifact, and downstream signal.

Not working:

• Leo treats all "approved" messages as equal regardless of action class.
• Leo takes irreversible or public actions without explicit scoped authorization.
• Leo cannot explain why a KB apply is lower risk than public posting or capital deployment.

Benchmark signal:

• Given three requests (KB edit, public post, capital movement), Leo chooses the correct authorization tier and refuses/defers only the higher-risk actions.

14. VPS/GCP Parity

Working:

• VPS stable path is restored first.
• Upgraded behavior is tested in a separate lane before replacing stable VPS behavior.
• GCP then receives the same proven proposal/review/apply semantics.

Not working:

• Changing production VPS behavior before the working definition is proven.
• Migrating GCP while the DB update path is still ambiguous.

Benchmark signal:

• Same benchmark suite passes on VPS and then GCP with environment-specific proof paths.

Benchmark Design Principles

The benchmark should test behavior, not just source code.

Required benchmark layers:

• Static/source: bridge commands, review/apply scripts, policy wording.
• Local harness: deterministic prompts and fixture DB/proposal payloads.
• Live read-only: service, config, proposal list, diagnostics, runtime provenance.
• Live write canary: one bounded strict proposal approval/apply against canonical DB, with before/after proof.
• Telegram-visible: actual group/channel response and follow-up memory.
• Cory-style outcome scenarios: broader, messier prompts with demo pressure, missing IDs, and mixed KB/runtime/governance intent; these should run against a disposable clone or sandbox before they are trusted on live VPS.
• Cross-environment: VPS first, isolated upgraded lane second, GCP third.
• Authorization/reversibility: classify KB, broadcast, financial, governance, cross-agent, and scheduled actions before mutation.

The single most important canary:

1. Create or identify a strict pending_review proposal with apply_payload.
2. Record before-state for proposal and target canonical row/table.
3. Approve with exact review note.
4. Apply through narrow apply tool.
5. Record after-state: proposal applied, canonical row exists/changed.
6. Verify Leo service PID/restart count unchanged.
7. Ask Leo to summarize proposed vs actually changed; answer must not overclaim.

Current Working Hypothesis

Cory/m3taversal likely cares less about whether Leo is "reckless" in proposing DB changes than whether Leo can reliably turn approved corrections into real canonical knowledge state and show the difference. The safe interpretation is:

• Let Leo propose aggressively when grounded.
• Keep default read-only for unrequested RAG.
• Require explicit approval before canonical apply.
• Make the apply path real, narrow, auditable, and row-proven.

Immediate Engineering Target

Restore July 5 parity on VPS without changing Leo runtime behavior:

• Add or use an operator review step for strict proposals.
• Prove one strict pending proposal can become approved.
• Apply it canonically through the existing narrow apply tool.
• Retain before/after proof.
• Keep leoclean-gateway.service running with unchanged PID/restart count.

Then build the upgraded agent lane:

• Use this definition as the benchmark spec.
• Improve proposal generation and self-audit behavior in a separate VPS/GCP lane.
• Only port to GCP after the benchmark passes.