- adapt meta-/code-/obs- rules to the local Python benchmark pipeline - replace db-sql-ddl, code-config-env-scope, test-e2e-pytest with pipeline equivalents - add code-python-style, data-determinism, data-naming-units, bench-methodology, build-pipeline-tasks - normalize specs and README typography to ASCII per code-data-formatting - rewrite root CLAUDE.md trigger table; add .cursorrules and .gitignore - specs: pipeline plan and task specs 00-11 - rules: 19 binding rule files adapted for this project - docs: CLAUDE.md rule-trigger table - config: .cursorrules commit convention, .gitignore excluding out/ and .venv/ - docs: rewrite README.md with pipeline diagrams, setup guide, result placeholders - config: requirements.txt for the closed dependency list - datagen: make_lab_config.py writes out/config/lab_config.yaml and .done marker
3.1 KiB
3.1 KiB
Meta / No assumptions
Binding on every interaction. Strictest when the cost of a wrong
guess is high: deleting or regenerating ./out/ artifacts, dropping or
reloading the tribo PostgreSQL database, changing the random seed or
lab_config.yaml, editing specs in ways that invalidate generated data,
git history, anything with data-loss consequences.
Rule
Before producing a plan or change:
- Re-read the user's most recent message. Watch for enumerations ("both", "and also", "in addition to"), explicit purpose statements ("X for A, Y for B"), and distinct entities that sound similar.
- Don't collapse two distinct entities into one. "X for A and Y for B" means two setups, not one.
- If anything is ambiguous after careful re-reading - ask. Don't pick the most likely interpretation and proceed.
- Echo back the parsed interpretation before producing the plan, so a misread is cheap to correct.
When the rule is most strict
Strictness scales with the cost of a wrong guess:
| Domain | Why a wrong assumption is expensive |
|---|---|
Deleting / regenerating ./out/ |
The artifact tree holds hours of generation, conversion, and benchmark work. Regenerating CSV invalidates every downstream format, benchmark result, and report. Confirm which subtree is affected before deleting or overwriting. |
The tribo PostgreSQL database |
Dropping or reloading it discards a long COPY load and invalidates benchmark results derived from it. Confirm before any DROP / TRUNCATE / reload. |
The random seed / lab_config.yaml |
Seed 20260711 and the lab configuration are the root of the whole reproducibility chain. Changing either silently invalidates all generated data, all conversions, all checksums, and all measured results. Never change them as a side effect of another task. |
Editing specs (docs/specs/) |
Specs are the task contract. A "small clarification" that changes volumes, schemas, or file layouts desynchronizes already-generated artifacts. Confirm intent when an edit is more than wording. |
Benchmark results (./out/bench/) |
Measured results cannot be re-derived without re-running the full matrix (hours). Never overwrite results_raw.csv / results_median.csv without confirmation. |
| git history | A wrong rebase/reset/force-push rewrites shared history; recovery is manual and error-prone. (The AI agent never runs git write operations at all - see meta-git-commits.md.) |
For all of the above: the cost of one extra clarifying question is zero; the cost of a wrong assumption is hours-to-days of recovery. Always ask.
Forms a clarifying question takes
- "Confirm: you want X for A AND Y for B (two setups), not just one?"
- "Two readings: (a) ..., (b) ... - which?"
- "What does '' refer to here - (a) ... or (b) ...?"
When the assumption was already wrong
- Acknowledge the misread explicitly. Quote the user's words back.
- Discard the wrong artifact entirely; don't repair piecemeal unless the user asks.
- Restart with the corrected interpretation, echo it first.