feat(miner-plan): add analyze and prepare plan-DAG templates to the shared engine#2628
feat(miner-plan): add analyze and prepare plan-DAG templates to the shared engine#2628GildardoDev wants to merge 1 commit into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2628 +/- ##
=======================================
Coverage 96.05% 96.05%
=======================================
Files 234 235 +1
Lines 26259 26273 +14
Branches 9527 9529 +2
=======================================
+ Hits 25223 25237 +14
Misses 425 425
Partials 611 611
🚀 New features to boost your workflow:
|
|
Warning 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ⏸️ Gittensory review result - manual review recommendedReview updated: 2026-07-03 02:40:31 UTC
⏸️ Suggested Action - Manual Review Review summary Nits — 4 non-blocking
Review context
Contributor next steps
Signal definitions
🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.
|
JSONbored
left a comment
There was a problem hiding this comment.
Merge conflicts, closing.
This branch has conflicts that must be resolved
Use the [web editor](https://github.com/JSONbored/gittensory/pull/2628/conflicts) or the command line to resolve conflicts before continuing.
packages/gittensory-engine/src/index.ts
sorry, but could you plz reopen this PR? so i will fix merge conflict problem |
…d duplicate parser (#4318) Two independently-filed issues (#2652's follow-up to #2293, and #2301) both specified a MinerGoalSpec parser. Two implementations landed around the same time: miner-goal-spec.ts became canonical (re-exported from the package barrel, the only one packages/gittensory-miner's real caller actually imports), while miner-goal-spec-parse.ts's own PR explicitly avoided the barrel "while #2628 is open" as a temporary conflict-avoidance measure that was never reconciled -- it sat published as its own npm subpath export with zero real callers anywhere in the repo. More importantly: the canonical file has the exact resource-exhaustion bug that #2896 patched in its orphaned sibling and nowhere else. normalizeStringList's cap check only fired after a candidate was accepted, so an array of entries that always take the `continue` path (non-string, duplicate, or empty-after-trim) never hit the cap and got scanned in full -- a hostile `.gittensory-miner.yml` with thousands of duplicate/invalid list entries could force unbounded CPU/memory work and unbounded warning growth on every repo a miner considers, since this parser runs on untrusted per-repo config. - Bound normalizeStringList's iteration to the raw array index, before any per-entry work, mirroring #2896's fix -- but WITHOUT that fix's own latent bug: a trailing `result.length >= cap` break (kept for "defense in depth") fires silently, with no warning, whenever the input has exactly cap+1 unique valid entries. A pre-existing test ("caps oversized string lists and ignores extra entries") caught this regression during review. The index-based check alone is both necessary and sufficient to bound work; the trailing check is removed rather than mirrored. - Delete the orphaned miner-goal-spec-parse.ts and its dedicated test (confirmed zero real callers, in-repo or via its published subpath). - Remove the ./miner-goal-spec-parse subpath from package.json's exports map. BREAKING CHANGE: @jsonbored/gittensory-engine's published subpath export is removed. The package is one week old with a single in-repo consumer that never used this subpath; no known external impact. - Add hostile-input regression tests (all-non-string, all-duplicate, all-empty, all-overlong) to both the package-level and root-level test suites for the canonical parser, mirroring the coverage #2896 added for its now-deleted sibling.
Summary
Adds a small library of reusable plan TEMPLATES to the shared engine as
packages/gittensory-engine/src/plan-templates.ts, so a miner does not have to invent its step graph from scratch for each lifecycle stage. Each template is a pure, deterministic builder that returns raw steps in exactly the shapegittensory_build_planaccepts (rawPlanStepSchemainsrc/mcp/server.ts), sobuild_plancan normalize them into a validated DAG. Templates only describe steps and their ordering; they never actuate anything.Closes #2317
Deliverables
analyzePlanTemplate(context?)andpreparePlanTemplate(context?)returningRawPlanStep[]in the{ id, title, actionClass?, dependsOn?, maxAttempts? }shapegittensory_build_planexpects.feasibility-checkandrag-retrievalrun independently, thenprompt-packetdepends on both.branch-createthencoding-agent(a placeholder step, no actuation) thenlocal-test.PLAN_TEMPLATE_BUILDERS(a stage to builder registry) andbuildPlanTemplate(stage, context?)so callers can enumerate or dispatch by stage.context.subjectis woven into every step title as a single clean line, whitespace-collapsed and length-bounded so a long subject can never push a title past the schema's 300-character limit.Notes
RawPlanSteptype mirrorsrawPlanStepSchemaso the engine package stays standalone and imports no app code. The unit tests import the ACTUALrawPlanStepSchema(now exported fromsrc/mcp/server.ts) and assert every template round-trips through it, so the templates can never drift from whatgittensory_build_planaccepts.exportto the existingrawPlanStepSchemaso the drift-guard tests can reference the real schema.Validation
rawPlanStepSchema, ids are unique with only in-plan acyclic dependencies, output is deterministic, the subject is woven as one clean line (and omitted when absent), an oversized subject stays within the 300-char title limit, and the analyze ordering (prompt-packet depends on both feasibility and retrieval).npm run build --workspace @jsonbored/gittensory-enginesucceeds;npm run typecheckis clean; the new tests pass under Vitest.