design-test-framework-rounds

Design Test Framework Rounds

Translate verified methods and project tensions into comparable tests that an architect can review, reject, or revise. Do not generate a final scheme, site placement, stylistic imitation, or unsupported dimensions.

Read apply-round-templates.md before creating a test round.

Skill contract: WHEN / IN / DO / STOP / OUT / QA

WHEN

Use this skill when:

• a project state and one or more evidence-backed method cards already exist;
• the user asks for an Apply round, a minimum model, or comparable test frameworks;
• architect feedback requires the organization logic to be rebuilt rather than an old diagram cosmetically revised.

IN

Confirm:

1. current project state and unresolved questions;
2. verified requirements and their locators;
3. method cards and evidence boundaries;
4. architect-authored design direction;
5. permitted outputs, prohibited detail, and review owner.

If a required predecessor is unavailable, label the result reconstruction or comparison, not a continuous update.

DO

1. Separate authority classes. Keep sourced requirements, Agent derivations, architect directions, design assumptions, open questions, and source conflicts distinct. Architect feedback is design direction, not automatically a client requirement or statutory fact.
2. Frame a real difference. Produce two or three frameworks that differ in organizing mechanism, not merely size, color, material, or presentation.
3. Keep dimensions honest. Use relative granularity, adjacency, shared-resource degree, interface hierarchy, time window, and other test variables. Do not invent length, height, level count, module, structural grid, courtyard size, density, floor-area ratio, placement, material, or facade answer.
4. Keep metric definitions separate. Unknown area means area not established; uniform diagram blocks must not imply proportion. Do not claim conservation or closure across incompatible definitions.
5. State assumptions conditionally. An idealized collaboration or operations premise may be used only when the user explicitly authorizes it for this round. Label it DESIGN ASSUMPTION; otherwise retain operational conflicts and open questions.
6. Make each framework falsifiable. Define inputs, mechanism, variables, expected effect, minimum model, test criteria, missing evidence, failure conditions, and human decision points.
7. Compare before recommending. Recommend only the next test order, with reasons. Do not select a final scheme.
8. Record feedback verbatim before translating it. Classify feedback, update assumptions or directions, and rebuild the mechanism if the critique concerns organization logic.
9. Version outputs. Preserve failed baselines as regression evidence. Create a new version unless overwrite is explicitly authorized, then re-read every written artifact.

STOP

Stop at the variable, relationship, or mechanism layer when:

• site, structure, code, operations, cost, or metric definitions are insufficient for deeper judgment;
• the method card is provisional or lacks traceable evidence;
• a framework starts copying a named designer's recognizable form rather than testing a transferable operation;
• the requested conclusion requires professional sign-off, client commitment, or statutory confirmation.

OUT

Deliver, at minimum:

1. framework cards using the 15-field template;
2. a comparison matrix;
3. the recommended test order, not a scheme choice;
4. one bounded minimum-model task card;
5. assumptions, blockers, stop conditions, and named human decisions;
6. a round log that records what changed and why.

Use the project's own output and log directories. Directory names are not part of this protocol.

QA

Before finishing, verify:

• every framework traces to current project evidence and an eligible method card;
• alternatives differ by mechanism;
• unsupported dimensions, forms, and materials are absent;
• diagrams state that they are not plans, area ratios, or final schemes;
• PASS, PARTIAL, and BLOCKED findings identify evidence and missing inputs;
• Agent proposals, design assumptions, and human directions are visibly separate;
• named-person style imitation and project-specific residue are absent;
• the next decision belongs to an identified human reviewer.

Tool and rendering discipline

• Do not assume a particular diagram editor or image renderer exists. Use the host's available tools and preserve an editable source when possible.
• A renderer or vision-tool failure does not prove that the underlying service is unavailable. Report the observed failure, use a bounded alternative, and never replace a required editable diagram with a generative image without authorization.
• Installation success or file creation is not method validation. Re-run a fixed input and compare outcomes against the QA conditions.