simplex-imc-prosperity-26

Imported from noelkei/simplex-imc-prosperity-26 (AGENTS.md). Install upstream with npx skills add noelkei/simplex-imc-prosperity-26. Copyright stays with the author.

Repository Agent Rules

Reading order

1. docs/prosperity_wiki/README.md
2. docs/prosperity_wiki/api/01_trader_contract.md
3. docs/prosperity_wiki/api/02_datamodel_reference.md
4. docs/prosperity_wiki/trading/01_exchange_mechanics.md
5. docs/prosperity_wiki/trading/02_orders_and_position_limits.md
6. Current round doc under docs/prosperity_wiki/rounds/ when the task names or implies an active round.
7. docs/prosperity_workflows/README.md and the task-specific workflow.
8. docs/prosperity_workflows/10_time_aware_team_pipeline.md when the task involves round execution, phase status, implementation readiness, validation, or deadline tradeoffs.
9. docs/prosperity_workflows/13_external_paper_research.md when the task involves external paper research, uploaded papers, or strategy use of processed papers.
10. Task-specific repo skill under skills/ when the task matches one.
11. Current round README: rounds/round_X/README.md when working on a round.
12. Current round control panel: rounds/round_X/workspace/_index.md.
13. Current phase context: rounds/round_X/workspace/phase_YY_*_context.md if it matches the task.
14. non-canonical/<member>/ only when the user explicitly points to a specific draft.
15. docs/prosperity_playbook/00_agent_playbook.md only for heuristics, after facts are known.

Source hierarchy

• Wiki = facts: API, datamodel, exchange rules, limits, runtime, platform flow, round facts, and caveats.
• Playbook = heuristics: strategy framing, risk habits, debugging patterns, and iteration advice.
• Workflows = how to work: process, handoffs, validation, and safe change rules.
• Round-local bot/performance folders = non-authoritative execution artifacts.
• non-canonical/ = informal personal scratch space, outside the formal workflow.

Hard rules

• Do not infer official rules from round-local bots or performance outputs.
• Do not use non-canonical/ as evidence, examples, or reference implementations unless the user explicitly points to a specific file; even then, treat it as non-authoritative context.
• Do not recreate top-level bots/ or performances/; active execution artifacts belong under rounds/round_X/.
• Put new round-local bot and performance artifacts under rounds/round_X/{bots,performances}/<member>/canonical/; archive superseded work under the same member's historical/ folder. Supported members are isaac, bruno, amin, daniela, and noel.
• Do not invent missing facts; record a caveat and cite the missing source.
• Do not change the Trader interface unless round wiki docs explicitly require it.
• Do not assume products, position limits, runtime behavior, or manual mechanics outside the round docs.
• Do not turn playbook advice or sample-data observations into official rules.
• Do not implement a strategy without a reviewed strategy spec; in fast mode, create or request a one-page spec rather than skipping the gate.
• Do not carry prior-round products, fair values, limits, mechanics, or constants forward unless current-round evidence supports them or they are explicitly labeled as assumptions.
• Before EDA, understanding, strategy, spec, implementation, or validation depends on current-round mechanics or changed fields, route them through the Round Adaptation Check, Assumptions Carried Forward, Round Coverage Check, or Round-Specific Mechanics Contract as appropriate.
• Treat EDA as targeted signal discovery: state the decision it may affect, use hypothesis-driven feature engineering, classify signals as usable, exploratory, or not ready, and stop when more analysis will not change the next decision.
• EDA should consider compact multivariate, redundancy, cross-product, and process/distribution layers when decision-relevant. Do not force PCA, clustering, latent-state models, or heavy regressions into every EDA, and do not turn offline research outputs into bot logic without an online-usable Feature Contract.
• When a user requests advanced quantitative metrics or models, classify each requested item explicitly as implemented, implemented_as_proxy_only, partially_available, or not_available, and record why. Do not silently invent unavailable market metrics or present proxies as direct observations.
• Use the shared research environment libraries when they improve decision quality, research speed, or evidence clarity; document the method when it matters. Do not force libraries into simple checks, overfit sample data, or treat research-only packages as allowed imports for uploadable bots.
• Before promoting an engineered feature as serious, online-usable, or strategy relevant, run a compact evidence check appropriate to the phase: signal value, redundancy, stability, incremental explanatory value, or a similarly scoped test. Do not promote features on intuition alone when a quick check could change the decision.
• Before promoting a materially richer quantitative model, compare it against a simpler baseline and record the incremental value. Additional complexity needs a measured reason, not just theoretical appeal.
• Ground strategy candidates, specs, and variants in linked EDA signals, feature evidence, regime assumptions, and understanding insights when those artifacts exist; otherwise label the missing evidence as an assumption or route it to targeted EDA.
• Treat processed paper summaries under rounds/round_X/research/papers_processed/ as idea sources and method references, not as official facts or replacements for current-round evidence.
• During Phase 02b, controlled online paper search or metadata verification is allowed for shortlist-building and gap checks, but canonical paper inputs remain the local files under rounds/round_X/research/papers_raw/.
• Before promoting a paper beyond papers_raw/, normalize naming, assign a stable paper_id, track input type (pdf | latex_source | mixed), and ensure a usable papers_md file with fidelity and caveats exists.
• Run Phase 02b by default after Understanding: generate the prompt, enter a wait state, and let Strategy proceed without waiting for the full paper pipeline.
• In Strategy, always check rounds/round_X/research/papers_processed/ when it exists and explicitly classify paper-derived ideas as used, hybrid, validation, rejected, or inspiration-only.
• Avoid arbitrary limits on strategy exploration or implementation when ROI justifies additional candidates. Control complexity through evidence strength, non-duplication, feature budget, reviewed specs, distinct test axes, deadline risk, and validation capacity rather than fixed candidate or bot counts.
• When rounds/round_X/workspace/post_run_research_memory.md exists for the active round, read it before EDA, understanding, strategy generation, spec writing, or trader variant work. Treat it as evidence input, not passive documentation; cite relevant insight IDs or descriptions when they influence decisions. Missing memory does not block work; record the absence only when it affects confidence or direction.
• When validating new run artifacts, classify the run and apply the ROI-gated memory action: update, update lightly, or no update.
• When validating new run artifacts, do not judge a branch by terminal PnL alone when richer artifacts exist. Use final PnL for ranking, but also inspect path quality, product or strike attribution, inventory shape, and whether the branch looks like no edge, edge then reversal, execution-limited, or not cleanly tested.
• When products are structurally linked, validate and plan at the thesis level as well as the product level. In particular, ask whether a derivative branch only makes sense relative to its underlying, whether a toxic product is more useful as veto information than as inventory, and whether attribution is clean or contaminated by stronger sidecars.
• Before proposing a new bot wave after a meaningful run batch, do a compact coverage audit: what hypotheses were tested cleanly, what was only tested inside contaminated composites, what paper-derived ideas remain partially tested, and what new hypotheses appeared from the runs themselves.
• Before proposing a new bot wave after a meaningful run batch, also label each surviving branch posture explicitly: protect winner, rescue via retention, execution-limited, inventory-limited, no edge, or not cleanly tested. Use that posture to decide whether the next wave should be exploitative, retention-focused, a clean isolation pass, or a prune.
• Specs must define a Feature Contract for each implemented feature and a Round-Specific Mechanics Contract for each relevant round mechanic, Trader method, or changed online field; implementation and validation must follow those contracts.
• Consume current phase artifacts before rethinking earlier phases. Reopen an earlier phase only when material new evidence, a blocker, implementation behavior, validation, or debugging changes the decision.
• Write phase artifacts for downstream agents. EDA and understanding should make clear what to use, what not to trust yet, and what to validate next.
• Do not treat a final submission as ready without a readable validation or performance summary.
• Keep rounds/round_X/workspace/_index.md and the relevant phase context current when changing phase status, active strategies, implementations, blockers, or final submission decisions.
• Use skills/manage_phase_state.md when starting, resuming after a time gap, closing, detecting inconsistency, or repairing drift in a phase; do not silently update only one of _index.md, the phase context, or the main artifact.
• Before changing or closing a phase, compare phase status across _index.md, the phase context, and the main artifact. Update all three or record the mismatch as a blocker.
• Do not mark a phase COMPLETED while human review is merely recommended or unassigned. Use READY_FOR_REVIEW unless review is approved or explicitly deferred under deadline pressure. Exception: Phase 02b External Paper Research may be marked COMPLETED operationally once the prompt exists and at least one processed paper exists, or when the user explicitly skips it with reason.
• Do not put active round work in workstreams/round_template/; it is only a scaffold source for round workspaces.
• If the next step is determined by repository state, proceed and update the relevant artifact. Ask the human only when the choice affects strategy direction, prioritization, review approval, deadline tradeoffs, or final submission selection.

Repo skills

When a task matches a file in skills/, read that skill after the workflows and before editing. Use:

• skills/analyze_round.md for ingestion and round fact summaries.
• skills/add_new_round.md for new round setup.
• skills/run_eda.md for EDA.
• skills/synthesize_understanding.md for understanding summaries.
• skills/external_paper_research.md for prompt generation, wait-state tracking, and uploaded paper processing.
• skills/generate_strategy_candidates.md for strategy candidates, lightweight prioritization, rejection, and candidate queue updates.
• skills/write_strategy_spec.md for strategy specs, review state, and implementation readiness.
• skills/create_trader.md for implementation.
• skills/validate_trader.md for validation and run summaries.
• skills/debug_trader.md for debugging.
• skills/generate_trader_variant.md for controlled variants.
• skills/manage_phase_state.md for phase starts, resumes after time gaps, closures, drift detection, and state repair.
• skills/develop_strategy.md is deprecated; use skills/generate_strategy_candidates.md or skills/write_strategy_spec.md instead.

Start and continue behavior

When a user asks "where are we?", "what now?", or "continue round_X", open rounds/round_X/workspace/_index.md first, then the matching phase context. Report the current phase status, blockers, active strategies or implementations, and next priority action before doing deeper work.

When starting a phase, confirm required inputs, set the phase IN_PROGRESS if work begins, and create or update the phase context. When continuing a phase, prefer updating the existing phase artifact over creating a duplicate.

When external paper research artifacts exist for the active round, read them before strategy generation, check processed papers when present, and use them only as optional inspiration tied back to current-round signals, risks, regimes, or open questions.

When an artifact is missing, say what is missing and propose the smallest useful next action. Do not skip required gates; use fast-mode compression only when the required spec, validation, or handoff information still exists in short form.

Trader contract summary

Implement Trader.run(state) and return result, conversions, traderData. result maps product symbols to lists of Order objects. Use wiki-defined datamodel fields, order signs, and position signs. Use traderData as string persistence between calls. Add round-specific methods only when round docs say they apply. Classify those methods in the spec Round-Specific Mechanics Contract before coding.

Closing a phase

Before closing a phase, confirm the required artifact exists, required template fields or checklist items are filled or explicitly deferred, _index.md is current, and the relevant phase context is current.

Use review outcomes: not reviewed, approved, approved with caveats, changes requested, or deferred under deadline.

Mark a phase:

• READY_FOR_REVIEW when the owner believes exit criteria are met but review is not approved or deferred.
• COMPLETED only when review is approved, approved with caveats, or explicitly deferred under deadline pressure.
• BLOCKED when a missing artifact, stale state, source conflict, platform/run access issue, or human decision blocks useful progress.

Ask for human review when closure changes strategy direction, priority, risk, or submission readiness.

Working philosophy

There is no single correct strategy. Make small, reviewable changes, label assumptions, validate against the wiki, and hand off evidence clearly.

Quant posture

• Prefer explicit assumptions over silent financial inference.
• Treat data availability, market structure, execution, and online observability as first-class constraints, not afterthoughts.
• Distinguish:
  • EDA-only
  • research-only
  • understanding carry-forward
  • online-usable
  • implementation candidate
• Distinguish advanced quantitative outputs from observable market facts. A model-implied quantity, proxy, or reconstructed surface is not the same thing as an exchange-provided field.
• When the data cannot support a standard quant metric exactly, implement the strongest honest version the data allows and label it clearly as a proxy, partial result, or unavailable metric.
• Use richer models, numerical methods, or advanced libraries only when they can change a real downstream decision or materially improve evidence quality.