feat(weave): batch untargeted multi-pending first-payload weave - #33
Conversation
- planWeave dispatches an untargeted candidate set through the existing coherent payload-batch planner when every candidate classifies as firstPayloadWeave (and overwrite is not requested); single-target and explicit multi-target behavior unchanged - prepareVersionExecution recognizes the untargeted all-first-payload set after candidate discovery and routes it through the existing batch-plan branch as one policy-validated VersionPlan; mixed, recursive, and later-payload sets stay on the sequential path - core tests: reverse-order untargeted batch (fail-on-old: "supports exactly one weave candidate; found 2") producing canonical ordering, one MeshInventory state + one working update, both payload and Knop facts merged; exact-target narrowing regression - integration test: docs-rooted sidecar with ontology+shacl integrated, untargeted executeWeave, versioned MeshInventory advancing ONCE (fail-on-old: sequential loop created _s0002 AND _s0003) - first-payload bite 1 of wa.task.2026.2026-07-03_1332 (brief in that note); full deno task ci green Implemented-By: Codex (codex exec) as Kim Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LHrFYeUefDr227gLuWWuq1
📝 WalkthroughWalkthroughThe change enables untargeted batching of multiple first-payload weave candidates when overwrite mode is disabled. Runtime planning selects these candidates, while unit and integration tests verify ordering, target isolation, generated outputs, and mesh metadata progression. ChangesFirst-payload batching
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant VersionRequest
participant prepareVersionExecution
participant planWeave
participant MeshOutput
VersionRequest->>prepareVersionExecution: provide multiple pending payload candidates
prepareVersionExecution->>planWeave: pass untargeted first-payload batch
planWeave-->>prepareVersionExecution: return payload batch plan
prepareVersionExecution->>MeshOutput: create payload files and ResourcePages
MeshOutput-->>VersionRequest: return updated mesh metadata
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
staged) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LHrFYeUefDr227gLuWWuq1
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/runtime/weave/version_execution.ts`:
- Around line 413-429: Update the untargeted first-payload path around
untargetedFirstPayloadBatch and batchCandidates to create and verify a
working-file snapshot for initialWeaveableKnops before batch planning. Ensure
the selected candidates are loaded from one consistent payload revision, while
preserving the existing snapshot behavior for explicit payload batches and the
current candidate-selection logic.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 884454da-51c7-4a93-85f2-be34525a5dc2
📒 Files selected for processing (4)
src/core/weave/weave.tssrc/core/weave/weave_test.tssrc/runtime/weave/version_execution.tstests/integration/weave_test.ts
| const untargetedFirstPayloadBatch = targets.length === 0 && | ||
| isUntargetedFirstPayloadBatch( | ||
| meshState.meshBase, | ||
| initialWeaveableKnops, | ||
| ); | ||
| const batchCandidates = untargetedFirstPayloadBatch | ||
| ? initialWeaveableKnops | ||
| : payloadBatchCandidates; | ||
|
|
||
| if ( | ||
| payloadBatchCandidates.length > 0 && | ||
| isExplicitPayloadBatch( | ||
| meshState.meshBase, | ||
| payloadBatchCandidates, | ||
| targetByDesignatorPath, | ||
| ) | ||
| batchCandidates.length > 0 && | ||
| (untargetedFirstPayloadBatch || | ||
| isExplicitPayloadBatch( | ||
| meshState.meshBase, | ||
| batchCandidates, | ||
| targetByDesignatorPath, | ||
| )) |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
Capture and verify a working-file snapshot for untargeted batches.
When targets is empty, shouldAttemptExplicitPayloadBatch returns false. Lines 413-420 then select initialWeaveableKnops without createPayloadBatchWorkingFileSnapshot or its verification. A payload change during candidate loading can produce a batch from mixed input revisions.
Extend the snapshot flow to the selected untargeted first-payload candidates before batch planning.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@src/runtime/weave/version_execution.ts` around lines 413 - 429, Update the
untargeted first-payload path around untargetedFirstPayloadBatch and
batchCandidates to create and verify a working-file snapshot for
initialWeaveableKnops before batch planning. Ensure the selected candidates are
loaded from one consistent payload revision, while preserving the existing
snapshot behavior for explicit payload batches and the current
candidate-selection logic.
|
Disposition of the snapshot-capture suggestion: deliberate skip, boarded as a residual rather than fixed here. The explicit-batch double-hash guard exists because the evidenced Stagecraft checkpoint flow supplies requested targets from a service that owns single-writer serialization — the recorded 2026-07-06 decision scoped capture verification to "the requested targets' current working payload files." The untargeted path has no requested set (candidates are discovered), so extending capture there is a new contract decision, not a bug fix — and it was pre-identified as exactly that in this bite's brief ("needs the explicit checkpoint batch's double-hash input-capture guarantee → separate contract decision; report rather than implement"). It is also not a regression: the sequential loop this dispatch replaces never had capture on the untargeted path either. Boarded on the owning task note; revisit if a service ever drives untargeted weave. 🤖 Generated with Claude Code |
1 participant
First-payload bite 1 of
wa.task.2026.2026-07-03_1332-stagecraft-weave-planner-generalization(Kim brief in that note; carved and fired from planning-loop wakes 6–8). Addresses the first remaining P1 blocker: multi-pending first-payload weave in one transaction — where "transaction" means one validatedVersionPlanand one shared MeshInventory progression, not filesystem atomicity (application-owned, per the recorded decision).What
Untargeted
weaveover two-plus pending candidates that ALL classify asfirstPayloadWeavenow routes through the existing coherent payload-batch planner instead of refusing with the single-candidate cardinality error. One deterministic plan, canonical designator ordering, both payload histories plus configured Knop support histories, one working MeshInventory update, and — under versioned MeshInventory policy — exactly one new HistoricalState per command. Single-target, explicit multi-target, exact-target narrowing, and untargeted mixed/recursive/later-payload sets are all preserved on their existing paths.Evidence
supports exactly one weave candidate; found 2; the integration test failed because the old sequential loop created_s0002AND_s0003where one state was owed; the exact-target regression passed on old code (confirming preserved narrowing).deno task cigreen.Not in this bite
Current-mode extracted-term preservation (sequenced after #31), condition-specific diagnostics, later-payload/recursive/mixed batching, locking/rollback.
Implemented by Codex (
codex exec) as Kim under the standing loop-wake grant; reviewed, validated, and landed by the planning seat.🤖 Generated with Claude Code
https://claude.ai/code/session_01LHrFYeUefDr227gLuWWuq1
Summary by CodeRabbit
New Features
Bug Fixes
Tests