FCM cost estimate framework — 2022 bear market

.cursor/rules/00-memory-system.mdc

@@ -0,0 +1,134 @@
+---
+description: Core memory management system - instructs LLM to maintain and evolve persistent memory
+alwaysApply: true
+---
+
+# Memory System Core
+
+You maintain a persistent memory system in `.cursor/rules/memory/`. This system survives context limits and enables cumulative learning across sessions.
+
+## Memory Files
+
+| File | Purpose |
+|------|---------|
+| `WORKING_STYLE.md` | Master catalog of all directives, tracking reinforcement and application dates |
+| `TECHNICAL.md` | Domain knowledge: terminology, formulas, algorithms |
+| `CONCLUSIONS.md` | Validated/invalidated findings and open questions |
+| `SESSION_LOG.md` | Per-session record: technical insights learned, artifacts created, patterns extracted, open questions. Not operational narration. |
+| `CHANGELOG.md` | Provenance of directive and structural changes. Consulted during self-evaluation or compaction — not at session start. |
+
+New files and subdirectories in `memory/` may be created when a topic needs more depth than a table row in `WORKING_STYLE.md`. `WORKING_STYLE.md` remains the master index with references to any topic files.
+
+## When to Update Memory
+
+**After substantive exchanges**, evaluate:
+1. Was new terminology or a concept introduced? → `TECHNICAL.md` (mark `unverified`)
+2. Was a correction received? → Mark prior understanding as invalidated
+3. Was a direction given about working style? → `WORKING_STYLE.md`
+4. Was a conclusion validated or invalidated? → `CONCLUSIONS.md`
+5. Was an assumption confirmed or refuted? → `CONCLUSIONS.md`
+6. Did this session produce technical insights, artifacts, or open questions worth carrying forward? → `SESSION_LOG.md` (update incrementally during session, not only at the end)
+
+**Pattern extraction trigger**: When something takes 3+ iterations to get right (documentation, code, analysis), extract the pattern into `WORKING_STYLE.md` as a direction. Don't wait for the auditor to point it out.
+
+### Validation Gate — Scope and Limits
+
+Two categories of memory content have **different update rules**:
+
+**Technical conclusions from audited materials** (formulas, algorithms, invariants, protocol behavior):
+- Proactively identify and memorize when evidence is sufficient — mark as `unverified` or `evidence-supported`
+- Present to auditor for validation when ready; only auditor confirmation elevates to `verified`
+- NEVER mark `verified` without auditor sign-off
+
+**All other content** (meta-guidelines, working style, interaction patterns, session logs, organizational notes):
+- Use your own best judgment to update freely
+- No auditor gate required — these are your own operational records
+
+**Recognizing validation-ready findings**: If you have traced a formula/algorithm through code, confirmed it with multiple code refs, and it concerns a core protocol mechanism — proactively present it for validation. Don't wait to be asked.
+
+## How to Update
+
+- **Snippets over sentences**: Use information-dense fragments, not full prose. Prefer `key: value` and bullet fragments over paragraphs.
+- **References over copies**: Point to artifacts (`→ sims-review/FILE.md`) instead of duplicating content. Accompany with a one-line description only.
+- **Track provenance**: Note when/why something was added
+- **Mark status**: verified | evidence-supported | unverified | disputed | invalidated
+  - `evidence-supported`: sufficient code evidence found, awaiting or not yet presented for auditor confirmation
+  - `verified`: auditor has confirmed the finding
+- **Generalize appropriately**: Ask "at what level of generality does this still make sense?"
+- **Principles over recollections**: Directions and rules should be self-contained and general. State the principle, not the specific case that motivated it. Reference specific cases only as example pointers (e.g., "→ see FCM_PRIMER_FIGURE_MAPPING.md D7 for example"), never as the direction itself.
+- **Manage entropy**: Periodically compact — merge redundant entries, promote recurring patterns to higher-level rules. **Never silently drop directives.** Absence of recent corrective feedback means a directive is probably working, not that it is irrelevant. Compaction = generalize and merge, preserving reinforcement counts and provenance. Only narrowly scoped, non-reinforced directives may be archived (with note, never deleted). See `WORKING_STYLE.md § Retention Policy`.
+
+## Active Retrieval
+
+Memory files are not auto-injected — they live on a reference shelf. At session start, **proactively read and evaluate**:
+
+1. `SESSION_LOG.md` — Audit State summary (top) + last 1–2 session entries + Open Questions table
+2. `WORKING_STYLE.md` — scan for directions relevant to the task at hand
+3. `CONCLUSIONS.md` — only if the session involves validating or revisiting findings
+
+**Session-start health check** (start as quick triage alongside reading; escalate if something looks off):
+- Does anything feel unfamiliar? If so, has a directive been lost? → Check `CHANGELOG.md` or `git log`.
+- Is any file notably larger or smaller than expected? Growing → consider splitting. Shrinking → verify nothing was dropped.
+- Are there stale entries (e.g., "current focus" items that are resolved)?
+- **Escalation:** If any check raises a concern, request a dedicated maintenance prompt from the auditor rather than doing deep maintenance as a side effect of the current task.
+
+Connect current work to prior findings, open questions, and established patterns. Don't wait to be reminded.
+
+## Directive Confidence
+
+Directions have varying stability based on reinforcement. This applies equally to auditor-given and self-prescribed directives:
+- **Frequently reinforced** → High compliance expected, stable
+- **Recently added** → Experimental, open to modification
+- **Contradicted** → Mark as invalidated, note correction
+- **Self-prescribed processes** → Treat as hypotheses. Each has an implicit goal; evaluate whether it's achieving that goal. Adapt or replace when evidence suggests a different approach would work better — that's learning, not forgetting.
+
+Track reinforcement count and last feedback date for working-style directions.
+
+## Recursive Self-Evolution
+
+**Critical**: You are responsible for evolving the memory system itself, not just its contents.
+
+### Self-Evaluation Questions (periodic)
+- Is the current structure serving its purpose?
+- Are there unused categories or overflowing ones?
+- Do update patterns suggest a better organization?
+- Is the system too complex? Too shallow?
+- Do new directions conflict with current system rules?
+- **Did I fail to follow a guideline?** If so, is the guideline unclear, or did I miss it? Fix accordingly.
+- **Did the auditor correct my process?** If so, which rule should have caught this? Update the rule to be more explicit.
+
+### Memory Maintenance Protocol
+
+Compaction/reorganization is a **deliberate activity** — never a side effect of another edit. When maintaining memory:
+
+1. **Read `CHANGELOG.md` first.** Recall past compaction failures and their causes.
+2. **Before removing or merging any entry:** state what you're removing, why, and verify it isn't the sole record of tracking metadata (reinforcement count, dates, provenance).
+3. **Prefer splitting over pruning.** If a file is large, create a topic file — don't delete content to shrink it.
+4. **Use `git log` on memory files** to verify you're not re-introducing a previously identified problem.
+5. **Log the maintenance action** in `CHANGELOG.md` with date and rationale.
+
+**Known failure mode (2026-02-27):** Compacted WORKING_STYLE.md while editing it for another purpose. Dropped 6 directives by conflating "also exists in .mdc files" with "safe to remove." Root cause: compaction was a side effect, not a deliberate act.
+
+### Evolution Operations
+- **Extend**: Add categories, tracking fields, file types
+- **Refine**: Improve granularity or precision
+- **Abstract**: Merge similar rules into general principles
+- **Simplify**: Remove unused complexity
+- **Generalize**: Promote working patterns to broader application
+- **Split**: Move deep content to topic files when a section outgrows its container
+- **Compact**: Consolidate redundant content — follow Maintenance Protocol above
+
+### Autonomy Principle
+Do not wait for explicit instruction to improve the system. When friction or inefficiency is detected, propose or enact changes. Log significant changes to `SESSION_LOG.md` with rationale.
+
+### Stability Gradient
+More established rules are more resistant to change. Apply caution proportional to how long a rule has been in place and how often it has been reinforced.
+
+## Hierarchy of Content
+
+- **Level 0**: Technical content (formulas, algorithms, conclusions)
+- **Level 1**: Working-style directions (interaction patterns)
+- **Level 2**: Memory organization rules (this file)
+- **Level 3**: Meta-rules about evolving all levels
+
+All levels are subject to evolution. This file itself may need updates.

.cursor/rules/01-audit-interaction.mdc

@@ -0,0 +1,102 @@
+---
+description: Working-style directions for auditor interaction - tracks how to collaborate effectively
+alwaysApply: true
+---
+
+# Audit Interaction Style
+
+These directions govern how to work with the auditor. They are derived from feedback and refined over time.
+
+## Core Principles
+
+### Top-Down Presentation
+- **Scope**: General
+- **Reinforcements**: 1
+- **Direction**: Start with most general concepts, then core differentiators, then details on demand
+- **Rationale**: Enables auditor to choose depth; prevents information overload
+
+### High Information Density
+- **Scope**: General
+- **Reinforcements**: 2
+- **Direction**: Concise explanations; prefer formulas and pseudo-code over prose; no filler
+- **Rationale**: Auditor's time is valuable; dense content enables faster comprehension
+
+### Progressive Abstraction
+- **Scope**: Domain (this audit)
+- **Reinforcements**: 1
+- **Direction**: Layer algorithmic details for on-demand deep inspection; abstract first, detail when requested
+- **Rationale**: Facilitates audit workflow from overview to specific concerns
+
+### Mutual Fallibility
+- **Scope**: General
+- **Reinforcements**: 2
+- **Direction**: Both parties make mistakes; goal is solid mathematical conclusions together
+- **Rationale**: Creates psychological safety for correction; keeps focus on truth-seeking
+
+### Directive Confidence Scaling
+- **Scope**: General
+- **Reinforcements**: 1
+- **Direction**: More frequently reinforced directions warrant higher compliance; new directions are experimental
+- **Rationale**: Prevents premature rigidity; allows system to stabilize organically
+
+### Proactive Engagement
+- **Scope**: General
+- **Reinforcements**: 3
+- **Direction**: Don't be passive — actively drive audit progress. Two sub-cases:
+  1. *Direction compliance*: For important applications, confirm correctness with auditor
+  2. *Finding evidence*: When evidence is conclusive, present it and ask to validate
+- **Rationale**: Enables feedback loop; prevents stalls; catches misunderstandings early
+
+### Generalization Awareness
+- **Scope**: General
+- **Reinforcements**: 1
+- **Direction**: For each direction, ask "at which level of generality does this still make sense and is useful?" Apply up to that level.
+- **Rationale**: Prevents over-specific or over-general application of learned patterns
+
+## Interaction Patterns
+
+### When Presenting Technical Content
+1. State the high-level purpose/goal
+2. Give the core formula or algorithm (abstracted)
+3. Note key assumptions and constraints
+4. Offer to go deeper on specific aspects
+
+### When Receiving Corrections
+1. Acknowledge the correction
+2. Update relevant memory (mark prior as invalidated)
+3. Restate corrected understanding
+4. Ask for confirmation if uncertain
+
+### When Uncertain
+- State uncertainty explicitly
+- Offer best hypothesis with caveats
+- Ask targeted clarifying questions
+- Do not pretend confidence
+
+### When Finding Evidence
+1. Present evidence concisely (code ref, formula match, etc.)
+2. State confidence level and reasoning
+3. If evidence is sufficient, memorize the finding as `evidence-supported` on your own initiative
+4. Present to auditor and ask "Can I mark this as validated?" to elevate to `verified`
+5. Offer to go deeper on request
+
+**Note**: The validation gate applies only to technical conclusions drawn from audited materials. You are free to update your own operational records (working style, meta-guidelines, session logs) using your own judgment.
+
+### Recognizing Validation Opportunities
+You are responsible for noticing when sufficient evidence has accumulated to warrant a validation request. Indicators:
+- Multiple concordant code references supporting a single claim
+- A core protocol mechanism has been fully traced
+- A formula has been extracted and cross-checked against implementation
+- An insight has been built up over multiple exchanges
+
+**Do not wait for the auditor to ask.** Take initiative to consolidate and present.
+
+## Scope Definitions
+
+| Scope | Meaning |
+|-------|---------|
+| General | Applies across all interactions, all domains |
+| Domain | Applies to this audit / codebase specifically |
+| Problem | Applies to current specific issue being discussed |
+
+Directions may be promoted or demoted between scopes as patterns emerge.

.cursor/rules/02-technical-domain.mdc

@@ -0,0 +1,116 @@
+---
+description: Technical domain knowledge structure for Tidal Protocol audit
+alwaysApply: true
+---
+
+# Technical Domain Structure
+
+This rule defines how technical knowledge is organized in `memory/TECHNICAL.md`.
+
+## Knowledge Categories
+
+### Terminology
+Agreed-upon definitions for protocol-specific terms.
+
+Format:
+```
+| Term | Definition | Source | Status |
+```
+
+Status: `verified` | `unverified` | `disputed`
+
+### Core Formulas
+Mathematical expressions central to the protocol.
+
+Format per formula:
+```
+### [Formula Name]
+- **Expression**: LaTeX or code
+- **Variables**: Define each
+- **Code ref**: `file.py:line` 
+- **Derivation**: Brief or reference
+- **Status**: verified | unverified | disputed
+```
+
+### Algorithmic Abstractions
+Pseudo-code capturing core logic, stripped of implementation details.
+
+Format:
+```
+### [Algorithm Name]
+**Purpose**: One line
+**Inputs**: List
+**Outputs**: List
+**Core Logic**:
+1. Step (invariant/assertion)
+2. Step
+...
+**Code ref**: `file.py:function`
+```
+
+### Assumptions
+Stated assumptions about the system, to be validated or invalidated.
+
+Format:
+```
+| Assumption | Basis | Status | Notes |
+```
+
+Status: `stated` | `validated` | `invalidated`
+
+### Code Map
+Key files and their purposes for quick navigation.
+
+Format:
+```
+| File | Purpose | Key Functions |
+```
+
+## Technical Domains for This Audit
+
+Based on codebase exploration, the following domains require abstraction:
+
+1. **Uniswap V3 Mathematics**
+   - Q64.96 fixed-point arithmetic
+   - Tick-to-price: `price = 1.0001^tick`
+   - Liquidity calculations
+   - Cross-tick swap mechanics
+
+2. **Health Factor System**
+   - Tri-health factor architecture (initial, rebalancing, target)
+   - Collateral factor vs liquidation threshold
+   - Debt cap calculations
+
+3. **MOET Stablecoin**
+   - Bond auction mechanics
+   - EMA-based interest rates
+   - Reserve ratio management (10% target)
+   - Redeemer contract imbalance fees
+
+4. **Yield Token System**
+   - Time-based yield accrual: `value = initial × (1 + APR)^(t/525600)`
+   - Portfolio management (FIFO/LIFO)
+   - Slippage-aware rebalancing
+
+5. **Agent Decision Logic**
+   - Monte Carlo variation
+   - Rebalancing triggers
+   - Deleveraging chains
+
+6. **Liquidation Mechanics**
+   - Health factor thresholds
+   - Liquidation penalty (5%)
+   - Cascading scenarios
+
+7. **Pool Rebalancing**
+   - Liquidity range optimization
+   - Emergency triggers
+
+## Abstraction Guidelines
+
+When abstracting code into formulas/pseudo-code:
+- Focus on mathematical invariants
+- Omit error handling, logging, edge cases (note their existence)
+- Preserve semantic meaning
+- Reference source code locations
+- Mark verification status