Generate Test Cases

Generate Test Cases

Use the bundled deterministic compiler to turn requirements into evidence-grounded manual functional Cases. New runs use the exact schema/compiler pair 4.3.0/0.8.0; exact 4.0.0/0.5.0 and 4.2.0/0.7.0 runs retain their bound behavior. v4 is the only public generation workflow. v3 is a legacy, read-only validation or migration input and is never a generation fallback.

The compiler owns validation, stable identity, Facts, scope topology, formal Test Points, semantic roots, classification, coverage, ordering, checkpoints, canonical results, and rendering. The Agent writes only the four requested semantic artifacts: source_pack, evidence_claims, behavior_views, and case_drafts.

Load the matching policy before acting

• Read references/run-management.md before creating, recovering, resuming, repairing, replacing, or cancelling with cancel_run.
• Read references/evidence-policy.md before collecting sources, creating locators, or writing source_pack or evidence_claims.
• Read references/behavior-views.md before writing behavior_views.
• Read references/case-writing-policy.md before writing case_drafts or presenting the business Case document.
• Read references/clarification-policy.md before presenting questions or submitting answer_question_part, defer_question_part, mark_question_unknown, or request_delivery.
• Read references/execution-closure-policy.md before submitting provide_capability_proof, set_execution_disposition, pause_execution, or reopen_semantic_question, and before presenting or confirming an execution plan.

Read the runner-requested scripts/schemas/<schema_ref> before writing that artifact or event. Do not invent a field absent from the closed Schema, rename a result kind, or expose a private working shape.

Select one delivery boundary

For ordinary requests to generate test Cases, test points, or a test document, use delivery_intent=case_document. Case generation does not check real environment URLs, accounts, observer access, control access, test-data availability, or cleanup resources. Logical business roles, permissions, preconditions, data conditions, actions, Oracles, and relative baselines are still semantic inputs.

Use delivery_intent=execution_plan only when the user explicitly asks to select or confirm an execution list. An execution plan is a separate downstream run bound to an immutable case_document_ref containing the exact manifest_digest and bundle_digest. Only this path checks current execution capabilities and dispositions. Do not ask for execution resources or an execution-plan preference during ordinary Case generation.

This Skill creates and, when explicitly requested, confirms an execution plan. It does not automatically start E2E, invoke a browser or API runner, generate automation code, or record execution results.

Gate and freeze input

Try every supplied path, attachment, and inline source. If no requirement content is readable, ask once for accessible source material. If it remains unavailable, end with INPUT_UNAVAILABLE; never create a generic or empty Case document.

Freeze product, module, role, client, version, region, environment, original source set, and material scope. An unspecified dimension remains unspecified. Do not broaden or narrow scope because later analysis discovers more material. New authoritative source bytes or a material scope change requires NEW_RUN_REQUIRED; preserve the old run.

Set output_language to the user's requested zh-CN or en, otherwise use the request language. Preserve source quotations and technical names verbatim. Never fill product truth from generic domain knowledge.

After source review and scope closure, briefly state the business understanding in the conversation: who acts on which object, under which relevant conditions, through which supported actions or links, and with which independently decidable results. Include only dimensions present in this request. This is a readable summary of the existing Fact/View path, not a fifth artifact, an evidence source, or a confirmation gate. Continue automatically when no necessary ambiguity exists; when one does, use the existing clarification phase.

When a business Claim carries compiler-consumed structure inside semantic_value, use only the exact assertion families and closed item shapes documented in references/evidence-policy.md: relative_baseline_assertions, test_value_assertions, test_value_derivations, risk_review_assertions, not_applicable_assertions, and ordering_assertions. Do not place execution readiness or a self-authored compiler ID in these fields.

Run the private workflow

Resolve <skill-dir> to this Skill directory. Create a persistent private run directory owned by the current task, outside the Skill installation and outside OS temporary storage. Its canonical absolute path is durable run identity; a spelling containing .. that resolves to it is the same canonical run.

Maintain run-catalog.json only as the private relationship index described by references/run-management.md. Accepted semantic repairs use its append-only artifact_repairs procedure; neither structure is a fifth Agent-writable artifact or an authority over the runner checkpoint.

For context recovery, resume the same run directory and invoke the runner first. Do not infer state from conversation history, filenames, a stale checkpoint, or an old current manifest. Invoke exactly:

node <skill-dir>/scripts/test-compiler.mjs <absolute-run-directory>

The runner receives one absolute run-directory argument and stdout contains one JSON reply. Validate it against scripts/schemas/reply.schema.json before inspecting status or writing anything. Unknown status/stage, a stage/schema mismatch, malformed JSON, extra reply fields, or unverifiable recovery bindings is PIPELINE_PROTOCOL_ERROR; write no artifact. stderr is diagnostics only.

Import the private installed Adapter helpers createV4RunDirectory, constructV4Action, constructIndependentReviewCompletionV4, stageV4PrdCollectionObservation, and stageV4SourceAcquisitionAction from <skill-dir>/scripts/test-compiler.mjs. Create each Case Document or Execution Plan sibling with createV4RunDirectory(<catalog-root>, delivery_intent) so the compiler issues the run ID and canonical runs/<run-id> directory together; never mint a run ID or move an established run directory. Before submitting a displayed action, pass the validated reply plus only the user's semantic answer or choice to constructV4Action, then append exactly the returned event to the next Source Pack revision. Never mint or compute an event ID, digest, presentation binding, request binding, or other protocol ID. A stale or unadvertised action is a protocol error; do not hand-build a substitute event.

For a new Case Document, first invoke the runner to obtain its source_pack request. Enumerate and actually inspect the declared PRD body, tables, images, visible comments, replies, and resolved threads as required by references/evidence-policy.md. Call stageV4PrdCollectionObservation with that validated reply, the closed technical observation, and the exact in-memory raw/capture bytes; then stage the reviewed four-artifact source_pack. The helper persists safe digests and collection status only. Its technical record is not a fifth semantic artifact and cannot prove or introduce a business fact.

Follow this order:

source acquisition and canonical capture
-> source review, atomic Facts, topology review, and scope manifest
-> pre-case clarification
-> sparse Behavior Views with design assurance, business outcomes, formal Test Points, and Case Drafts
-> post-case clarification for newly discovered semantic gaps only
-> source-first independent review inside the same Case Draft stage
-> canonical Case Document delivery
-> optional explicit Execution Plan bound to that immutable Case Document

The pre-case clarification occurs after source review, atomic fact extraction, and scope manifest closure, but before Behavior Views and Cases. The post-case clarification occurs only after Case design reveals a genuinely new semantic gap. In both phases, present one business-readable batch.

For a partial answer, submit only reliably bound answered parts. Unanswered parts remain presented and pending; blank, unparseable, or not reliably bound text writes no answer and cannot suppress an item or advance its revision. Only an explicit defer_question_part or mark_question_unknown changes that part to deferred or unknown. request_delivery closes only the explicitly referenced parts for delivery.

Handle runner replies

Every user-visible stop path must state: current state, produced artifacts, incomplete reason, concrete next actions, and recovery. Use only actions returned by the validated reply.

Handle need_artifact

Report current state, produced artifacts, why source acquisition is incomplete, the advertised provide_artifact/cancel_run next actions, and the exact resume_ref recovery. Never retain a signed retrieval URL. Collect the complete batch named by artifact_requests, review the safe canonical Source Pack, and call stageV4SourceAcquisitionAction with the validated reply, that Source Pack, each request's safe input, and its exact material bytes; then call the runner again. The helper derives all events and computed Source fields and atomically stages only the safe resumed Source Pack plus short-lived material. need_artifact is reserved for this complete source-acquisition recovery contract.

Handle need_user_answers

Report current state, produced artifacts, why the run needs decisions, available actions, and recovery from the committed checkpoint. Present compiler questions in business language: concrete question, why_needed, decision_impact, unresolved_outcome, affected business items, and named risk counts. Keep root, Fact, Claim, obligation, digest, and other protocol IDs hidden in the submission context.

For semantic clarification, allow only answer_question_part, defer_question_part, mark_question_unknown, request_delivery, and cancel_run when advertised. For an explicitly requested execution plan, execution closure uses only provide_capability_proof, set_execution_disposition, pause_execution, reopen_semantic_question, and cancel_run when advertised. Copy all presentation, version, item, run, and checkpoint bindings exactly; do not compute IDs.

Handle need_revision

Report current state, accepted artifacts, exact validation reason, the artifact/action that can be corrected next, and recovery from the last committed checkpoint. Repair an unaccepted staging artifact at the same revision. Repair an accepted semantic artifact only through the digest-bound append procedure in run-management.md; never edit accepted, derived, or output bytes.

When incomplete_reason.code is STAGE_ARTIFACT_REQUIRED, open the named Schema and matching policy, write only its fixed staging file, and call the runner again:

• source_pack -> staging/source-pack.json
• evidence_claims -> staging/evidence-claims.json
• behavior_views -> staging/behavior-views.json
• case_drafts -> staging/case-drafts.json

Any other Agent-writable stage is PIPELINE_PROTOCOL_ERROR. Never invent a fifth artifact.

For a 4.3 case_drafts reply with INDEPENDENT_REVIEW_REQUIRED and a review_request, do not create another artifact or stage. Read the declared source-first targets before the generated projection, adjudicate every target and finding from exact Claim/Decision support, and call constructIndependentReviewCompletionV4(validatedReply, {target_assessments, findings}). Replace only the unaccepted staging case_drafts.independent_review with that returned closed object while repeating the same generated content. The helper copies target IDs and review_target_digest; never guess either. A changed Fact, View, formal Test Point, responsibility, Case precondition, data condition, step, or Oracle requires a new compiler-issued review request. Review prose alone does not create a new target digest.

Allow three repair attempts for the same normalized stage and root cause. The fourth identical no-progress result is PIPELINE_NO_PROGRESS, not a compiler fatal or business Blocked item. Reset the counter only on material stage or cause change.

Handle finished

Re-read output/current.json, treat it as the only authoritative manifest, and validate every referenced file and digest before reporting success. Report current state, canonical result kind, produced files/counts, any retained gaps or execution exclusion reason, next available action, and exact recovery run reference.

For a 4.2 or 4.3 Case Document, validate output/current.json entries for canonical JSON, test-cases.html, case-table.txt, CSV, Markdown, and source-reading.json. For 4.3 also verify that the manifest review digest matches canonical JSON. Open test-cases.html as the primary readable artifact. Send the CommonMark Table from case-table.txt in canonical ordered_case_ids order and展示全部 Case 的全量 Table; every generated Case appears exactly once, and a long table is continued in ordered segments without ellipsis or sampling. Its required header is 序号 | 模块 | 用例/流程名称 | 预期结果 | 优先级 | 依据状态. Display all step-bound Oracles in their deterministic observation order rather than summarizing only the last result.

JSON, HTML, CSV, Markdown, and the full Table are projections of the same canonical Case bundle; source-reading.json is separately projected from the bound technical collection record. Markdown remains a compatibility file and begins with a one-scenario-per-line overview showing module, priority, title, and status. Coverage is labelled “已审阅 formal test-point 覆盖” and separately names semantic gap, Exploratory, and NotApplicable counts. Never claim unbounded “100% requirement coverage”. Internal IDs appear only in canonical JSON or an explicitly enabled audit appendix. For a legacy 4.0 task, keep its original manifest and readable artifacts unchanged; do not backfill a false collection-completeness claim.

blocked_only is a delivered unresolved report and must not claim Cases were generated. no_applicable_cases, delivered_cases, and delivered_with_gaps retain their exact meaning. Execution-only execution_ready requires nonempty runner_projection.case_ids; no_execution_selected is not ready. Only Grounded + Execute Cases enter that projection.

Never produce a hand-written official final, alternate Markdown, spreadsheet, or test-case fallback. A fatal or failed canonical gate means no unbound file is an official result.

Handle fatal

Report current state, the last valid produced artifacts, diagnostic reason, safe next action if any, and checkpoint recovery. On fatal, produce no Markdown, spreadsheet, test cases, or other fallback final. Never convert process failure into semantic Blocked.

Handle cancelled

Report current state, produced and preserved prior artifacts, incomplete reason (the cancellation phase/reason), the next action, and recovery. The cancelled run accepts no more appends. cancel_run is valid during source acquisition, semantic clarification, execution closure, and final confirmation; repeat cancellation is idempotent. To resume, call the installed bundle's ordinary createV4RunDirectory helper with { parent_run_id, creation_reason: 'resume_cancelled' } as its second argument; the compiler derives the original delivery intent and issues the sibling ID. Never append to the cancelled run, mint its ID, or choose a different intent.

Preserve truth and delivery integrity

• Keep evidence status separate from execution disposition. DoNotExecute never means NotApplicable and cannot upgrade evidence or alter an Oracle.
• Keep one independently diagnosable primary business outcome per Case. Every Oracle binds an existing step with observe_after_step_id.
• Never fabricate a Behavior View field, business rule, ordering dependency, observer, execution resource, or Schema field. Multiple unrelated atomic Claims must not share a whole-document locator.
• request_delivery may close selected semantic gaps for delivery; it never fabricates answers, deletes formal Test Points, or makes an execution plan ready.
• In 4.3, request_delivery, ordinary confirmation, E1 input, defer, unknown, or resolved_temporary never resolves a critical acceptance-impact root. Formal delivery requires the compiler's final-resolution basis.
• JSON is normative. HTML, the full conversation Table, Markdown, and CSV are mechanical views of the same canonical result, never independently edited.
• Execution results and defect records belong downstream and bind the delivered bundle digest plus Case ID; they are never written into the canonical Case Document.