Module acceptance 

speccoder.task.acceptance: derive acceptance tests from the spec before an attempt.

A judge-side call: no tools, no say in the verdict, and the implementing model never sees it as its own work. speccoder validates what comes back, writes it as new (hence frozen) test files, and requires red before and green after the attempt.

Structs

Acceptance

The coded skill.

ReproduceParts

What a bug’s reproduction (or held-out) author is given. The statements and the person’s rejections are the person’s; the file list is the worktree’s; an issue’s text is untrusted. Every part is listed in the call’s context manifest, journaled with it.

ReviewParts

What a review-time author call is given. The requirement, its scenarios and the person’s notes are the person’s; the file list is the checkout’s.

Constants

CAPABILITY

The capability the skill provides.

Functions

held_out_input

The held-out author’s input: the visible run’s, plus the scenarios, the visible tests (so the held-out ones differ) and whether this task completes its story.

held_out_policy

What the held-out author is told: the visible tests’ scenarios again, with other inputs, for tests the implementer never sees.

held_out_schema

The held-out answer’s schema: per file its scenarios and command.

input

The run input: { bundle, scenarios, project: { files, manifest } }.

policy

What the test author is told.

reproduce_held_out_policy

What the author of a bug’s held-out variants is told: the same statements, other inputs, never shown to whoever fixes it.

reproduce_input

The reproduction author’s input.

reproduce_policy

What the reproduction author is told (a bug): test-blind, one test per statement, red now by an assertion for an Expected statement, green now for an Unchanged one.

reproduce_schema

The reproduction answer’s schema: per file its statement, test name and command.

review_input

The review-time author’s input: { mode: "review", … }.

review_policy

What the test author is told at review: the same author, for one requirement before any task exists, stating per scenario what it asserts so two independent answers can be compared.

review_schema

The review answer’s schema: the run-time answer plus expectations and untestable, both required (contracts/author-schema.md).

schema

The answer’s schema.

strengthen_input

The input for strengthening a weak set: the visible run’s, plus the tests so far and what got through (described by the judge, never shown to the implementer).

strengthen_policy

What the author is told when the set was too weak: the same task, the tests so far, and the wrong implementations they let through.