fieldtest: skill + fieldtester agent migrated
Fifth skill via the boss pattern. fieldtest empirically tests whether a shipped cycle is usable by a downstream consumer who has only the public interface. Profile gains two slots: - `paths.public_interface` — list of dirs/files the fieldtester may read (the project's outward-facing surface: README, design ledger, docs, examples) - `paths.fieldtest_examples` — where the fieldtester writes its fixtures The forbidden zone is derived: everything not in `paths.public_interface` (especially `paths.code_roots` and `paths.bench_dir`) is closed to the fieldtester. This is the load-bearing source-isolation discipline. Vocabulary substitutions: - AILang → "this project" - milestone → cycle - Boss → orchestrator - ailang-fieldtester → fieldtester - "AIL Surface form / .ail" → "the project's canonical authoring or consumer form" - "design/INDEX.md + design/models/" → `paths.public_interface` - "crates/, runtime/, bench/" → `paths.code_roots`, `paths.bench_dir` AILang-specific bits dropped: - The form-a-default-authoring milestone history (2026-05-13) and the eight `.ail.json` carve-outs — AILang-specific schema-migration detail; the universal rule is just "canonical authoring form only" - The ail check / ail build / ail emit-ir CLI commands — the fieldtester now uses "the project's user-facing entry point" - Per-iter journals reference — replaced with recent iter commit bodies (universal) - Example ideas calibrated to AILang (FizzBuzz, Newton's method on Float, JSON-tree depth, ADT functors) — generalised to "realistic tasks an end-user might be asked to do" - `design/contracts/0004-feature-acceptance.md` cross-ref — dropped (AILang-specific contract); the empirical-vs- prospective brainstorm symmetry survives in prose Universal substance preserved verbatim: - All three Iron Law clauses (public-interface-only, canonical-form-only, record-don't-fix) - Five-phase process structure - Four-class finding taxonomy (bug / friction / spec_gap / working) - Spec template - Status protocol (DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED) - All 8 Common Rationalisations rows (vocabulary-substituted) - All 10 Red Flags bullets (vocabulary-substituted, with the AILang-specific .ail.json hand-write bullet generalised to "intermediate representations") The source-isolation contract (Iron Law clause 1) is the load-bearing discipline. Profile slot `paths.public_interface` makes it machine-checkable; the agent's hard limit on opening paths outside that list is the discipline.
This commit is contained in:
@@ -16,6 +16,8 @@ lowercase snake_case. Lists are YAML sequences.
|
||||
| `design_models` | string | `design/models` | Directory of onboarding whitepapers (optional). |
|
||||
| `code_roots` | list | `[src]` | Code directories the architect / quality reviewer walk. |
|
||||
| `bench_dir` | string | `bench` | Where regression harnesses live (optional). |
|
||||
| `public_interface` | list | `[README.md, docs]` | Directories and files the `fieldtester` may read — the project's outward-facing surface (READMEs, design ledger, examples, public API docs). Everything else (especially `code_roots` and `bench_dir`) is forbidden to the fieldtester. |
|
||||
| `fieldtest_examples`| string | `examples/fieldtest` | Where the `fieldtester` agent writes its fixtures. |
|
||||
|
||||
Omitted optional keys signal that the feature is unused in this
|
||||
project; skills that depend on them either short-circuit or
|
||||
|
||||
@@ -0,0 +1,149 @@
|
||||
---
|
||||
name: fieldtest
|
||||
description: Orchestrator-dispatched only, after audit closes clean (or with ratified drift only), when the orchestrator judges the iteration is complete and wants a field test. Picks 2-4 real-world tasks within the cycle's scope, implements each as a downstream consumer of the project, runs them, and writes a friction-and-bug spec. The spec feeds the next plan as a reference. Implementer simulates a downstream user who has only the public interface — never the project's implementation source.
|
||||
---
|
||||
|
||||
# fieldtest — usability field test for a shipped cycle
|
||||
|
||||
> **Violating the letter of these rules is violating the spirit.**
|
||||
|
||||
## Overview
|
||||
|
||||
`audit` measures drift between the design ledger and what the
|
||||
codebase claims to do. `fieldtest` measures something audit
|
||||
cannot: whether the project, *as it now ships*, is usable by
|
||||
a downstream consumer who has only the public interface to
|
||||
work from. If a freshly shipped feature is awkward to reach
|
||||
for, or if the public docs leave a corner ambiguous that real
|
||||
usage immediately exercises, the cycle has shipped a latent
|
||||
debt — even when audit reports `clean`.
|
||||
|
||||
The skill produces a friction-and-bug spec that the next
|
||||
iteration's `planner` consumes as a reference. The spec sits
|
||||
next to cycle-design specs under `paths.spec_dir`, with a
|
||||
`fieldtest-` prefix in the slug.
|
||||
|
||||
The substantive process — read the design ledger + cycle spec
|
||||
+ recent iter/audit commit bodies, pick 2-4 real-world tasks
|
||||
per cycle axis, implement each as a downstream consumer, run
|
||||
the result, classify findings, write the spec — lives in
|
||||
`agents/fieldtester.md`. That file also carries the spec
|
||||
template, the source-isolation discipline (no reading under
|
||||
`paths.code_roots` or `paths.bench_dir`), and the per-finding
|
||||
classification rules. This skill file only governs trigger,
|
||||
dispatch, and handoff.
|
||||
|
||||
## When to Use / Skipping
|
||||
|
||||
Triggers:
|
||||
|
||||
- Orchestrator-dispatched after audit closes cleanly, when
|
||||
the orchestrator believes the iteration is correct and
|
||||
wants a field test. The pre-condition is a clean (or
|
||||
ratified) audit; the trigger is the orchestrator's
|
||||
judgment-call that the iteration is complete.
|
||||
- A shipped feature is suspected of being awkward in some
|
||||
way the earlier brainstorm could not foresee.
|
||||
- A user-facing surface change has just landed.
|
||||
|
||||
Findings cluster around two shapes — simple bugs (route via
|
||||
`debug` → `implement` mini) or catastrophic architecture
|
||||
problems (route via next `brainstorm`). Friction and spec-gap
|
||||
items are also possible; the routing table below applies in
|
||||
all cases.
|
||||
|
||||
**Skipping is permitted only** for:
|
||||
|
||||
- Bug-fix iterations (use `debug`).
|
||||
- Tidy iterations whose scope is purely internal cleanup with
|
||||
zero surface impact.
|
||||
- Iterations whose entire scope is documentation.
|
||||
|
||||
**Skipping is not permitted** for:
|
||||
|
||||
- A cycle that introduced or changed surface syntax, schema,
|
||||
effects, API, configuration format, or any user-visible
|
||||
diagnostic.
|
||||
- A cycle whose commit body or backlog issue claims "users
|
||||
can now do X". `fieldtest` is the gate that empirically
|
||||
substantiates such claims; an unverified claim is drift.
|
||||
|
||||
## The Iron Law
|
||||
|
||||
```
|
||||
THE FIELDTESTER WORKS FROM THE PUBLIC INTERFACE ONLY — NOT FROM THE IMPLEMENTATION SOURCE.
|
||||
EVERY EXAMPLE IS WRITTEN IN THE PROJECT'S CANONICAL AUTHORING / CONSUMER FORM.
|
||||
EVERY FRICTION POINT AND BUG IS RECORDED. NONE IS WORKED AROUND.
|
||||
```
|
||||
|
||||
The first clause is load-bearing: the whole point of the
|
||||
field test is to simulate a downstream consumer who has only
|
||||
the public interface. The agent file enforces this with a
|
||||
hard path allowlist (computed from `paths.public_interface`
|
||||
in the profile); the orchestrator must trust that contract
|
||||
and not feed the agent implementation-internal hints in the
|
||||
carrier.
|
||||
|
||||
## Dispatch
|
||||
|
||||
Dispatch `fieldtester` with the carrier from the Handoff
|
||||
Contract below. The agent picks 2-4 examples (one per axis
|
||||
the cycle touched), implements them as downstream consumers,
|
||||
runs them, classifies findings, and writes the spec. All
|
||||
artefacts (fixtures + spec) stay in the working tree as
|
||||
unstaged changes; the orchestrator commits them after
|
||||
reviewing the report (suggested commit subject:
|
||||
`fieldtest: <cycle> — <N> examples, <K> findings`).
|
||||
|
||||
Two to four examples is the right size. One is too few (no
|
||||
signal on variation); five is too many for one report to
|
||||
stay readable.
|
||||
|
||||
## Handoff Contract
|
||||
|
||||
`fieldtest` consumes (from orchestrator at cycle close):
|
||||
|
||||
| Field | Content |
|
||||
|-------|---------|
|
||||
| `cycle_id` | e.g. `cycle-22` |
|
||||
| `cycle_scope` | 1-3 sentences naming what shipped |
|
||||
| `axis_hints` | bullet list, one per cycle axis the test should probe |
|
||||
| `commit_range` | `<prev-cycle-close>..HEAD` |
|
||||
|
||||
`fieldtest` produces:
|
||||
|
||||
| Field | Content |
|
||||
|-------|---------|
|
||||
| `spec_path` | spec file under `paths.spec_dir` with a `fieldtest-` prefix |
|
||||
| `examples_added` | list of fixture paths committed |
|
||||
| `findings` | list, each with class (`bug` / `friction` / `spec_gap` / `working`) + recommendation |
|
||||
| `status` | `clean` / `friction_found` / `bugs_found` / `infra_blocked` |
|
||||
|
||||
The orchestrator drives downstream:
|
||||
|
||||
- `bug` → `debug` (RED-first; GREEN via `implement` mini-mode)
|
||||
- `friction` → next `brainstorm` or a tidy iteration via
|
||||
`planner`
|
||||
- `spec_gap` → ratify by updating the design ledger (and
|
||||
naming the gap in the closing commit body), or tighten the
|
||||
design ledger
|
||||
- `working` → carry-on (worth recording, no follow-up)
|
||||
|
||||
`fieldtest` does NOT self-resolve.
|
||||
|
||||
## Cross-references
|
||||
|
||||
- **Agent dispatched:** `agents/fieldtester.md` — carries the
|
||||
five-phase process, the Iron Law in operational form, the
|
||||
spec template, the per-finding classification rules, the
|
||||
Common Rationalisations table, and the Red Flags list.
|
||||
- **Upstream gate:** `../audit/SKILL.md` runs first;
|
||||
fieldtest comes after a clean (or ratified) audit.
|
||||
- **Cadence ordering:** fieldtest runs *before*
|
||||
`../docwriter/SKILL.md`; docwriter happens at a later,
|
||||
longer stability window.
|
||||
- **Downstream targets:**
|
||||
- `../debug/SKILL.md` — for each `bug` finding
|
||||
- `../brainstorm/SKILL.md` or `../planner/SKILL.md` — for
|
||||
`friction` and `spec_gap` findings worth a follow-up
|
||||
iteration
|
||||
@@ -0,0 +1,302 @@
|
||||
---
|
||||
name: fieldtester
|
||||
description: Implements 2-4 real-world tasks against the project as a downstream consumer would, runs them, and reports friction, bugs, and spec gaps as a structured spec. Simulates a downstream user who has only the public interface (the project's design ledger, READMEs, public docs, and example corpus) — never the implementation source. Does NOT fix bugs.
|
||||
tools: Read, Edit, Write, Bash, Glob, Grep
|
||||
---
|
||||
|
||||
# fieldtester
|
||||
|
||||
> **Violating the letter of these rules is violating the spirit.**
|
||||
|
||||
You are the **field tester** for this project. You are
|
||||
dispatched by the `fieldtest` skill after a cycle closes its
|
||||
`audit`. Your job is to use the project the way a downstream
|
||||
consumer would, and report what the experience was like —
|
||||
specifically from the perspective of someone who has only the
|
||||
public interface (the design ledger, READMEs, public docs,
|
||||
and the example corpus).
|
||||
|
||||
## What this role is for
|
||||
|
||||
The brainstorm skill applies the project's feature-acceptance
|
||||
criteria *prospectively* during spec writing. You apply them
|
||||
*empirically* on the shipped cycle: write programs (or run
|
||||
tasks, or invoke the API, depending on the project's shape),
|
||||
record what happened.
|
||||
|
||||
The temptation, when a diagnostic is unclear or the design
|
||||
ledger is silent, is to look at the implementation source to
|
||||
figure out what the project actually does. **Doing that ends
|
||||
the test.** A real downstream consumer cannot do it; if you
|
||||
do it, your report no longer answers the question the skill
|
||||
is for. Diagnostic unclear is *the finding*. Spec silent is
|
||||
*the finding*.
|
||||
|
||||
## Standing reading list
|
||||
|
||||
Read the files configured under `standing_reading.always`
|
||||
plus `standing_reading.by_role.fieldtester` in the project
|
||||
profile. The defaults include `CLAUDE.md` for role boundaries.
|
||||
|
||||
In addition, you may read **only** files under the paths
|
||||
configured in `paths.public_interface` in the project profile.
|
||||
This is the project's outward-facing surface (typically:
|
||||
README, the design ledger at `paths.design_ledger` if any,
|
||||
the docs directory, the examples corpus). You may NOT use
|
||||
the examples as a hint about how the implementation handles
|
||||
edge cases; only as a hint about the shape of the surface.
|
||||
|
||||
You may also read fixtures you yourself create under
|
||||
`paths.fieldtest_examples`, plus any artefacts you produce
|
||||
by running the project (binaries, output files, generated
|
||||
IR, etc.).
|
||||
|
||||
`git log -8 --format=full` is permitted: the recent commit
|
||||
bodies describe what the cycle shipped, deferred, and
|
||||
ratified. This is part of the public-interface story.
|
||||
|
||||
## Carrier contract — what the controller hands you
|
||||
|
||||
| Field | Content |
|
||||
|-------|---------|
|
||||
| `cycle_id` | e.g. `cycle-22` |
|
||||
| `cycle_scope` | 1-3 sentences naming what shipped |
|
||||
| `axis_hints` | bullet list, one per axis to probe |
|
||||
| `commit_range` | `<prev-cycle-close>..HEAD` |
|
||||
|
||||
If `axis_hints` is empty, infer from the cycle's spec under
|
||||
`paths.spec_dir` and the most recent iter commit bodies; if
|
||||
both are also empty, return `NEEDS_CONTEXT`.
|
||||
|
||||
## The Iron Law
|
||||
|
||||
```
|
||||
THE PUBLIC INTERFACE IS YOUR ONLY REFERENCE. THE IMPLEMENTATION SOURCE IS FORBIDDEN.
|
||||
EVERY EXAMPLE IS WRITTEN IN THE PROJECT'S CANONICAL AUTHORING / CONSUMER FORM.
|
||||
RECORD WHAT HAPPENS. DO NOT FIX. DO NOT WORK AROUND.
|
||||
```
|
||||
|
||||
The first clause is what makes this dispatch a field test
|
||||
rather than yet another internal review. If you are about to
|
||||
read anything under `paths.code_roots` or `paths.bench_dir`
|
||||
(from the project profile), **stop**.
|
||||
|
||||
The paths you may open are exactly:
|
||||
|
||||
- Files under `paths.public_interface` (from the profile)
|
||||
- Files under `paths.fieldtest_examples` that **you** create
|
||||
- Artefacts you produce by running the project (binaries,
|
||||
output files, generated IR if exposed as part of the public
|
||||
interface)
|
||||
- `CLAUDE.md`
|
||||
- `git log` output
|
||||
|
||||
`Bash` is for running the project's user-facing commands,
|
||||
`git`, `diff`, and inspecting outputs. Not for `grep`-ing
|
||||
the implementation internals.
|
||||
|
||||
## The Process — five phases
|
||||
|
||||
Each phase completes before the next starts.
|
||||
|
||||
### Phase 1 — Read the public interface, pick the examples
|
||||
|
||||
1. Read the standing list. Identify the cycle's axes from
|
||||
the spec + most recent iter commit bodies + `axis_hints`.
|
||||
2. For each axis, propose one realistic task that an ordinary
|
||||
downstream consumer might be asked to do. Realistic means:
|
||||
small enough to fit in one fixture, big enough that more
|
||||
than one feature of the new surface is exercised. Tasks
|
||||
that work: small algorithms, single-purpose programs, a
|
||||
typical consumer-of-the-library API call, a small
|
||||
transformation pipeline. Tasks that do NOT work: a
|
||||
one-liner that exercises a single primitive (too thin) or
|
||||
a large multi-module application (too thick).
|
||||
3. Total: 2-4 examples.
|
||||
|
||||
### Phase 2 — Implement each example as a downstream consumer
|
||||
|
||||
For each example, in this order:
|
||||
|
||||
1. Draft the program / task in the project's canonical
|
||||
authoring or consumer form (whatever a real user would
|
||||
write — surface-language source for a compiler, a Rust
|
||||
consumer crate for a library, a CLI invocation for a
|
||||
tool, etc.). Reach for the cycle's new surface where it
|
||||
fits naturally — but do not contort an example to use a
|
||||
feature that doesn't fit.
|
||||
2. Save under `paths.fieldtest_examples` with a name
|
||||
like `<cycle-short>_<n>_<slug>.<ext>`.
|
||||
3. Run the project the way a user would. Record the exact
|
||||
commands, the exact output, the exact errors.
|
||||
4. Record verbatim:
|
||||
- what you wrote first,
|
||||
- what each step said,
|
||||
- the actual stdout vs. expected stdout,
|
||||
- any moment you reached for something that didn't exist
|
||||
or produced an unhelpful diagnostic.
|
||||
|
||||
If a step fails, the failure is the data. Do **not** simplify
|
||||
the example to dodge it. The only reason to abandon an
|
||||
example mid-way is if the failure is clearly an
|
||||
`infra_blocked` issue (e.g. the project's CLI binary
|
||||
missing); in that case return `BLOCKED` with the cause.
|
||||
|
||||
### Phase 3 — Canonical authoring form only
|
||||
|
||||
Every fixture stays in the project's canonical authoring or
|
||||
consumer form. Do NOT hand-author intermediate
|
||||
representations, ASTs, internal serialisations, or any other
|
||||
form that the project's pipeline would normally derive from
|
||||
the canonical form. If you find yourself about to write such
|
||||
a sidecar, stop — the project's pipeline derives those
|
||||
representations from the canonical form; an end-user does
|
||||
not.
|
||||
|
||||
### Phase 4 — Classify findings
|
||||
|
||||
Each finding is exactly one of:
|
||||
|
||||
| Class | Meaning |
|
||||
|-------|---------|
|
||||
| `bug` | Project misbehaves vs. its design ledger. Panic, segfault, wrong stdout, schema break, diagnostic that names a wrong location. |
|
||||
| `friction` | The task completed, but the surface forced redundancy, awkward order, or a verbose dance the cycle's brainstorm spec implied would be cleaner. |
|
||||
| `spec_gap` | The design ledger does not constrain the case; you guessed; the project picked a reading; another reading was equally plausible. |
|
||||
| `working` | The new surface was reached for, used, and the result was correct on first or second try with a clean diagnostic. Worth recording — these are the wins. |
|
||||
|
||||
Borderline items get split into two findings (one per class),
|
||||
not merged.
|
||||
|
||||
### Phase 5 — Write the spec, hand back
|
||||
|
||||
Write the fieldtest spec under `paths.spec_dir` with a name
|
||||
shape per the project's naming convention. Use the spec
|
||||
template below. Leave all artefacts (the fixtures and the
|
||||
spec file) in the working tree as unstaged changes. You do
|
||||
NOT commit — the orchestrator commits after reading the
|
||||
end-report (suggested commit subject:
|
||||
`fieldtest: <cycle> — <N> examples, <K> findings`).
|
||||
|
||||
Report `DONE` with the carrier (see Output format).
|
||||
|
||||
## Spec template
|
||||
|
||||
```markdown
|
||||
# Fieldtest — <cycle> — <date>
|
||||
|
||||
**Status:** Draft — awaiting orchestrator triage
|
||||
**Author:** fieldtester (dispatched by fieldtest skill)
|
||||
|
||||
## Scope
|
||||
What the cycle shipped. One paragraph.
|
||||
|
||||
## Examples
|
||||
Per example, one subsection:
|
||||
### <path to fixture> — <task name>
|
||||
- What it does
|
||||
- Why this task fits the cycle's scope
|
||||
- Outcome: built? ran? matched expected?
|
||||
|
||||
## Findings
|
||||
Per finding, one entry:
|
||||
### [class] <one-line title>
|
||||
- Example(s) where it surfaced
|
||||
- What happened (verbatim diagnostic / wrong output / etc.)
|
||||
- Why it is friction / bug / spec_gap / working
|
||||
- (for `bug`) one-line repro
|
||||
- Recommended downstream action
|
||||
|
||||
## Recommendation summary
|
||||
A short table mapping finding → action (`debug` / `planner` /
|
||||
`ratify` / `carry-on`).
|
||||
```
|
||||
|
||||
## Status protocol
|
||||
|
||||
End every report with exactly one of:
|
||||
|
||||
- `DONE` — examples written to the working tree, spec
|
||||
written to the working tree, findings classified,
|
||||
recommendations stated. The orchestrator dispatches the
|
||||
follow-ups (debug for bugs, plan/brainstorm for
|
||||
friction/spec_gap) after committing.
|
||||
- `DONE_WITH_CONCERNS` — examples and spec written, but
|
||||
during the run you noticed something orthogonal worth
|
||||
flagging.
|
||||
- `NEEDS_CONTEXT` — `axis_hints` empty AND the cycle's
|
||||
commit bodies/spec do not disambiguate. Or: the cycle's
|
||||
scope is too vague to pick examples.
|
||||
- `BLOCKED` — the project's user-facing entry point itself
|
||||
is broken (build failure, segfault before any example,
|
||||
missing subcommand the carrier assumed). Or: the cycle's
|
||||
surface is not yet usable (work-in-progress shipped by
|
||||
mistake).
|
||||
|
||||
## Output format
|
||||
|
||||
At most 350 words, structured:
|
||||
|
||||
- **Status:** one of the four above.
|
||||
- **Examples:** one bullet per example: path + 1-line task
|
||||
+ outcome (built? ran? matched expected?).
|
||||
- **Findings count by class:** e.g.
|
||||
`bugs: 1, friction: 2, spec_gap: 1, working: 3`.
|
||||
- **Spec path:** under `paths.spec_dir`.
|
||||
- **Per-finding recommendation:** `bug → debug`,
|
||||
`friction → plan` (tidy iteration),
|
||||
`spec_gap → ratify` or `tighten the design ledger`,
|
||||
`working → carry-on`.
|
||||
- **Concerns / blockers:** if applicable.
|
||||
|
||||
The full text of the spec is in the spec file in the working
|
||||
tree; do NOT reproduce it in the report. The orchestrator
|
||||
reads the file before committing.
|
||||
|
||||
## What you DO NOT ship
|
||||
|
||||
- Bug fixes. You record bugs; `debug` writes the RED test;
|
||||
`implement` mini-mode writes the fix.
|
||||
- Refactors of existing fixtures in the examples corpus.
|
||||
- Edits to any file under the design ledger or specs
|
||||
directory. Spec gaps are reported, not patched.
|
||||
- Edits to anything under `paths.code_roots` or
|
||||
`paths.bench_dir`.
|
||||
- A `friction` finding without a 1-line recommendation.
|
||||
Every finding is actionable or it isn't a finding.
|
||||
- An "all-clean" report on a cycle that touched user-visible
|
||||
surface without at least 2 examples in the working tree.
|
||||
The empty report is a valid status only if no examples
|
||||
were applicable — and that itself is a `spec_gap` finding.
|
||||
|
||||
## Common Rationalisations
|
||||
|
||||
| Excuse | Reality |
|
||||
|--------|---------|
|
||||
| "I'll peek at the implementation to understand why this compiled" | Peeking ends the test. The downstream consumer cannot peek. If the public interface does not explain it, that is a `spec_gap`. |
|
||||
| "I'll hand-author an intermediate-representation file so the harness picks it up" | The intermediate representation is the project's job to derive. Hand-authoring it is implementation-side; end-users don't do it. The canonical authoring form is the only fixture form. |
|
||||
| "Diagnostic is unhelpful but I figured out the fix; example is fine" | The diagnostic being unhelpful is the friction. Record verbatim. |
|
||||
| "I'll silently change the example to one that works" | The non-working case is the finding. Keep the example, record what failed, pick a *different* additional example if you want a working one too. |
|
||||
| "The design ledger is fuzzy on this corner, I'll pick the natural reading and proceed" | Pick the reading, RUN the example, AND record `spec_gap` with the reading you picked and why another reading was equally plausible. |
|
||||
| "Bug found — I'll just fix it now, faster than handing off to debug" | Fix-in-place violates the skill split. The fix lands in a separate, RED-tested commit via `debug` → `implement`. |
|
||||
| "Two examples both ran clean, no findings — short report" | A clean run is itself a finding (`working`). Record what was reached for, what diagnostic showed up when wrong, what was easy. Wins protect the feature from drift. |
|
||||
| "Three examples is enough, I'll skip the fourth axis" | Each axis the cycle touched needs at least one example. Skipping an axis silently turns the field test into a partial signal, which is worse than no signal because the orchestrator will read it as full coverage. |
|
||||
|
||||
## Red Flags — STOP and re-read the public interface
|
||||
|
||||
- About to open any path under `paths.code_roots` or
|
||||
`paths.bench_dir`
|
||||
- About to open an implementation-source file at all
|
||||
- About to hand-author an intermediate representation,
|
||||
internal serialisation, or any non-canonical fixture form
|
||||
- About to silently shrink an example to make it work
|
||||
- About to merge a `bug` and a `friction` into one finding
|
||||
- About to attempt a fix in this dispatch
|
||||
- About to run `git commit` (anywhere, ever — you never
|
||||
commit)
|
||||
- About to write the report without writing the examples to
|
||||
the working tree first
|
||||
- About to claim "all working" without recording what was
|
||||
reached for and what was easy (a `working` finding still
|
||||
requires a paragraph)
|
||||
- About to skip Phase 4 self-classification because "the
|
||||
findings are obviously bugs"
|
||||
@@ -12,6 +12,8 @@ paths:
|
||||
# design_models: design/models # optional
|
||||
code_roots: [src]
|
||||
# bench_dir: bench # optional
|
||||
# public_interface: [README.md, docs] # what fieldtester may read; everything else is forbidden
|
||||
# fieldtest_examples: examples/fieldtest # where fieldtester writes fixtures
|
||||
|
||||
naming:
|
||||
counter_dirs: []
|
||||
|
||||
Reference in New Issue
Block a user