← OloLand DDCONTENT HISTORY
WHAT CHANGED
Update to OloLand DD
Snapshot Nov 2, 2026 · 18:12 UTC · version 1.26.7
Collection source: downloaded plugin package.
First saved snapshot
No earlier snapshot is available to establish a change.
Save OloLand DD and check future changes in Following.
Up to 10 plugins free · no card required.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Use when the user asks to edit, correct, fix, update, or redline text inside a deal's documents — a wrong figure, a stale name, a sentence to amend across the data room. Launches an agentic editing session via edit_deal_documents; every edit lands as a pending_approval patch a HUMAN must approve and commit. Covers launch→poll→read, writing deterministic edit instructions, pinning the working set, the approval flow, and what the verifiers will reject.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 454
}
],
"name": "document-editing",
"skill_md_contents": "---\nname: document-editing\ndescription: \"Use when the user asks to edit, correct, fix, update, or redline text\\\n \\ inside a deal's documents \\u2014 a wrong figure, a stale name, a sentence to amend\\\n \\ across the data room. Launches an agentic editing session via edit_deal_documents;\\\n \\ every edit lands as a pending_approval patch a HUMAN must approve and commit.\\\n \\ Covers launch\\u2192poll\\u2192read, writing deterministic edit instructions, pinning\\\n \\ the working set, the approval flow, and what the verifiers will reject.\"\n---\n\n# Document Editing (human-approved patches)\n\nOloLand can edit deal documents agentically — but it never commits anything\nitself. An editing agent mounts the relevant documents, makes the edits, and\neach accepted edit becomes a `pending_approval` patch that passes four\ndeterministic verifiers. A human reviews, approves (or rejects) and commits\npatches into a new document version. Full provenance: proposer, rationale,\nevidence quote, verifier verdicts, approval note, version lineage.\n\n## The flow (launch → poll → read → approve)\n\n1. **Launch**: `edit_deal_documents(deal_id, instruction, file_ids?)` —\n returns a `task_id` immediately. Costs 10 credits. Sessions take\n seconds to a couple of minutes.\n2. **Poll**: `check_task_status(task_id)` until completed.\n3. **Read**: `list_patches(deal_id, status=\"pending_approval\")` — patches\n are DB-backed and stay readable after the task id expires. Each patch\n carries op, before/after text, evidence, and verifier verdicts.\n4. **Approve & commit (HUMAN step)**: in the web app under\n **Deal → Document Edits** (`/deals/<deal_id>/patches`). The MCP rail is\n fail-closed for human approvals: never call `approve_patch` or\n `commit_version` through MCP. Never auto-approve on the user's behalf —\n surface the pending patches and let the user decide in the app.\n\n## Writing instructions that land deterministically\n\n- **Quote the exact text to change**: `replace \"FY2024 revenue of $12.4M\"\n with \"FY2024 revenue of $12.6M\"` beats `fix the revenue figure`.\n- **Pin the working set when you know the file**: pass `file_ids` to skip\n retrieval-based candidate discovery — faster and unambiguous.\n- **One logical change per instruction.** The editing agent keeps each\n edit inside one paragraph; cross-paragraph rewrites are rejected.\n- **Repeated text** (OCR'd forms, boilerplate): the agent uses\n replace-all semantics — each occurrence becomes its own patch; the\n reviewer can approve them individually.\n\n## What gets rejected (and why that's the product)\n\n- Edits without source evidence (P0 `patch_evidence`).\n- Edits where the quoted before-text no longer matches the document\n (P0 `patch_before_text_match` — the document changed underneath).\n- Cross-paragraph rewrites and table-structure changes (cells are\n editable; pipes/headers are not).\n\nRejected attempts persist as audit rows — say so rather than retrying\nblindly; re-read the patch list and adjust the instruction.\n\n## What this is NOT\n\n- Not committed automatically — `pending_approval` is the terminal state\n of the agent's work; humans approve and commit in the app only. The MCP\n `approve_patch` and `commit_version` tools are never callable approval paths.\n- Not available when `AGENT_SDK_DOC_EDITING_ENABLED` is off — the tool\n returns a clear disabled message; relay it, do not retry.\n- Not for creating new documents — it edits text of existing deal\n documents (PDFs are edited via their extracted text render).\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"
}SHA-256 of public snapshot: be56cbe42c60a2ba9452eb1f14faacf01a4749e81544f530fe4be39f24510066