Update to OloLand DD

{
  "description": "Use when working on a deal across multiple conversation sessions, or when an analyst confirms a fact that should survive beyond the current turn — EBITDA confirmations, sponsor names, IC dates, modeling conventions, deal-specific assumptions. Explains the deal_session_memory store and the institutional pattern that drives \"OloLand captures the institution, not the session\".",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 457
    }
  ],
  "name": "deal-session-memory",
  "skill_md_contents": "---\nname: deal-session-memory\ndescription: \"Use when working on a deal across multiple conversation sessions, or\\\n  \\ when an analyst confirms a fact that should survive beyond the current turn \\u2014\\\n  \\ EBITDA confirmations, sponsor names, IC dates, modeling conventions, deal-specific\\\n  \\ assumptions. Explains the deal_session_memory store and the institutional pattern\\\n  \\ that drives \\\"OloLand captures the institution, not the session\\\".\"\n---\n\n# Deal Session Memory\n\n`deal_session_memory` is the table that turns OloLand from a stateless reasoning engine into a persistent deal record. Every fact persisted via `remember_deal_fact` survives across conversation sessions, analyst handoffs, and even LLM-provider changes.\n\n## Why it exists\n\nThe marketing claim \"OloLand captures the institution, not the session\" is load-bearing only if there is somewhere durable to capture *to*. Conversation history is per-session and stale within hours. Document ingestion is per-corpus and doesn't capture analyst judgment. Risk corrections and outcomes have dedicated tables but cover their own narrow domains.\n\n`deal_session_memory` is the catch-all for analyst-confirmed facts. It is the place where you write:\n\n- \"FY24 EBITDA is $34.2M, confirmed against the CPA-audited statements\" — `ebitda_fy24_confirmed: 34200000`.\n- \"Sponsor's lead partner is Jim from MidOcean\" — `sponsor_lead_partner: \"Jim Smith (MidOcean)\"`.\n- \"We're normalizing WC against the 3-year average, not the trailing 12, after partner discussion 2026-05-12\" — `wc_normalization_convention: \"3yr_average\"` with a note.\n- \"LOI signed 2026-05-20\" — `loi_signed_date: \"2026-05-20\"`.\n\n## Why it is not the conversation log\n\nConversations are noisy — they contain hypotheses, partial answers, dead-end branches. `deal_session_memory` is the curated subset: only facts an analyst has *confirmed*. The discipline matters; otherwise the recall surface fills with noise and stops being useful.\n\n## Storage shape\n\n| Field | Constraint |\n|---|---|\n| `deal_id` | Foreign key to `deals` — facts are deal-scoped, not user-scoped. |\n| `company_id` | Inherited from the deal. Multi-tenant isolation. |\n| `key` | ≤ 200 chars. Short, stable, kebab-case. |\n| `value` | Any JSON value. Scalar, list, or small object. |\n| `note` | ≤ 1000 chars. Optional provenance. |\n| `updated_at` | Set on every write. |\n\nRe-writing the same `(deal_id, key)` is idempotent — value and note are replaced.\n\n## Institutional pattern\n\nThe right workflow on any non-trivial deal session:\n\n1. **Open** — `recall_deal_facts(deal_id)` (or `ololand-dd-recall`) to load every confirmed fact before doing anything else.\n2. **Cross-reference** — when the model says something that contradicts a recalled fact, the *fact* wins by default. Investigate the contradiction.\n3. **Confirm** — when the user agrees that an AI-surfaced number or claim is correct, `remember_deal_fact` (or `ololand-dd-remember`) it. Don't wait until end-of-session.\n4. **Close** — at session end, the next analyst (or you, next week) re-opens by step 1 and inherits everything.\n\n## What NOT to put here\n\n| Wrong table | Belongs in |\n|---|---|\n| Risks (severity, financial impact, materiality) | `deal_risks` — surfaced via `get_deal_risks`. |\n| Materialized risks (post-close outcomes) | `materialized_risks` — surfaced via `record_materialized_risks`. |\n| Deal outcome (IRR, MoIC, hold period, etc.) | `deal_outcomes` — surfaced via `record_deal_outcome`. |\n| Claim-level AI errors | `analyst_corrections` — surfaced via `unsupported OpenAI claim-correction workflow (see unsupported-workflows.json)`. |\n| Assumption status (open/blocking/approved) | `deal_assumptions` — surfaced via `set_assumption_status`. |\n| Conversation-scoped TODO list | `write_todo` / `update_todo` — turn-scoped, not persistent. |\n\nPutting these in `deal_session_memory` muddies the dedicated surfaces; the flywheel can't train on miscategorized data.\n\n## Companion tools\n\n- `remember_deal_fact` — write.\n- `recall_deal_facts` — read (with optional `keys` filter).\n- `search_extracted_knowledge` — semantic search over AI-extracted insights (different surface; not analyst-confirmed).\n\nCompanion commands: `ololand-dd-remember`, `ololand-dd-recall`.\n\n\n## OpenAI execution requirements\n\nUse the connected MCP server's current tool schemas. Do not invent tool arguments, job-status endpoints, inputs, or outputs. If a referenced tool is unavailable, explain the limitation and request the needed connection or data. Invoke writes only when the user has requested the corresponding action. Do not initiate purchases or payments. An unrun, unsupported, or unavailable procedure is a gap, never a passing result.\n\n\nOpenAI cannot execute local lifecycle hooks. Use the packaged explicit setup/review workflow when requested. Server-side MCP auditing remains authoritative; preserve evidence blockers and human-only approval gates.\n\nClaim-correction submission is unsupported in this OpenAI upload because the current handler records surface=cowork. Do not invoke submit_agent_claim_correction from OpenAI. Explain the limitation and retain proposed correction text for human review without claiming submission. See unsupported-workflows.json for the excluded canonical workflow.\n"
}