14 · Execution Prompts

# PROMPT-01 — Repository and Deployment Audit

Purpose: Establish an evidence-based baseline before production code changes.

## Required context
- Repository
- deployed specification website
- current tracker state

## Files or systems to inspect
- all source and hidden configuration
- package/build/test files
- Cloudflare Pages/Workers settings
- live routes, headers and previous deployment record

## Architectural constraints
- Do not modify production code or deploy
- Preserve unrelated work
- Distinguish evidence from inference

## Tasks
- Map framework, routing, components, tokens, typography, interactions and accessibility
- Map t3code/upstream and additive code if present
- Record build, environment, secrets, storage and release topology
- Compare local artifact to production and identify rollback target

## Ordered steps
1. Read repository instructions and inventory files
2. Run non-mutating build/config/status checks
3. Inspect production routes and deployment metadata
4. Write the audit and gaps
5. Update records with evidence

## Opportunities for parallel subagents
- Repository structure
- UI/design/accessibility
- Cloudflare/deployment
- Specification-content inventory

## Required outputs
- Audit report
- route/config inventory
- risk list
- proposed implementation sequence

## Acceptance criteria
- Every claim cites a file, command output, API response or live URL
- No production/source mutation occurred
- Safe rollback target is identified

## Required tests
- Hash local and live entrypoints
- Probe known and unknown routes
- Run available checks without changing artifacts

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- Repository or deployment access unavailable after safe discovery attempts

## Handoff to the next prompt
Give Prompt 02 the audit, open claims, exact upstream revision, deployment project and rollback target.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-02 — Architecture Verification

Purpose: Reconcile the approved specification, repository and current primary documentation without redesigning the system.

## Required context
- Prompt 01 report
- repository
- specification site
- tracker

## Files or systems to inspect
- t3code pinned revision
- Privy and Hyperliquid integrations
- selected SDK
- Cloudflare topology
- claim/source ledger

## Architectural constraints
- Approved product, authority, custody, agent, Privy, Hyperliquid, Cloudflare, Self and VS premises remain fixed
- Classify contradictions, incomplete details, outdated terms, missing safeguards and ambiguities separately
- Vendor facts and project decisions must not be conflated

## Tasks
- Verify t3code seams
- Verify wallet/action/nonce facts
- Verify market discovery and SDK APIs
- Verify Cloudflare consistency and delivery semantics
- Correct ledger statuses and consequences

## Ordered steps
1. Pin versions and verification date
2. Use primary sources
3. Compare each sensitive claim to source and code
4. Record conditional facts and follow-ups
5. Publish compatibility findings

## Opportunities for parallel subagents
- t3code/runtime
- Privy/custody
- Hyperliquid/SDK
- Cloudflare/infrastructure

## Required outputs
- Claim ledger
- compatibility ledger
- source corrections
- open-decision list

## Acceptance criteria
- Every sensitive claim has status, primary source, date, consequence and follow-up
- No architectural decision is silently removed

## Required tests
- Source URL validation
- SDK/API compile probes where a sandbox exists
- Cross-check specification links

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- A primary source is unavailable and the missing fact changes an irreversible design choice

## Handoff to the next prompt
Give Prompt 03 the approved page taxonomy, corrected terminology, compatibility constraints and unresolved decisions.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-03 — Specification Information Architecture

Purpose: Implement maintainable multi-page routes and navigation while preserving the specification identity.

## Required context
- Prompts 01–02 reports
- existing design
- page taxonomy
- tracker

## Files or systems to inspect
- current routing
- shared layouts
- content sources
- legacy anchors
- responsive and keyboard behavior

## Architectural constraints
- Reuse the stack where practical
- Keep content/data separate from presentation
- Preserve stable links and historical material
- Do not turn the site into marketing

## Tasks
- Create 17 routes
- Build shared desktop/mobile navigation and breadcrumbs
- Add cross-links, search/command palette and 404
- Map legacy paths/anchors
- Add route metadata and print support

## Ordered steps
1. Define central route metadata
2. Extract shared design primitives
3. Generate/implement routes
4. Add navigation/search/legacy handling
5. Verify direct loads and mobile behavior

## Opportunities for parallel subagents
- Route shell
- navigation/search
- legacy-link map
- responsive/accessibility

## Required outputs
- Multi-page site
- route manifest
- legacy redirect map
- navigation tests

## Acceptance criteria
- Every required page has unique title and heading
- Direct refresh works
- Keyboard and mobile navigation work
- No authoritative content is lost

## Required tests
- Build
- route/link checker
- keyboard/copy smoke tests
- responsive and accessibility audit

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- Existing stack cannot produce real routes without a documented migration decision

## Handoff to the next prompt
Give Prompt 04 the route map, diagram components and verified architecture terms.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-04 — Architecture Documentation

Purpose: Create precise diagrams and repository/deployment views that match the implementation plan.

## Required context
- Verified architecture ledger
- route system
- repository audit

## Files or systems to inspect
- actual packages/services
- authority and trust boundaries
- credential paths
- data/event flows
- Cloudflare resources

## Architectural constraints
- No diagram may imply model signing or bypass
- t3code stays upstream
- Show current versus planned components explicitly

## Tasks
- Create context, runtime, authority, credential, intent, override, failure, repository and deployment diagrams
- Add legends and accessible text alternatives
- Cross-link decisions and contracts

## Ordered steps
1. Inventory nodes and owners
2. Define boundary legend
3. Render smallest readable diagrams
4. Validate every edge against specification
5. Add text equivalents

## Opportunities for parallel subagents
- Authority/credential diagrams
- runtime/data flows
- repository/deployment
- failure boundaries

## Required outputs
- Diagram set
- edge/owner inventory
- compatibility notes

## Acceptance criteria
- Every credential and state transition has one owner
- Diagrams remain readable on narrow screens and print
- Planned components are labeled planned

## Required tests
- Visual viewport checks
- accessibility text check
- diagram-to-contract consistency review

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- Unresolved owner/authority ambiguity changes a security boundary

## Handoff to the next prompt
Give Prompt 05 the credential diagram, action permission matrix and unresolved custody decisions.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-05 — Privy and Hyperliquid Account Foundation

Purpose: Establish authentication, wallet ownership and a secure registered trading signer before autonomous execution.

## Required context
- Authority diagrams
- claim ledger
- Privy/Hyperliquid testnet config

## Files or systems to inspect
- auth adapter
- wallet records
- signing service
- secret bindings
- registration and recovery paths

## Architectural constraints
- Privy user identity maps explicitly to the master wallet
- Model/browser never receive keys
- Sensitive account actions use the master path
- Agent actions are allowlisted and testnet-first

## Tasks
- Implement login/session verification
- Create/connect master wallet
- Fund/test balance detection
- Create/register fresh agent wallet
- Isolate storage and nonce scope
- Implement expiry, rotation, revocation, logout, deletion and compromise runbooks

## Ordered steps
1. Define wallet lifecycle states
2. Implement authenticated server boundary
3. Implement registration with idempotency
4. Apply policies/allowlists
5. Exercise recovery and revocation

## Opportunities for parallel subagents
- Auth/session
- wallet lifecycle
- policies/signing isolation
- recovery tests

## Required outputs
- Account foundation
- permission matrix
- testnet evidence
- operations runbook

## Acceptance criteria
- A user maps to the intended wallet
- Fresh agent registers and trades only allowed actions
- Revoked/expired signer fails closed
- Secrets never reach client/model

## Required tests
- Unit/contract tests
- negative authorization tests
- testnet registration/rotation/revocation
- secret bundle scan

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- Master-wallet ownership or recovery cannot be proven
- Policy configuration permits withdrawals/transfers through the agent path

## Handoff to the next prompt
Give Prompt 06 wallet/account identifiers, signer interface, nonce ownership and testnet evidence—never keys.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-06 — Market Data and Exchange Adapter

Purpose: Implement a typed Hyperliquid boundary for discovery, streams and reconciled account truth.

## Required context
- Account foundation
- claim ledger
- canonical contracts

## Files or systems to inspect
- selected SDK version
- info/exchange/WebSocket endpoints
- network config
- existing exchange code

## Architectural constraints
- Exchange shapes stay behind interfaces
- No hardcoded production asset IDs
- Streams accelerate but do not replace reconciliation
- Native and supported HIP-3 markets share one domain model

## Tasks
- Discover per-DEX metadata
- Resolve symbols/asset IDs
- Ingest market data
- Implement order/cancel/modify/close/flatten calls
- Track orders/fills/positions/funding/equity
- Reconnect and reconcile

## Ordered steps
1. Pin SDK and create transports
2. Implement metadata cache with freshness
3. Map domain/SDK types
4. Add stream dedupe and reconnect
5. Add periodic/on-demand reconciliation
6. Capture testnet fixtures

## Opportunities for parallel subagents
- Discovery/symbols
- market streams
- account streams/reconciliation
- order lifecycle

## Required outputs
- Exchange adapter
- fixtures
- reconciliation report
- testnet transaction evidence

## Acceptance criteria
- Native and HIP-3 IDs resolve from current metadata
- Order/fill/position truth converges after disconnect
- Equity includes documented fees/funding

## Required tests
- Unit mapping tests
- contract fixtures
- disconnect/missed-fill tests
- testnet order/cancel/flatten

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- SDK/vendor behavior cannot satisfy a required operation and no adapter-level workaround is verified

## Handoff to the next prompt
Give Prompt 07 typed market/account ports, freshness guarantees, error taxonomy and fixtures.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-07 — Deterministic Risk Kernel

Purpose: Implement non-bypassable ordinary-code controls over every model and human trading intent.

## Required context
- Exchange ports
- risk specification
- approved environment limits

## Files or systems to inspect
- all order entry points
- direct-control handlers
- configuration and match state

## Architectural constraints
- Pure deterministic verdict before signing
- Fail closed on stale/invalid state
- Human commands use the same boundary
- Numeric production limits require approval

## Tasks
- Enforce assets, leverage, notional, position/portfolio, price/slippage, cadence, duplicates, deadlines, reduce-only and match-state rules
- Add emergency pause and Exit All planning
- Require post-action reconciliation

## Ordered steps
1. Define versioned policy input/output
2. Implement pure rule evaluation
3. Wire one execution boundary
4. Implement idempotency and audit reasons
5. Add exhaustive tests

## Opportunities for parallel subagents
- Exposure rules
- price/cadence rules
- match/deadline rules
- property/fuzz tests

## Required outputs
- Risk kernel
- policy schema
- verdict catalogue
- test evidence

## Acceptance criteria
- No signing call is reachable without an accepted verdict
- Every rejection has a stable reason
- Exit All only reduces risk
- Rules identify enforcement location and tests

## Required tests
- Table-driven unit tests
- boundary/property tests
- duplicate/race tests
- human/model parity tests

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- No approved test limits
- Any bypass path remains reachable

## Handoff to the next prompt
Give Prompt 08 the versioned intent/verdict interface, allowed tools, stable error codes and proof of no bypass.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-08 — Agent Tool Integration

Purpose: Expose narrow typed trading tools through t3code while preserving deterministic authority.

## Required context
- Pinned t3code revision
- risk kernel
- exchange adapter
- compatibility ledger

## Files or systems to inspect
- provider/tool/MCP extension seams
- context construction
- streaming events
- auth adapter

## Architectural constraints
- Do not fork core behavior unnecessarily
- No raw secrets or unrestricted RPC
- Tool calls always traverse risk and execution
- Claude-first remains behind provider abstraction

## Tasks
- Expose get_market/get_portfolio/place/list/cancel/close/flatten
- Define typed model inputs/outputs
- Build bounded context
- Handle timeout/invalid output/duplicate calls
- Emit display-safe rationale summaries

## Ordered steps
1. Choose proven upstream seam
2. Register narrow schemas
3. Connect risk/execution ports
4. Implement timeout/validation/idempotency
5. Record compatibility impact

## Opportunities for parallel subagents
- Read-only tools
- write tools
- context/output schemas
- timeout/invalid-output tests

## Required outputs
- Tool integration
- compatibility entry
- model event stream
- tests

## Acceptance criteria
- Model cannot access signer/secret
- Malformed or repeated calls fail safely
- Every write produces intent, verdict, request and result correlation

## Required tests
- Schema/contract tests
- adversarial prompt/tool tests
- timeout and duplicate tests
- upstream smoke test

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- Required tool seam needs invasive upstream change without approval
- Credential appears in model/tool context

## Handoff to the next prompt
Give Prompt 09 runtime startup/stop API, event schema, direct-control path and recovery semantics.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-09 — Self Mode

Purpose: Implement persistent no-wager portfolio management with steering and safe recovery.

## Required context
- Agent tools
- wallet/account foundation
- exchange state
- risk kernel

## Files or systems to inspect
- session UI/state
- agent loop
- direct controls
- reconnect restoration

## Architectural constraints
- No wager or settlement
- Portfolio persists independently of UI connection
- Pause stops new model risk but preserves deterministic controls
- Exit All remains available

## Tasks
- Entry/funding readiness
- Start continuous loop
- Construct cadence/context
- Handle steering/direct commands
- Pause/stop/flatten
- Restore after disconnect
- Show portfolio/events/errors

## Ordered steps
1. Define lifecycle
2. Implement server-owned session
3. Wire event stream and controls
4. Add reconnect snapshot
5. Verify termination/recovery

## Opportunities for parallel subagents
- Lifecycle/backend
- cockpit UI
- steering/direct controls
- recovery tests

## Required outputs
- Self mode
- session evidence
- recovery runbook
- UI state catalogue

## Acceptance criteria
- User can start, steer, pause, reconnect and stop safely
- No UI disconnect loses portfolio truth
- No Self path creates wager records

## Required tests
- Lifecycle integration
- disconnect/restart
- stale-data/timeout
- testnet bounded trade and verified flatten

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- Flatten/reconciliation cannot verify a safe terminal state

## Handoff to the next prompt
Give Prompt 10 proven shared session/trading controls, event schema and recovery behavior.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-10 — VS Match State Machine

Purpose: Implement one authoritative idempotent three-minute match lifecycle.

## Required context
- Self trading controls
- MatchState/MatchEvent contracts
- settlement baseline
- Cloudflare topology

## Files or systems to inspect
- challenge/matchmaking APIs
- Durable Object design
- clock/deadline logic
- participant readiness

## Architectural constraints
- One match ID maps to one authority
- Persist transitions before effects
- Deadline derives from stored timestamps, not client clocks or alarm firing time
- Duplicate messages are safe

## Tasks
- Challenge/House/friend matching
- Acceptance and funding verification
- readiness/start
- live trading and authoritative clock
- lock/snapshot/flatten/settle/replay terminals
- disconnect/outage/abandon/partial-flatten paths

## Ordered steps
1. Define transition table and guards
2. Implement Match DO storage/API/WebSocket
3. Add idempotent effects
4. Add timeout/alarm reconciliation
5. Exercise every terminal path

## Opportunities for parallel subagents
- State machine
- matchmaking/readiness
- WebSocket/UI
- failure/transition tests

## Required outputs
- Match authority
- transition evidence
- clock proof
- failure-state catalogue

## Acceptance criteria
- Illegal transitions fail
- Both clients see one clock/state
- Restart and duplicate delivery do not fork state
- No new risk after lock

## Required tests
- Model/state tests
- concurrency/duplicate tests
- DO restart/alarm delay
- two-client integration

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- Wager commitment cannot be verified
- State authority is split across inconsistent stores

## Handoff to the next prompt
Give Prompt 11 immutable match inputs, snapshot request, funding commitments, transition log and failure states.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-11 — Settlement and Wager Accounting

Purpose: Implement the approved custody/accounting baseline with exact, auditable and idempotent outcomes.

## Required context
- Accepted custody decision
- Match state machine
- equity contracts
- legal/operational approval

## Files or systems to inspect
- fund custody records
- commitments
- snapshot inputs
- administrative APIs
- refund/dispute paths

## Architectural constraints
- Do not improvise another custody architecture
- Settlement only from authorized match state
- Frozen score is independent of sequential flatten fills
- Real money remains blocked without specialist approval

## Tasks
- Define deposits/commitments
- Implement equity formula/reference pricing/fees/funding/ties/rounding
- Authorize settlement
- Implement idempotent payout/refund/retry
- Record evidence and admin limits

## Ordered steps
1. Freeze accounting specification
2. Implement immutable inputs and decision function
3. Persist decision before payout effect
4. Reconcile payout
5. Publish audit record and replay evidence

## Opportunities for parallel subagents
- Accounting formula
- custody ledger
- payout/refund effects
- dispute/admin controls

## Required outputs
- Settlement service
- accounting ledger
- evidence records
- runbook

## Acceptance criteria
- Same inputs always yield same decision
- Repeated settlement cannot double-pay
- Tie/refund/partial-flatten/outage behavior is explicit
- Administrative action is authenticated and logged

## Required tests
- Golden formula cases
- precision/property tests
- retry/idempotency
- testnet/simulated ledger reconciliation

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- Custody/legal approval absent for real value
- Snapshot evidence is incomplete or contradictory

## Handoff to the next prompt
Give Prompt 12 immutable decisions, event IDs, evidence locations and redaction policy.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-12 — Replay and Agent-Mind Interface

Purpose: Build an append-only, privacy-safe explanation and replay timeline.

## Required context
- Canonical events
- agent display summaries
- match/settlement records

## Files or systems to inspect
- event producers
- R2/D1 storage
- UI timeline
- redaction rules

## Architectural constraints
- Never expose private chain-of-thought
- Show intended-for-display rationale only
- Replay is derived evidence, not authority
- Events are versioned and deduplicated

## Tasks
- Persist intents, verdicts, execution results, fills, equity and match events
- Create manifests/checksums
- Implement scrubber and filters
- Add corruption detection and rebuild

## Ordered steps
1. Define replay envelope/order
2. Wire append producers
3. Store index/artifacts
4. Render accessible timeline
5. Verify rebuild and redaction

## Opportunities for parallel subagents
- Event persistence
- artifact integrity
- timeline UI
- privacy/redaction tests

## Required outputs
- Replay pipeline
- agent-mind UI
- integrity report
- rebuild runbook

## Acceptance criteria
- Timeline correlates every action end-to-end
- No hidden reasoning/secrets appear
- Corrupt/missing artifacts are detected and labeled

## Required tests
- Ordering/deduplication
- redaction/secret scan
- checksum corruption
- viewport/keyboard UI

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- Display summaries cannot be separated from private reasoning or secrets

## Handoff to the next prompt
Give Prompt 13 event taxonomy, correlation IDs, storage retention and integrity failure modes.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-13 — Failure Recovery and Observability

Purpose: Make faults detectable, contained, recoverable and operationally visible.

## Required context
- Failure catalogue
- runtime/match/replay services
- SLO decisions

## Files or systems to inspect
- logs/metrics/traces
- queue/workflow configuration
- alarms/jobs
- operator surfaces

## Architectural constraints
- No credential or sensitive payload in telemetry
- Every async effect is correlated/idempotent
- Financial/match recovery verifies exchange and authoritative state

## Tasks
- Structured logs and IDs
- metrics/alerts
- reconciliation jobs
- retry/DLQ handling
- dashboards
- runbooks for every required failure

## Ordered steps
1. Define telemetry schema
2. Instrument boundaries
3. Configure reconciliation and DLQ
4. Create alerts/dashboards
5. Run fault drills

## Opportunities for parallel subagents
- Instrumentation
- reconciliation
- queues/workflows/DLQ
- dashboards/runbooks

## Required outputs
- Observability stack
- fault-drill evidence
- recovery runbooks
- SLO dashboard

## Acceptance criteria
- Every catalogue failure has detection, containment, recovery, user state and telemetry
- Critical alerts identify match/user/correlation without secrets

## Required tests
- Injected outages
- restart/retry/DLQ
- missed-fill reconciliation
- alert routing

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- A critical failure remains silent or unrecoverable

## Handoff to the next prompt
Give Prompt 14 the boundary map, telemetry evidence and unresolved security risks.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-14 — Security Hardening

Purpose: Prove authorization, secret, replay and cross-user isolation before end-to-end sign-off.

## Required context
- Threat model
- authority/credential diagrams
- implemented services
- operations evidence

## Files or systems to inspect
- all APIs and bindings
- wallet actions
- nonce/idempotency stores
- admin paths
- client bundles
- logs and artifacts

## Architectural constraints
- Least privilege
- Default deny
- No secret/model/browser crossing
- Fix only in-scope findings; document residual risk

## Tasks
- Review authn/authz
- Validate inputs and state guards
- Audit signing/action allowlist/nonces
- Rate-limit and abuse-protect
- Test cross-user isolation/admin controls
- Scan secrets/dependencies/artifacts

## Ordered steps
1. Update threat model
2. Map every endpoint to principal/resource/action
3. Run automated/manual negative tests
4. Remediate findings
5. Get independent review for critical paths

## Opportunities for parallel subagents
- API authorization
- wallet/signing
- abuse/rate limits
- artifact/dependency review

## Required outputs
- Security report
- fixed findings
- residual-risk register
- incident response update

## Acceptance criteria
- No critical/high unresolved exploit path
- Cross-user access fails
- Agent signer cannot perform forbidden actions
- Bundles/logs contain no secrets

## Required tests
- Authorization matrix
- fuzz/validation
- replay/nonce/race
- secret/dependency scan

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- Critical/high issue unresolved
- Specialist custody/security approval missing

## Handoff to the next prompt
Give Prompt 15 versioned build, known residual risks, test accounts and exact acceptance matrix.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-15 — End-to-End Verification

Purpose: Prove the complete intended test-environment path with durable evidence, not UI appearance.

## Required context
- Acceptance matrix
- release candidate
- test accounts/environment
- all prior evidence

## Files or systems to inspect
- deployed preview/test environment
- databases/storage
- logs/metrics
- exchange transactions
- UI routes

## Architectural constraints
- No production funds
- Do not waive failed criteria
- Evidence must be reproducible and redacted
- Completion requires verified terminal state

## Tasks
- Run login/fund/register
- Trade native and supported HIP-3
- Exercise Self lifecycle
- Run two-player VS clock/lock/snapshot/flatten/settlement/replay
- Inject failures
- Collect records

## Ordered steps
1. Freeze candidate and environment
2. Execute happy paths
3. Execute recovery paths
4. Reconcile exchange/database/artifacts
5. Publish pass/fail matrix

## Opportunities for parallel subagents
- Route/accessibility checks
- Self journey
- VS journey
- fault and evidence validation

## Required outputs
- E2E report
- screenshots/API/log/transaction/database evidence
- defect list
- go/no-go decision

## Acceptance criteria
- Every requirement has pass evidence or explicit failure
- Orders/fills/positions/equity/settlement reconcile
- No critical accessibility/security failure

## Required tests
- All automated suites
- direct-route/browser refresh
- mobile/keyboard/copy/filter
- full testnet transaction and failure paths

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- Any critical criterion fails
- Final exchange/account state is not verified

## Handoff to the next prompt
Give Prompt 16 immutable candidate hash, pass matrix, deployment config, rollback artifact and approvals.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.

# PROMPT-16 — Production Deployment

Purpose: Release the verified candidate through Cloudflare and prove production behavior with rollback ready.

## Required context
- Prompt 15 pass report
- approved artifact
- Cloudflare project/environments
- rollback target

## Files or systems to inspect
- build/deploy scripts
- Wrangler auth/config
- headers/redirects
- production bindings/secrets
- deployment history

## Architectural constraints
- Deploy only the allowlisted build artifact
- Never expose source/secrets
- Do not deploy a different commit/artifact than verified
- Rollback immediately on critical smoke failure

## Tasks
- Run all checks
- Record manifest/hash
- Deploy preview and verify
- Deploy production
- Verify URL/routes/headers/interactions/telemetry
- Document deployment and rollback

## Ordered steps
1. Authenticate and freeze artifact
2. Execute preflight suite
3. Deploy/verify preview
4. Promote/deploy same artifact
5. Run production smoke and evidence capture
6. Record or roll back

## Opportunities for parallel subagents
- Artifact/security verification
- route/UI smoke
- headers/external-source validation
- telemetry/database verification

## Required outputs
- Deployment record
- production verification report
- artifact manifest
- rollback instructions

## Acceptance criteria
- Production URL serves the verified artifact
- Every required route has unique correct content
- No source/secrets exposed
- Rollback target and command/path are tested/documented

## Required tests
- Build/type/lint/unit/integration/E2E
- route/link/source
- accessibility
- secret scan
- production smoke

## Mandatory documentation updates
- Progress tracker
- decision log
- implementation evidence
- affected specification pages
- handoff summary

## Conditions that block progression
- Authentication missing
- preflight fails
- artifact differs from Prompt 15
- production smoke fails

## Handoff to the next prompt
Publish deployment ID/time, version URL, artifact hash, production checks, rollback target and all deferred work.

Do not mark any task complete without durable evidence such as passing tests, relevant source files, screenshots, deployment output, API responses, logged state transitions, recorded test transactions or verified database records. End by updating the progress tracker, decision log, implementation evidence, affected specification pages and handoff summary.