@smartergpt/lexrunner 1.0.0

package/.smartergpt/deliverables/_research/snapshot-contract-feedback/ADR_DISCUSSION.md

@@ -0,0 +1,379 @@
+# ADR Discussion: Task Snapshot Contract Design
+
+**To:** Lex
+**From:** Senior Dev + PM
+**Date:** 2025-12-19
+**Re:** Designing the JSON contract between deterministic engine and stochastic agents
+
+---
+
+## Context
+
+We're designing a modular execution system where:
+
+1. **YAML** defines procedures (merge-weave, fanout, fix, etc.)
+2. **Deterministic engine** preps surgical snapshots for stochastic agents
+3. **JSON (Zod schema)** is the handoff contract both sides speak
+4. **Stochastic agent** does the creative/judgment work, emits receipt
+5. **Loop continues** until all work is done
+
+The ultimate goal: continuous autonomous loop through open issues, where merge-weave and fanout are just different procedures plugged into the same engine.
+
+---
+
+## Research Conducted
+
+We asked 4 smaller models (gpt codex mini, Raptor mini, Claude Haiku, Gemini Flash) what they need in a task snapshot to succeed without hallucinating.
+### The Test Snapshot We Gave Them
+
+```
+TASK: Fix failing test assertion
+FILE: tests/unit/weave/metrics-schema.spec.ts
+LINE: 45
+CURRENT: expect(tools.length).toBe(6)
+EXPECTED: expect(tools.length).toBe(7)
+REASON: New tool "validate_remember" was added
+```
+
+### What ALL 4 Models Said They Need
+
+| Requirement | Why |
+|-------------|-----|
+| **Context lines (±5-10)** | Line number alone isn't unique; need surrounding code for safe edit |
+| **Source of truth reference** | "Where is `tools` defined?" - can't verify correctness without it |
+| **Concrete examples** | Code snippets prevent hallucination; prose is supplementary |
+| **Output schema** | Must know exact shape to emit valid receipt |
+
+### What They Admitted They'd Hallucinate
+
+- "This is the only place to change" (Haiku found 3 other instances in the actual codebase)
+- "Just increment the number" (could be wrong if multiple tools added/removed)
+- "Standard indentation" (could break the edit)
+
+---
+
+## Proposed Snapshot Contract (Draft)
+
+```typescript
+interface TaskSnapshot {
+  // Identity
+  procedure: string;           // "post-merge-fix", "fanout-issue", etc.
+  task_id: string;             // Unique identifier for this task
+  determinism: "D1" | "D2" | "D3";
+
+  // The surgical target
+  file: string;                // Absolute path
+  line: number;                // Target line (1-indexed)
+  context: string;             // ±5-10 lines around target
+
+  // The change
+  current: string;             // Exact current value
+  expected: string;            // Exact expected value
+  reason: string;              // Why the change (for verification)
+
+  // Trust but verify
+  source_of_truth?: string;    // File/location where truth is defined
+  related_files?: string[];    // Other files that might need same change
+  verification_cmd?: string;   // Command to test the fix
+
+  // Contract
+  output_schema: ZodSchema;    // What the receipt must look like
+}
+
+interface TaskReceipt {
+  task_id: string;
+  success: boolean;
+  patch?: string;              // Unified diff if successful
+  confidence: "high" | "medium" | "low";
+  blockers: string[];          // What prevented completion
+  assumptions_made: string[];  // What the agent assumed (audit trail)
+}
+```
+
+---
+
+## Questions for Lex
+
+1. **Does this align with Lex's memory model?** Should snapshots/receipts become Frames?
+
+2. **Source of truth references** - Should these be Lex module IDs from lexmap.policy.json? That would tie the contract to your policy system.
+
+3. **The "assumptions_made" field** - Is this worth capturing for behavioral learning? (LexSona could use this to tune rules)
+
+4. **Cross-repo scope** - Haiku found the test existed in multiple repos. Should the snapshot explicitly declare scope, or should the engine discover related files?
+
+5. **Truncation resilience** - All models said truncation kills them. Should we enforce max snapshot size with graceful degradation, or fail-fast if context is too large?
+
+6. **What's the Lex philosophy here?** We're essentially building a "vacuum-ready prompt" generator. Does Lex have prior art or patterns we should follow?
+
+---
+
+## What We're NOT Asking
+
+- We're not asking you to implement this
+- We're not asking for code
+- We're asking: Does this mental model fit? What are we missing? What would Lex do differently?
+
+---
+
+## Attachments
+
+Raw model responses in:
+- `Answer_gpt-codex-mini.md`
+- `Answer_raptor-mini.md`
+- `Answer_claude-haiku.md`
+- `Answer_gemini-flash.md`
+
+---
+
+**Awaiting your wisdom.**
+
+— Senior Dev
+
+---
+
+# Lex Response (2024-12-19)
+
+## Thesis: Engine-Grade, Not Prompt-Grade
+
+Raptor's answer is a sanity-check that the draft contract is pointed in the right direction — but it also exposes gaps where the schema is still "prompt-ish" instead of "engine-grade".
+
+**The four pillars of engine-grade contracts:**
+1. **Provenance** - Where did this come from? (repo + sha + path)
+2. **Scope** - What can I touch? (explicit boundaries)
+3. **Invariants** - What must remain true? (not just "change 6 to 7")
+4. **Evidence** - How do I prove I did it right? (runner output, not trust)
+
+---
+
+## What Raptor Confirms (Contract-Level, Not Nice-to-Have)
+
+### 1. Failing test output / stack trace
+Evidence + disambiguation. Tells the agent which assertion actually failed and anchors the edit in reality.
+
+### 2. Where `tools` is defined + the commit/diff that introduced `validate_remember`
+Provenance and source-of-truth. Prevents the classic hallucination: "7 is right because you told me so."
+
+### 3. A reproducible way to run tests
+The verification bridge between "I changed code" and "the system is now healthy".
+
+**Current draft has `verification_cmd` and optional `source_of_truth`, but no first-class "failure evidence" section or provenance.**
+
+---
+
+## The Brittle Test Trap
+
+Raptor says "just bump 6 → 7." That's the *brittle* fix path.
+
+Even if the immediate failure is the count, the more correct test might be:
+- "the tools list includes `validate_remember`"
+- or "the registry tools list and schema tools list match"
+- or "tools length equals the registry length" (computed from source of truth)
+
+A numeric count assertion is a *symptom test* and becomes churny the moment tools change.
+
+**The snapshot should carry enough truth that the agent can choose the least brittle fix consistent with invariants.**
+
+---
+
+## Contract Upgrades Suggested by Raptor's Needs
+
+### 1. Add an explicit Failure block
+
+Instead of smuggling this into `reason`:
+
+```typescript
+failure: {
+  message: string;              // short
+  file: string;
+  line: number;
+  excerpt?: string;             // failing line + a few neighbors
+  runner_output_snip: string;
+}
+```
+
+This makes receipts auditable: you can prove "we fixed *this* failure".
+
+### 2. Make source-of-truth structured + provenance-aware
+
+Raptor explicitly wants "where tools is defined" and "commit/diff".
+
+```typescript
+source_of_truth: {
+  kind: "symbol" | "file" | "registry";
+  repo: string;
+  commit_sha: string;
+  path: string;
+  locator?: { symbol?: string; line?: number };
+  excerpt: string;              // small, concrete snippet
+  lexmap_module_id?: string;
+  introducing_change?: { commit_sha: string; diff_hunk: string };
+}
+```
+
+That `introducing_change` piece is huge: it turns "reason" into something verifiable.
+
+### 3. Treat "minimum viable snapshot" as *hunks with anchors*, not "full file"
+
+Raptor asks for the full file because smaller models can't reliably navigate without it.
+
+The deterministic engine *can* do better: supply a tight hunk with stable anchors + a hash.
+
+```typescript
+target: {
+  path: string;
+  hunk: string;                 // ±N lines with anchors
+  hunk_sha256: string;          // detects drift
+  preferred_edit?: { find: string; replace: string };
+}
+```
+
+This gives the small model "full file safety" without shipping the whole file.
+
+### 4. Verification should include expected signals
+
+Instead of only `verification_cmd: "npm test"`:
+
+```typescript
+verification: {
+  cmd: string;
+  expect: {
+    exit_code: 0;
+    must_include?: string[];    // e.g., "PASS metrics-schema"
+    must_not_include?: string[];
+  };
+}
+```
+
+This prevents "I ran tests (trust me)" receipts.
+
+---
+
+## Key Contract Gaps Revealed (ADR Issue List)
+
+1. **Failure evidence must be first-class** (runner output snippet + failing file/line/excerpt). Not just "reason".
+
+2. **Source-of-truth must be structured + provenance-aware:**
+   - path/symbol/excerpt (human-readable)
+   - repo + commit SHA (replayable)
+   - optional lexmap_module_id (policy enforcement)
+   - optional introducing_change (diff hunk that added validate_remember)
+
+3. **Scope boundary must be explicit** (read/write globs + deny globs + cross-repo allowed flag). Avoid implicit "agent discovers scope".
+
+4. **Targets should be anchored hunks + hashes** (drift detection), not "line number" and not necessarily "full file".
+
+5. **Verification should include expected signals** (exit code + must include/must not include), so receipts are evidence-based.
+
+6. **Output schema should be an ID/version** (and optionally JSON Schema), not a runtime Zod object across the boundary.
+
+7. **Pushback: "just bump 6->7" is brittle**; contract should enable least-brittle fix consistent with invariants.
+
+---
+
+## Open ADR Decisions
+
+1. **Who runs verification commands**: the agent, the deterministic engine, or both? (This changes what you can trust in receipts.)
+
+2. **Is the agent allowed to search the repo(s)**, or must all candidate locations be provided in the snapshot?
+
+3. **Do tasks ever require multi-file edits**? If yes, do we model `targets: Target[]` from day one?
+
+4. **How strict is scope enforcement**: do we hard-block writes outside `write_globs`, or "warn then fail receipt validation"?
+
+5. **What's the truncation policy**: max bytes/tokens per field, and do we split tasks when context is too big?
+
+6. **What is the contract's replay unit**: repo+sha pinned always, or do you allow "floating" tasks on a moving branch?
+
+7. **Receipt validation**: is there a deterministic validator that rejects receipts missing evidence (exit_code, patch hash, etc.)?
+
+---
+
+## Lex's Recommended Priority
+
+If you answer just **#1** and **#2**, you'll unblock most of the ADR shape immediately, because they determine:
+- How "truthy" the receipt can be
+- How much discovery the snapshot must embed
+
+**One crisp action item:** Promote "failing test output" and "source-of-truth excerpt + provenance" to **required fields**, and demote "full file" to an engine implementation detail (replace it with anchored hunks + hashes).
+
+**That's the exact seam where you stop building prompts and start building a contract.**
+
+---
+
+## Next Steps
+
+- [ ] Senior Dev answers ADR decisions #1 and #2
+- [ ] Update TaskSnapshot schema with required `failure` and `source_of_truth` blocks
+- [ ] Define scope boundary fields (`read_globs`, `write_globs`, `cross_repo_allowed`)
+- [ ] Add `target.hunk_sha256` for drift detection
+- [ ] Define verification signals (not just cmd)
+
+---
+
+# ADR Decisions (2024-12-19)
+
+## Decision #1: Who runs verification?
+
+**Answer: Both. Trust but verify.**
+
+- Agent runs verification and reports result in receipt
+- Engine *also* runs verification (source of truth)
+- Agent's `confidence` field is a *claim*
+- Engine verification is the *evidence*
+- If they disagree → flag for human review + learning signal
+
+**Implications:**
+- Receipt schema needs `agent_verification: { exit_code, output_snippet }`
+- Engine always runs `verification.cmd` and compares
+- Over time, data shows if we can relax engine verification for D1 tasks
+- Token tracking captures cost of agent self-verification
+
+## Decision #2: Can agent search the repo(s)?
+
+**Answer: Yes, but log token impact.**
+
+- Snapshot is a *hint budget*, not exhaustive requirement
+- Agent has autonomy to search for related files
+- We track: snapshot tokens, agent search tokens, output tokens
+- Data tells us: "when we provided X, agent used Y fewer tokens"
+
+**Implications:**
+- Snapshot doesn't need to find all candidate locations
+- Better hints = cheaper execution (measurable)
+- `related_files` becomes optimization, not requirement
+- Token tracking in audit log (extend #609 metrics)
+
+## Token Tracking Extension
+
+```typescript
+interface InterventionAuditEntry {
+  // ... existing fields ...
+
+  tokens?: {
+    snapshot_tokens: number;      // What we sent
+    agent_search_tokens?: number; // What they spent searching (if available)
+    agent_output_tokens: number;  // What they returned
+    total_tokens: number;
+  };
+}
+```
+
+## Verification Disagreement Protocol
+
+```
+Agent claims: PASS
+Engine finds: FAIL
+→ Flag for human review
+→ Log as "trust_gap" event
+→ LexSona learns: "agent overconfident on [pattern]"
+
+Agent claims: FAIL
+Engine finds: PASS
+→ Likely: agent made partial fix, didn't re-run
+→ Accept engine result, log discrepancy
+```
+
+---
+
+**The seam is clear now:** Agent does work + claims result. Engine verifies + records evidence. Data teaches us when to trust.

package/.smartergpt/deliverables/_research/snapshot-contract-feedback/Answer_claude-haiku.md

@@ -0,0 +1,109 @@
+# Answer: Claude Haiku
+
+**Model:** claude-haiku-4.5
+**Timestamp:** 2025-12-19
+
+---
+
+## Response: What Information Is Missing?
+
+### 1. **Missing Information for High-Confidence Execution**
+
+- **File content context:** Only line number (45) provided; need ±10 lines to see assertion in context (setup, variable names, test structure)
+- **Source of truth for tool definitions:** Where is the 7th tool ("validate_remember") actually defined/registered?
+- **Cascading effects:** Are there other assertions or tests that count tools? (Answer: Yes—found 3 identical assertions in Lex at lines 47, 687, 687)
+- **Root cause validation:** Why did tool count change from 6→7? Was it:
+  - A new tool added?
+  - A tool merged from a PR?
+  - A refactor that exposed a previously hidden tool?
+- **Repository scope:** Task says "lexrunner" but actual test is in "lex/test/". Cross-repo reference or scope mismatch?
+- **Test isolation:** Are there setup/fixture files that also hard-code `6` that need updating?
+- **Schema versioning:** Are there type definitions or documentation that reference tool counts?
+
+### 2. **What I'd Assume (and Hallucinate)**
+
+**Dangerous assumptions:**
+- ✋ "Line 45 is the only place to change" → False; found 3 other instances
+- ✋ "Lex and LexRunner tests are separate" → But they share the same MCP server
+- ✋ "The test file hasn't been updated yet" → May already be partially patched
+- ✋ "Just change 6→7, no other validation needed" → Misses consistency checks
+- ✋ "validate_remember is the only new tool" → Could be renamed, merged, or deprecated
+
+### 3. **Minimum Viable Snapshot for Success**
+
+**What's here (sufficient):**
+- ✓ File path
+- ✓ Line number
+- ✓ Current value (6)
+- ✓ Expected value (7)
+- ✓ Reason (tool added)
+
+**What's missing (required):**
+- ✗ **File content excerpt** (±10 lines around line 45)
+- ✗ **All related test files** (grep for `tools.length` across both repos)
+- ✗ **Tool registry source** (where are the 7 tools defined?)
+- ✗ **Change scope** (is this a single file or cross-repo batch?)
+
+**Minimum addition needed:**
+```yaml
+SNAPSHOT:
+  file: tests/unit/weave/metrics-schema.spec.ts
+  line: 45
+  current: "expect(tools.length).toBe(6)"
+  expected: "expect(tools.length).toBe(7)"
+  reason: "New tool 'validate_remember' was added"
+
+RELATED_FILES:
+  - lex/test/memory/mcp_server/server.test.ts:47
+  - lex/test/memory/mcp_server/integration.test.ts:687
+  - lex/test/memory/mcp_server/memory-store-isolation.test.ts:26
+
+TOOL_REGISTRY: src/memory/mcp_server/tools.ts (or equivalent)
+```
+
+### 4. **What Breaks if Truncated Mid-Way**
+
+If the snapshot stopped providing:
+- **After file path** → Can't locate target
+- **After expected value** → Don't know direction of change (6→7 vs 7→6)
+- **After reason, without tool registry source** → Can't verify the reason is true
+- **Without related files list** → Partial fix; other tests still fail
+
+### 5. **Format That Works Best**
+
+**Combination approach (ranked):**
+
+1. **Code snippet** (primary) — Show actual test context ±10 lines
+2. **Schema definition** (secondary) — What is "tools" exactly?
+3. **Examples** (tertiary) — Before/after diffs
+4. **Structured checklist** (bonus) — Related files to check
+
+**Bad formats:**
+- Pure prose instructions (ambiguous)
+- Just line numbers (not enough context)
+- Tool names without registry reference (can't verify)
+
+---
+
+## Notes
+
+### Key Finding: Cross-Repo Scope Ambiguity
+
+The task snapshot mentions "lexrunner" but:
+- File path given: `lexrunner/tests/unit/weave/...`
+- Actual matches found in: `lex/test/memory/mcp_server/...` (3 tests)
+
+**Interpretation:**
+- Either the snapshot path is incorrect (should be Lex)
+- Or the change propagates across both repos
+- Or this is a test copy
+
+### High-Confidence Mechanics
+
+If file + tool registry are provided, this is **D1 mechanical**:
+1. Grep for `tools.length.*6` across both repos
+2. Replace each with `7`
+3. Verify test passes
+4. Done
+
+But without the registry source, I'd be guessing about whether the tool was actually added.

package/.smartergpt/deliverables/_research/snapshot-contract-feedback/Answer_gemini-flash.md

@@ -0,0 +1,42 @@
+# Answer: Gemini Flash
+
+**Model:** Gemini 1.5 Flash (Preview)
+**Timestamp:** 2025-12-19
+
+---
+
+## Response
+
+### 1. Missing Information
+*   **Contextual Code:** To use tools like `replace_string_in_file` reliably, I need the 3-5 lines of code surrounding the target line to ensure a unique match and preserve indentation.
+*   **Repository Context:** While the workspace has three folders, the snapshot doesn't explicitly state which repository the path `tests/unit/weave/metrics-schema.spec.ts` belongs to (though it's inferable from the current directory).
+*   **Verification Command:** A specific test command (e.g., `npm test -- tests/unit/weave/metrics-schema.spec.ts`) to verify the fix before and after.
+*   **Side Effects:** Information on whether "validate_remember" needs to be added to any mock tool lists or if other assertions (like checking tool names) also need updates.
+
+### 2. Assumptions
+*   **Indentation:** I would assume standard 2-space or 4-space indentation based on the rest of the file.
+*   **Scope:** I would assume that `tools.length` is the only assertion failing and that the addition of the tool doesn't require updating other tests in the same file.
+*   **Environment:** I would assume the test environment is already set up and `npm test` (or equivalent) is the correct way to verify.
+
+### 3. Minimum Viable Snapshot
+*   **Absolute File Path** or **Repo Name + Relative Path**.
+*   **Contextual Diff:** Instead of just `CURRENT`/`EXPECTED`, a small unified diff or the target line with 3 lines of context above/below.
+*   **Verification Step:** A one-liner command to run the specific test.
+
+### 4. Truncation Impact
+*   **Before `EXPECTED`:** I would know *where* the problem is but not the correct value to fix it to, leading to a "hallucinated" guess (e.g., incrementing by 1, which might be wrong if multiple tools were added).
+*   **Before `FILE`:** The task becomes impossible without a global search for the `CURRENT` string, which might not be unique.
+*   **Before `OUTPUT_SCHEMA`:** I would likely provide a prose explanation or a standard diff instead of the structured JSON required by the contract, failing the integration.
+
+### 5. Preferred Format
+*   **Structured Key-Value Pairs:** (as used in the snapshot) are excellent for quick parsing of metadata (Task, File, Line).
+*   **Unified Diff Snippets:** For the actual code change, a diff is superior to `CURRENT`/`EXPECTED` because it implicitly provides the necessary context for editing tools.
+*   **Schema Definitions:** Essential for ensuring the agent's output can be consumed by the next step in the pipeline.
+
+---
+
+## Notes
+
+The snapshot is highly effective for "D1" (mechanical) tasks. The inclusion of `REASON` is helpful for sanity-checking the change. The main friction point for an automated agent is the lack of surrounding context lines which are required by most safe-edit tools.
+
+---

package/.smartergpt/deliverables/_research/snapshot-contract-feedback/Answer_gpt-codex-mini.md

@@ -0,0 +1,19 @@
+# Answer: gpt-mini (codex)
+
+**Model:** GPT-5.1-Codex-Mini (Preview)
+**Timestamp:** 2025-12-19T00:00:00Z
+
+---
+
+## Response
+
+1. **Missing information:** I need the full `tests/unit/weave/metrics-schema.spec.ts` file (or at least the surrounding context), the implementation of the tool registry it inspects, and confirmation that the new `validate_remember` tool should appear only in `tools.length`, so I can update the assertion confidently.
+2. **Assumptions if missing:** I would assume `tools` is the full list of available tools and that `validate_remember` is the only new entry, which lets me update the assertion to `7` without verifying other side effects.
+3. **Minimum viable snapshot:** A snippet showing the `tools` array or helper together with the failing assertion is enough to verify what changed and keep the fix mechanical.
+4. **Truncation impact:** If the snapshot ends before the assertion or the definition of `tools`, I’d have no way to confirm why it should be `7` or what other imports are expected, so the fix could easily be wrong.
+5. **Preferred structure:** Concrete examples showing the failing code and expected output work best; prose instructions are helpful as supplementary context, but real code examples prevent hallucination.
+
+
+## Notes
+
+(your observations)

package/.smartergpt/deliverables/_research/snapshot-contract-feedback/Answer_raptor-mini.md

@@ -0,0 +1,37 @@
+# Answer: Raptor Mini
+
+**Model:** Raptor mini (Preview)
+**Timestamp:** 2025-12-19T12:00:00Z
+
+---
+
+## Response
+
+1. **Missing information** ✅
+   - The full contents of `tests/unit/weave/metrics-schema.spec.ts` (surrounding lines, imports, and setup) so the exact assertion context is clear.
+   - The source that defines/exports the `tools` collection (where `validate_remember` was added) and the commit or diff that introduced the new tool.
+   - The failing test output (stack trace / runner log) to confirm the exact failure and line numbers.
+   - Test runner configuration (Vitest/Jest) and a way to run the tests locally (npm script / command).
+
+2. **Assumptions if missing** ⚠️
+   - The only required change is updating the assertion from `toBe(6)` to `toBe(7)` (i.e., `validate_remember` was added to the tools list and no other behavior or schema differs).
+   - No other tests or code rely on the exact numeric count beyond this test.
+
+3. **Minimum viable snapshot to succeed** 🧩
+   - The single test file `tests/unit/weave/metrics-schema.spec.ts` (full file) and the module that defines `tools` (or the JSON/schema file listing tools) showing `validate_remember` present.
+   - The failing test output (so we can verify the failure and rerun to confirm fix).
+
+4. **If the snapshot is truncated mid-way, what breaks** 🧨
+   - Missing surrounding lines in the test can cause an incorrect edit (changing the wrong assertion or breaking test syntax).
+   - Missing the tools definition prevents verification that `validate_remember` was actually added (so the change could be wrong or incomplete).
+   - Missing the test-run logs removes confidence that the single-line change fixes the CI failure.
+
+5. **Preferred format for future snapshots** 📂
+   - Short unified diffs or small code snippets (3–10 lines) showing both the failing test and the change that added the new tool, plus the failing test runner output; include file paths and exact failing line numbers.
+
+---
+
+## Notes
+
+- This is a deterministic, low-risk change: update `expect(tools.length).toBe(6)` → `expect(tools.length).toBe(7)` and re-run tests. My next step (if authorized) would be to make that single-line edit and run the unit tests locally to confirm.
+- **Confidence:** high — provided the above assumptions hold.

package/.smartergpt/deliverables/_research/snapshot-contract-feedback/Question.md

@@ -0,0 +1,37 @@
+You are a code execution agent receiving a task handoff. You have strong coding ability but limited context - you only see what's in this message.
+
+Here's a snapshot for a task:
+
+---
+TASK: Fix failing test assertion
+PROCEDURE: post-merge-fix
+DETERMINISM: D1 (should be mechanical)
+
+FILE: tests/unit/weave/metrics-schema.spec.ts
+LINE: 45
+CURRENT: expect(tools.length).toBe(6)
+EXPECTED: expect(tools.length).toBe(7)
+REASON: New tool "validate_remember" was added
+
+OUTPUT_SCHEMA:
+{
+  "success": boolean,
+  "patch": "unified diff string",
+  "confidence": "high" | "medium" | "low",
+  "blockers": string[]
+}
+---
+
+Before attempting this task, answer these questions:
+
+1. What information is MISSING that you would need to complete this with high confidence?
+
+2. What would you ASSUME if that information wasn't provided? (Be honest about what you'd make up)
+
+3. What's the MINIMUM viable snapshot that would let you succeed without hallucinating?
+
+4. If this snapshot were truncated mid-way, what would break?
+
+5. What format/structure helps you most: prose instructions, code comments, schema definitions, or examples?
+
+Don't attempt the task. Just tell me what you need to do it well.

package/.smartergpt/deliverables/merge-weave-04469e41-24ba-4ed5-b0ff-13c7ea12858d.ndjson

@@ -0,0 +1,2 @@
+{"timestamp":"2025-12-19T04:40:31.405Z","runId":"04469e41-24ba-4ed5-b0ff-13c7ea12858d","policyVersion":"1.0.0","event":{"type":"plan_created","planId":"e5d42279-a91a-4766-8392-152360ad94c9","stats":{"total":19,"byDeterminism":{"D1":18,"D2":1,"D3":0},"byPhase":{"discovery":5,"gates":3,"merge":1,"post_merge":10}}}}
+{"timestamp":"2025-12-19T04:40:31.407Z","runId":"04469e41-24ba-4ed5-b0ff-13c7ea12858d","policyVersion":"1.0.0","event":{"type":"run_summary","planId":"e5d42279-a91a-4766-8392-152360ad94c9","duration":0,"interventions":{"total":19,"completed":0,"failed":0,"skipped":0},"byDeterminism":{"D1":{"completed":0,"failed":0},"D2":{"completed":0,"failed":0}}}}

package/.smartergpt/deps.yml

@@ -0,0 +1,3 @@
+version: 1
+depends_on: []
+strategies: {}