@smartergpt/lexrunner 1.0.0 → 1.3.0

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

@@ -1,379 +0,0 @@
-# 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

@@ -1,109 +0,0 @@
-# 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

@@ -1,42 +0,0 @@
-# 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

@@ -1,19 +0,0 @@
-# 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

@@ -1,37 +0,0 @@
-# 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

@@ -1,37 +0,0 @@
-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

@@ -1,2 +0,0 @@
-{"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

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