git:20260825.81319f4 to git:20260925.778348a

---

name: craft-discipline

description: Use when a change looks finished and is about to be committed, or a phase has just turned green — the self-check the software-engineer runs before claiming the work is done. Not a review contract. The reviewer verifies artifacts independently.

---

# Craft Discipline

## Overview

10 self-discipline checkpoints for the `software-engineer`.

Run at every COMMIT & VERIFY phase, before committing.

**What this skill is NOT:** a review contract. The reviewer does not read

this skill. It audits artifacts independently through its own gates.

## Checkpoints

Execute in order. Each checkpoint must pass before proceeding.

### C1 — Acceptance test passes

```bash

dotnet test --filter "Category=Acceptance"

```

The acceptance test targeted by this iteration MUST pass. No `[Skip]`.

### C2 — All unit tests pass

```bash

dotnet test

```

Zero red tests. Zero ignored tests.

### C3 — Build passes

```bash

dotnet build

```

All projects compile without warnings. Treat warnings as errors.

### C4 — Static analysis passes

Verify that the linter/analyzer reports no new findings.

### C5 — No skipped tests or placeholder assertions

No `[Skip]`, `[Ignore]`, `#if false`, disabling comments,

or placeholder assertions in test bodies

(`assert.fail()` / `Assert.Fail()` / `Assert.True(false, ...)` /

`throw new NotImplementedException()` / `throw new Error('not implemented')`).

Skipped tests and placeholder assertions are both theater —

they pass the compile gate but assert nothing.

### C6 — No mocks in Domain/Application

Check UnitTest files:

- No `A.Fake<>()`, `Mock<>()`, `Substitute.For<>()`

on a Domain or Application type.

- Mocks allowed ONLY on driven ports (repositories, gateways).

### C7 — Business language verified

Test names, variables, and assertions use business vocabulary

(see the project's FR→EN lexicon). No `test1`, `data`, `ProcessData`.

### C8 — mutation score meets the bar

**S7 DETERMINISTIC TOOL BRIDGE — execute via terminal, not prose.**

1. Resolve the stack's adapter (`resolving-stack-commands`) and run its mutation

scripts in order — core first, then boundary. Each script carries the threshold for

its scope and returns the verdict as an exit code; `skraft-quality-bar` states the

values. Never hand-assemble the runner invocation here.

2. Parse output — extract survivors.

3. For real survivors → write boundary test → re-run scoped.

4. For equivalent mutants → document in code comment.

Zero surviving mutants in Domain and Application (equivalent mutants documented if accepted).

Load the [`mutation-testing`](../mutation-testing/SKILL.md) skill for full workflow.

### C9 — Conventional commit format

### C10 — Object Calisthenics on Domain

Verify the 9 rules (see [references/object-calisthenics.md](references/object-calisthenics.md)).

Applicable to Domain code only.

### C11 — Parametrize Variations

Multiple input variants for the same behavior MUST be a single parameterized test

(`[Theory]/[InlineData]` in .NET, `@ParameterizedTest` in Java, `pytest.mark.parametrize` in Python),

not duplicated test methods. One test method per behavior, one row per case.

## When to Execute

| TDD Phase | Applicable Checkpoints |

|-----------|------------------------|

| PREPARE | None |

| RED | None |

| SYNTHESIZE-GREEN | C3 only (build) |

| COMMIT & VERIFY | **All (C1-C11)** |

## On Failure

- Red checkpoint → fix BEFORE committing.

- No exceptions, no `--ignore`.

- After 3 attempts on the same checkpoint: revert to green + escalate.

## References

- [Test Theater Patterns](references/test-theater-patterns.md)

- [Object Calisthenics](references/object-calisthenics.md)