Case Data Material Planner

case-data-material-planner

One-stop material engine between case authoring and case execution.

• Build an optional business-context graph from requirements
• Parse entities and actions from each case
• Construct data and bind commands through adapters
• Emit case-executable.md

How the work is divided

scripts/pipeline.ts owns orchestration. You supply judgment at three points only — parse-case, knowledge-build, and select-tool — and the script does construction, binding, linting, and writeback. This split exists because those three stages need reading comprehension while the rest must be reproducible: a case re-run tomorrow has to yield the same manifest, which is impossible if a model re-derives each step. So when the runner exits asking for one of the three, launch that Agent, merge its patch, and --resume; do not take over a stage the script already implements (invoke_entity.ts, bind_action.ts, slot_render.ts), and with 2+ cases go through the dispatcher so each case gets its own pipeline.ts process.

Hard constraints

These are the ones that silently corrupt output rather than failing loudly, which is why they are worth stating:

• Do not invent business IDs, amounts, or config values. A plausible-looking ID makes a case that fails at execution time with no trace of where the value came from. When unsure, record failReason and let the gate surface it.
• Parse before constructing. Data needs come from the case's preconditions and steps; skipping parse means constructing something the case never asked for.
• Keep case-executable.md business-only. No node / python / bash invoke lines, no skillRoot, cwd, host, or mock-server ports — those live in manifest.json (invokeCmd / filledCmd). The case document is read by people and replayed in other environments, where local paths and ports are wrong or meaningless.
• Persist every non-envelope business field, not just the primary ID. A downstream step usually needs the attributes that came back with it, and re-fetching them is not always possible.
• Respect the gates. C3 stays blocking when lint-gate is abnormal, and the lint-gate loop runs at most 3 rounds before it must hand the decision to the user — an unbounded loop burns the run without converging.
• During knowledge-build, describe the business, not a shopping list. The graph answers "what does this domain look like"; deciding what data to prepare is the parse stage's job and doing it early biases the parse.

---

Entry routes

After receiving the request, classify the input:

Path A: requirement / design doc (+ cases)

1. Read planner.md and run scripts/pipeline.ts
2. Exit 12 → knowledge-build Agent, merge, --resume
3. Then parse (exit 11) or continue if cases were already parsed

Path B: cases only (no requirement doc)

1. Read planner.md and run scripts/pipeline.ts --case-id … --source …
2. Reuse ./testdata/case-materials/business-context.json via --context when it exists
3. Otherwise knowledge-build is skipped by the runner
4. Handle exit 11 (parse-case) then --resume. Construction, binding, and writeback stay inside pipeline.ts — do not take those stages over.

Path C: batch (2+ cases)

When the user supplies 2 or more cases:

1. Read case-dispatcher.md and follow it
2. One pipeline.ts process per case (parallel). Shared knowledge-build once
3. The user talks to the dispatcher, not a per-case Planner Agent

Rule:

• case count ≥ 2 → Path C
• case count == 1 → Path A or B

Input sources (highest first)

Priority 0 is an optional fast path. sourceType values: remote-case | local-file | planId | paste. They map to the four legal caseSource.type values. Callers that omit sources[] still use priorities 1–4 interactively.