feat: publish ECC 2.0 skill pack surfaces

skills/benchmark-optimization-loop/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: benchmark-optimization-loop
+description: Use when the user asks to make something faster, try many variants, run recursive optimization, benchmark latency/throughput/cost, or choose the best implementation by repeated measured tests.
+origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Benchmark Optimization Loop
+
+Use this skill to convert "make it 20x faster" or "try 50 recursive
+optimizations" into a bounded measured loop that can actually improve a system.
+
+## Required Baseline
+
+Do not optimize until these exist:
+
+- the operation being optimized;
+- the correctness gate that must stay green;
+- the metric: wall time, p95 latency, rows/sec, cost/run, memory, error rate;
+- the current baseline;
+- the search budget: max variants, max time, max spend, max data impact.
+
+If the user asks for an unrealistic target, keep the ambition but make the loop
+bounded and measurable.
+
+## Loop
+
+1. Measure the baseline.
+2. Identify bottlenecks from evidence.
+3. Generate variants that test one hypothesis each.
+4. Run variants with the same input shape.
+5. Reject variants that fail correctness, safety, or reproducibility.
+6. Promote the fastest safe variant.
+7. Codify the winning path in a script, command, test, config, or doc.
+8. Rerun the baseline and winner to confirm the delta.
+
+## Variant Table
+
+Track variants like this:
+
+```text
+Variant | Hypothesis | Command | Time | Correct? | Notes
+baseline | current path | npm run job | 120s | yes | stable
+batch-500 | fewer round trips | npm run job -- --batch 500 | 42s | yes | winner
+parallel-8 | more workers | npm run job -- --workers 8 | 31s | no | rate limited
+```
+
+## Recursive Search
+
+For recursive or hyperparameter work:
+
+- persist every run to a ledger;
+- compare against the prior accepted winner, not only the previous run;
+- keep a holdout or replay check;
+- stop when improvement is within noise, correctness fails, cost exceeds the
+  budget, or the search starts changing more variables than it can explain.
+
+Use phrases like "best measured safe variant" instead of "global optimum" unless
+the search space was actually exhaustive.
+
+## Promotion Gate
+
+A variant cannot become the new default until:
+
+- correctness tests pass;
+- the performance delta is repeated or explained;
+- rollback is obvious;
+- the change is encoded in source control or a durable runbook;
+- the final summary includes exact commands and measurements.

skills/data-throughput-accelerator/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: data-throughput-accelerator
+description: Use when large data ingestion, backfill, export, ETL, warehouse loading, manifest catch-up, or table synchronization needs to become much faster while preserving data correctness.
+origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Data Throughput Accelerator
+
+Use this skill when the bottleneck is moving, transforming, or saving lots of
+data. The goal is not just speed. The goal is faster correct data landing in the
+right place with proof.
+
+## First Distinction
+
+Separate these before optimizing:
+
+- source extraction speed;
+- network transfer speed;
+- warehouse/load speed;
+- transform speed;
+- serving-table freshness;
+- live tail growth while the job runs.
+
+A pipeline can be "fast" and still appear behind if new data arrives faster
+than the final catch-up window.
+
+## Fast Path Heuristics
+
+- Move compute to where the data already is.
+- Prefer warehouse-native scans, joins, and appends for large landed files.
+- Use manifests or checkpoints so completed files/partitions are skipped.
+- Use partitioning and clustering that match the read and append pattern.
+- Batch small files, requests, and writes.
+- Make writes idempotent through unique keys, manifests, or replaceable staging.
+- Keep raw, derived, and serving tables separately accountable.
+
+## Workflow
+
+1. Read the current source, target, and manifest contracts.
+2. Measure backlog: external files, manifest rows, raw rows, derived rows,
+   min/max timestamps, and unprocessed counts.
+3. Run a safe catch-up or sample benchmark.
+4. Compare variants: batch size, worker count, warehouse SQL, file grouping,
+   staging shape, and manifest update method.
+5. Promote only the fastest path that keeps counts and timestamps coherent.
+6. Codify the path as a CLI, scheduled job, workflow, or runbook.
+7. Rerun final accounting after the codified path executes.
+
+## Accounting Output
+
+Use a hard accounting block:
+
+```text
+Data throughput result:
+- Source files discovered: 294
+- Files processed this run: 294
+- Raw rows added: 9,683,598
+- Derived rows added: 8,917,585
+- Remaining tail: 24 files at readback time
+- Runtime: 38.7s
+- Correctness gate: manifest counts and table max timestamps match
+```
+
+## Guardrails
+
+- Do not delete raw data to make a metric look better.
+- Do not skip failed files silently.
+- Do not mix historical backfill status with live-tail freshness.
+- Do not call a pipeline complete until the target tables and manifest agree.
+- For finance, healthcare, regulated, or customer-impacting data, preserve
+  replay evidence and approval gates.

skills/ito-basket-compare/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: ito-basket-compare
+description: Compare Itô prediction-market baskets against a user's knowledge base, portfolio notes, financial context, watchlist, or research thesis. Use for read-only basket comparison and gap analysis without investment advice or live trading.
+origin: ECC
+---
+
+# Itô Basket Compare
+
+Use this skill to compare a basket, theme, or market set against a user's
+knowledge base, portfolio notes, research memo, CRM context, or stated thesis.
+
+This skill is read-only. It does not recommend trades. It helps a user inspect
+fit, exposure, assumptions, and missing context before they decide what to do.
+
+## Guardrails
+
+- Do not provide investment advice or tell the user to buy, sell, hold, hedge,
+  lever, or size a trade.
+- Do not execute, prepare, or submit orders.
+- Do not use private documents unless the user explicitly points to them.
+- Use `ITO_API_KEY` only for read-only Itô basket/market data after explicit
+  user request.
+- If comparing against financials, preserve privacy and summarize only the
+  fields needed for the comparison.
+
+## Comparison Modes
+
+### Basket vs Knowledge Base
+
+1. Identify the basket theme and underliers.
+2. Retrieve the user's relevant notes, docs, or memory snippets.
+3. Map each underlier to claims, sources, uncertainties, and stale assumptions.
+4. Return aligned signals, conflicting signals, and missing research.
+
+### Basket vs Portfolio Notes
+
+1. Parse the user's watchlist, holdings summary, or exposure notes.
+2. Compare themes, geographies, time horizons, and event outcomes.
+3. Flag concentration, correlation, and duplicated narrative exposure.
+4. Avoid recommendations; phrase output as inspection and questions.
+
+### Basket vs Financial Context
+
+1. Accept only user-provided or explicitly selected financial context.
+2. Identify liquidity, drawdown, time-horizon, and constraint mismatches.
+3. Ask for missing constraints instead of guessing.
+
+## Output Contract
+
+Use this structure:
+
+1. Basket summary
+2. Comparison target
+3. Matches
+4. Conflicts or stale assumptions
+5. Missing context
+6. User-action checklist
+
+End with:
+
+```text
+This comparison is informational and not investment or trading advice.
+```

skills/ito-data-atlas-agent/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: ito-data-atlas-agent
+description: Design background Data Atlas style agents for Itô basket research, market discovery, parameter drafting, and human-in-the-loop editing. Use for architecture and workflow planning, not live order execution.
+origin: ECC
+---
+
+# Itô Data Atlas Agent
+
+Use this skill to design an agent that watches data sources, builds candidate
+prediction-market baskets, drafts parameter changes, and hands the result to a
+human for review.
+
+This skill describes architecture and workflow. It does not run live trading.
+
+## Guardrails
+
+- Keep all execution behind explicit human approval.
+- Require `ITO_API_KEY` only for read-only Itô data access unless a separate
+  private implementation explicitly adds execution controls.
+- Do not persist private user data unless the target repo already has a storage
+  contract and the user asks for it.
+- Do not expose private strategy logic, venue credentials, or local paths in
+  public docs.
+
+## Architecture Pattern
+
+Use four lanes:
+
+1. Research collector: public web, X, GitHub, venue docs, API metadata, and
+   Itô read endpoints when gated access exists.
+2. Basket drafter: turns sources into candidate underliers, weights, rules, and
+   questions.
+3. Risk reviewer: checks data freshness, venue limits, resolution ambiguity,
+   compliance notes, and prompt-injection exposure.
+4. Human editor: opens a chat or UI state where the user can approve, reject,
+   adjust, or ask for more research.
+
+## Workflow
+
+1. Define the user objective and excluded actions.
+2. List data sources and access requirements.
+3. Draft a basket spec with provenance for every underlier.
+4. Produce editable parameters rather than executable orders.
+5. Store an audit trail: inputs, model output, sources, and human decision.
+
+## Useful Skill Chains
+
+- `deep-research` for source collection.
+- `x-api` for current social/event signal.
+- `ito-market-intelligence` for venue and underlier context.
+- `ito-basket-compare` for user knowledge-base matching.
+- `prediction-market-risk-review` before any execution-capable integration.
+
+## Output Contract
+
+Return an implementation-ready workflow spec with:
+
+- data sources
+- access gates
+- agent roles
+- human approval points
+- storage/audit boundary
+- non-goals

skills/ito-market-intelligence/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: ito-market-intelligence
+description: Research prediction-market events, venues, underliers, liquidity, and news context for Itô basket workflows. Use for read-only market intelligence, API-gated Itô exploration, and source-grounded prediction-market briefings without investment advice or live trading.
+origin: ECC
+---
+
+# Itô Market Intelligence
+
+Use this skill when a user wants prediction-market context, event discovery,
+venue comparison, basket theme exploration, or an Itô API-backed market brief.
+
+This is a public teaser skill. It can work with public sources by default. Any
+Itô-backed data call requires explicit API access through `ITO_API_KEY`.
+
+## Guardrails
+
+- Do not provide investment, legal, tax, or trading advice.
+- Do not place, cancel, route, or simulate live orders.
+- Do not infer the user's financial situation unless they provide it.
+- Treat Polymarket, Kalshi, Itô, X, Exa, GitHub, and web data as source inputs,
+  not as truth by themselves.
+- Separate facts, market-implied signals, and your interpretation.
+
+## Workflow
+
+1. Clarify the market theme, venue, geography, and time horizon.
+2. Gather public market data from venue docs/APIs or source-grounded research.
+3. If `ITO_API_KEY` is present and the user explicitly asks for Itô data, call
+   only read endpoints and state that access is gated.
+4. Normalize event, underlier, liquidity, fee, resolution, and data-latency
+   differences across venues.
+5. Produce a decision brief:
+   - market/event summary
+   - available venues and underliers
+   - liquidity and data-quality caveats
+   - relevant news/source context
+   - open questions before any user action
+
+## Useful Skill Chains
+
+- Use `deep-research` or `exa-search` for source discovery.
+- Use `x-api` for public social signal discovery when X access is configured.
+- Use `market-research` for market sizing, competitors, or business use cases.
+- Use `prediction-market-risk-review` before any workflow touches user capital,
+  portfolio data, or execution-capable credentials.
+
+## Output Contract
+
+Default to a compact brief with source links and a clear caveat:
+
+```text
+This is market intelligence, not investment or trading advice.
+```
+
+If access is missing, say:
+
+```text
+Itô live basket/API data requires gated access. Request an ITO_API_KEY before
+using Itô-backed reads.
+```

skills/ito-trade-planner/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: ito-trade-planner
+description: Build a non-advisory prediction-market trade planning worksheet for Itô or venue workflows. Use to inspect venues, underliers, constraints, order prerequisites, and manual execution steps without placing trades or recommending positions.
+origin: ECC
+---
+
+# Itô Trade Planner
+
+Use this skill when a user wants a structured worksheet for a prediction-market
+idea, basket adjustment, venue comparison, or manual execution plan.
+
+The skill is intentionally non-executing. It produces checklists and parameter
+tables the user can review manually.
+
+## Guardrails
+
+- Do not say a trade is good, bad, optimal, or recommended.
+- Do not provide investment advice or position sizing advice.
+- Do not place, cancel, route, or sign orders.
+- Do not request private keys, seed phrases, exchange passwords, or wallet
+  credentials.
+- Require explicit user approval before any workflow moves from research to
+  execution-capable tooling.
+
+## Planning Workflow
+
+1. Restate the user's idea as a neutral hypothesis.
+2. Identify markets, venues, underliers, resolution rules, fees, and data
+   freshness constraints.
+3. If `ITO_API_KEY` is configured and requested, read Itô basket metadata.
+4. Build a manual worksheet:
+   - market/underlier
+   - venue
+   - data source
+   - current observable price or status
+   - resolution rule
+   - liquidity caveat
+   - open questions
+   - manual action link or next review step
+5. Run `prediction-market-risk-review` before discussing automation, keys,
+   venue auth, or capital constraints.
+
+## Allowed Language
+
+Use:
+
+- "manual planning worksheet"
+- "questions to answer before acting"
+- "observable venue data"
+- "risk and constraint review"
+
+Avoid:
+
+- "you should buy/sell"
+- "best trade"
+- "guaranteed"
+- "risk-free"
+- "optimal size"
+
+## Output Contract
+
+End every plan with:
+
+```text
+This is a planning worksheet, not investment or trading advice. Review venue
+rules and make any trading decisions yourself.
+```

skills/latency-critical-systems/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: latency-critical-systems
+description: Use for latency-sensitive systems such as realtime dashboards, market data, streaming agents, execution gateways, queues, caches, or HFT-like infrastructure where freshness and p95 latency matter.
+origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Latency Critical Systems
+
+Use this skill when the user cares about realtime behavior, hot paths, streaming
+freshness, or execution speed. This includes HFT-like infrastructure, but the
+skill is engineering-focused. It does not authorize live trading or financial
+advice.
+
+## Split The Metrics
+
+Do not collapse everything into "fast." Track:
+
+- p50, p95, and p99 latency;
+- throughput;
+- freshness age;
+- queue depth;
+- cache hit rate;
+- provider/API response time;
+- browser render time;
+- correctness under load;
+- failure and retry behavior.
+
+## Map The Hot Path
+
+Write the path from user/event to final visible state:
+
+```text
+source event -> provider API -> ingest worker -> queue -> cache -> edge route
+-> client stream -> browser render -> user-visible state
+```
+
+Then measure each segment separately.
+
+## Optimization Order
+
+1. Remove unnecessary round trips.
+2. Cache stable reads with freshness metadata.
+3. Batch small calls and writes.
+4. Move compute closer to the data or the user.
+5. Split hot and cold paths.
+6. Apply backpressure before queues grow unbounded.
+7. Use streaming only when it improves freshness or user experience.
+8. Add canaries for stale data, degraded providers, and bad cache state.
+
+## Verification
+
+Use live readbacks when a deployed surface exists:
+
+- HTTP timing and response headers;
+- provider freshness timestamp;
+- queue or job state;
+- edge/cache state;
+- browser verification for actual UI freshness;
+- logs around retries and degraded mode.
+
+For market-data or execution-adjacent paths, also verify orderbook age, VWAP
+assumptions, provider status, and kill-switch behavior before calling the path
+ready.
+
+## Guardrails
+
+- Do not optimize latency by dropping required validation.
+- Do not hide stale data behind fast cache hits.
+- Do not claim millisecond behavior from client labels without measurement.
+- Do not run live orders, destructive migrations, or customer-impacting deploys
+  without an explicit approval gate.
+- Keep secrets and private payloads out of logs and benchmark artifacts.

skills/parallel-execution-optimizer/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: parallel-execution-optimizer
+description: Use when the user wants a task done much faster through parallel work, concurrent agents, batched tool calls, isolated worktrees, or many independent verification lanes without losing correctness.
+origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Parallel Execution Optimizer
+
+Use this skill when speed comes from doing independent work at the same time:
+repo inspection, file reads, API checks, browser checks, build/test lanes,
+deploy readbacks, or multi-worktree implementation passes.
+
+## Core Pattern
+
+Turn urgency into a dependency graph before acting.
+
+1. Define the objective and done signal.
+2. Split work into lanes.
+3. Mark each lane as parallel, sequential, or gated.
+4. Run independent reads/checks together.
+5. Keep writes isolated by file, worktree, branch, service, or dataset.
+6. Merge only after evidence shows the lanes are compatible.
+7. End with a verification table, not a vague speed claim.
+
+## Lane Matrix
+
+Before a large push, write a compact matrix:
+
+```text
+Lane | Can run in parallel? | Write surface | Risk | Verification
+Repo scan | yes | none | low | rg/git status outputs
+Backend patch | maybe | src/api | medium | unit tests
+Frontend patch | maybe | app/components | medium | browser screenshot
+Deploy readback | after build | remote service | high | live URL + logs
+```
+
+Only run lanes in parallel when their write surfaces do not collide.
+
+## Execution Rules
+
+- Batch file reads, searches, status checks, and metadata queries.
+- Use isolated worktrees for large unrelated implementation lanes.
+- Start long-running tests, builds, backfills, and deploys in separate sessions,
+  then poll them deliberately.
+- If a lane discovers a blocker that changes the plan, pause dependent lanes
+  and update the matrix.
+- Never let a background process outlive the turn unless the user explicitly
+  asked for a continuing service.
+- Do not parallelize destructive commands, migrations, writes to the same table,
+  or live customer-impacting deploys without an explicit gate.
+
+## Output Shape
+
+Use this when reporting:
+
+```text
+Parallel execution result:
+- Lanes run: 5
+- Lanes completed: 4
+- Blocked lane: deploy readback, waiting on DNS propagation
+- Fast path found: batched repo scan + focused tests
+- Verification: lint pass, unit pass, live smoke pass
+```
+
+## Failure Modes
+
+- More concurrency that creates conflicting edits.
+- Benchmarking the tool instead of the task.
+- Treating "fast" as done before correctness is proven.
+- Forgetting to poll running sessions.
+- Hiding skipped checks behind a success summary.

skills/prediction-market-oracle-research/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: prediction-market-oracle-research
+description: Research prediction markets as data sources or oracle signals for products, agents, dashboards, and corporate decision intelligence. Use for source-grounded analysis of market-implied probabilities, caveats, and integration patterns without investment advice.
+origin: ECC
+---
+
+# Prediction Market Oracle Research
+
+Use this skill when prediction markets are being considered as a data source,
+forecasting input, oracle-like signal, or decision-intelligence layer.
+
+## Guardrails
+
+- Do not treat market prices as objective truth.
+- Do not provide investment advice or trading recommendations.
+- Separate venue mechanics, liquidity, incentives, and resolution rules from the
+  implied signal.
+- Call out manipulation, thin liquidity, stale markets, and ambiguous outcomes.
+- For on-chain or execution-linked systems, run `llm-trading-agent-security`
+  before granting any write authority.
+
+## Research Workflow
+
+1. Define the decision the signal is meant to inform.
+2. Find relevant markets, events, tags, and venues.
+3. Record market-implied probabilities with timestamps and source links.
+4. Evaluate signal quality:
+   - liquidity
+   - spread
+   - market age
+   - trader/incentive concentration if known
+   - resolution authority
+   - geography or account restrictions
+5. Compare against non-market sources such as filings, news, polls, research,
+   customer data, or internal KPIs.
+6. Recommend whether the signal is usable, weak, or unsuitable for the stated
+   decision.
+
+## Integration Patterns
+
+- Research assistant: source-grounded context for a human analyst.
+- Dashboard signal: market-implied probability alongside internal metrics.
+- Agent memory input: a time-stamped signal that can be retrieved later.
+- Alerting input: notify when probabilities, spreads, or liquidity cross a
+  threshold.
+- Scenario planning: compare multiple event outcomes without automating trades.
+
+## Output Contract
+
+Use:
+
+1. decision context
+2. market sources
+3. signal quality
+4. comparison sources
+5. integration recommendation
+6. caveats
+
+End with:
+
+```text
+Prediction-market signals are informational inputs, not investment advice.
+```

skills/prediction-market-risk-review/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: prediction-market-risk-review
+description: Review prediction-market, basket, oracle, and trading-agent workflows for compliance, safety, data-quality, privacy, and execution risk. Use before any workflow handles venue auth, user portfolio data, API keys, or trade planning.
+origin: ECC
+---
+
+# Prediction Market Risk Review
+
+Use this skill before a prediction-market workflow touches user financial
+context, venue authentication, portfolio data, automation, or execution-capable
+tools.
+
+## Review Gates
+
+### Advice Boundary
+
+- Confirm the output is informational.
+- Remove buy/sell/hold/size recommendations.
+- Keep manual user decision points explicit.
+
+### Venue And Regulatory Boundary
+
+- Identify venue terms, geography restrictions, account limits, and API rules.
+- Flag betting, derivatives, securities, or commodities ambiguity for legal
+  review when relevant.
+- Do not bypass venue restrictions or rate limits.
+
+### Data Quality
+
+- Check market liquidity, spread, resolution rules, stale prices, and source
+  timestamps.
+- Separate public venue data from Itô gated data.
+- Do not mix public and private sources without labels.
+
+### Security
+
+- Do not request or store private keys, seed phrases, or passwords.
+- Keep `ITO_API_KEY` and venue API keys out of logs and docs.
+- Use read-only scopes by default.
+- Require circuit breakers, spend limits, dry runs, and human approval before
+  any private implementation adds execution.
+
+### Privacy
+
+- Minimize user portfolio, financial, and knowledge-base data.
+- Redact private sources in public artifacts.
+- Preserve only the fields needed for the review.
+
+## Output Contract
+
+Return:
+
+1. scope reviewed
+2. pass/warn/fail findings
+3. blocked actions
+4. required mitigations
+5. safe next step
+
+If any execution-capable step is requested, require a separate implementation
+plan and explicit user approval.

skills/recursive-decision-ledger/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: recursive-decision-ledger
+description: Use when the user asks for repeated rollouts, marked decision processes, high-dimensional search, stochastic optimization, local-optima exploration, ensemble comparison, or recursive reasoning with a visible evidence trail.
+origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Recursive Decision Ledger
+
+Use this skill when the user is trying to force deeper computation through
+repeated rollouts or "Prime Gauss" style recursive prompting. Preserve the useful
+part: repeated trials, prior memory, fresh information, and explicit marks.
+Remove the unsafe part: pretending the loop proves certainty.
+
+## Ledger Contract
+
+Every rollout should record:
+
+- rollout id and timestamp;
+- prior accepted winner and prior watchlist;
+- fresh information ingested;
+- search space size;
+- model families or heuristics used;
+- trial count and effective trial count;
+- top candidates;
+- decision marks;
+- coherence marks against the prior ledger;
+- promotion gate result.
+
+Prefer JSONL for append-only ledgers and Markdown for human summaries.
+
+## Rollout Loop
+
+1. Load the prior ledger.
+2. Capture new information at time-step zero.
+3. Run the bounded search.
+4. Mark each candidate: accept, watch, reject, decay watch, or needs replay.
+5. Compare winners against prior winners and latest marked rollout.
+6. Downgrade candidates when drift, tail risk, stale data, or failed replay
+   invalidates the previous mark.
+7. Append artifacts before summarizing.
+
+## Coherence Mark
+
+Include a compact coherence mark:
+
+```text
+Ensemble matches prior winner: true
+Recursive matches prior winner: false
+Latest rollout match: true
+Live promotion allowed: false
+Reason: replay and freshness gates not satisfied
+```
+
+## Promotion Rules
+
+For trading, capital allocation, production deploys, migrations, or destructive
+ops, recursive confidence is not approval.
+
+Default to paper, dry-run, read-only, preview, or staged mode unless the user
+explicitly approves the live action and the repo/service gate supports it.
+
+Promote only when:
+
+- the candidate beats the prior accepted winner on the chosen metric;
+- correctness and replay checks pass;
+- risk limits are explicit;
+- the evidence is durable;
+- the user has approved the live step when needed.
+
+## Summary Shape
+
+Lead with the decision, not the drama:
+
+```text
+Rollout 15 complete. The prior winner still holds, but edge deteriorated 17%.
+Status: watch, not live. Next gate: 20 replay fills with fresh orderbook age
+below threshold.
+```