agentleFS
jjillijjilli/fable-flow/skills/build-patterns/SKILL.md

build-patterns

Skill2 starsChanged 4 months agoMITView on GitHub

Battle-tested engineering patterns and seam traps distilled from long multi-round fable-flow builds. Consult when planning tracks, implementing a track, or reviewing — especially for the recurring integration failure (tests green per track, broken where tracks or the live runtime meet), the reusable patterns that make later rounds cheaper (provider-adapter, enqueue-only worker, guarded migration, invariant validators), and the verification discipline that a green test suite alone does not give you.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Contract expansion is additive: When a wire/dict/DB shape gains a field, exact-equality tests (set(obj) == KEYS) will break by design.

    line 59
  2. Very specific:

    Before reporting a missing test, grep for the *symbol under test* across all test files, not just for a <Name>.test file — coverage …

    line 84
  3. Distinctive:

    Don't trust a capability claim from a comment or a track report.

    line 87

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Build patterns & seam traps

Field notes from running this pipeline across many rounds of one codebase. The fable-prompting skill covers how to prompt; this covers what tends to break and what tends to work when the plan turns into code. None of this overrides the plan's Contracts — it's the judgment to apply within them.

The core failure mode: green per track, broken at the seam

The single most common real bug that survives per-track testing lives where a track meets something its own unit tests don't exercise: another track's code, or the live runtime. A round can show every track's suite green and still be broken. Prove each round with one real end-to-end run through the actual runtime path, not only the unit suite. Seams unit tests routinely miss:

  • Background threads, queues, event loops. The pure function is tested; the wiring that feeds it from the drain thread / worker / async loop is not. Test the dispatch, not just the callee.
  • Non-HTTP request scopes. A gate built on an HTTP-only base (e.g. Starlette BaseHTTPMiddleware) silently skips WebSocket and other scopes — an auth or rate-limit middleware that looks complete can leave the live event socket wide open. Test the socket/stream path explicitly, not just GET /.
  • Real timing and sampling. A loop gated by wall-clock fps/interval behaves differently under a tight test loop than in production. Make the seam deterministic (inject the clock, feed a fixed frame/event sequence) so the test actually pins the wiring instead of passing by luck.

The architect should name the round's riskiest seam and require a concrete end-to-end check of it; the integration reviewer should assume the seam is the bug until a real run says otherwise.

Reusable patterns (each earned, each made later rounds cheaper)

  • Provider-adapter, never-raises. For any optional capability (an AI model, an external service, a hardware backend): a make_X(config) factory that NEVER raises when the optional dependency is absent, a single typed error that wraps every failure mode, a lazy import inside the method, and a zero-dependency default that CI actually exercises. Optional providers degrade to the default; they never crash the pipeline.
  • Enqueue-only worker. Push heavy or optional work (vision, re-identification, matching) onto a bounded-queue daemon thread off the hot path. submit() never blocks and never raises (log-and-drop when full); the stop flag is named so it can't shadow a base-class attribute (_stop_event, not _stop); every failure is logged, never propagated to the caller.
  • Guarded schema migration. CREATE TABLE IF NOT EXISTS never adds a column to a table that already exists. Add new columns at startup with PRAGMA table_info
    • ALTER TABLE ADD COLUMN. When you extend a prune/cascade routine, keep its signature and return type stable so callers and their exact-shape tests don't move.
  • Invariant validators that don't break existing input. A newly-added required-invariant check can reject a config that was valid yesterday. Distinguish an explicit misconfiguration from a defaulted value the user never set (e.g. pydantic model_fields_set): reject the former, clamp/upgrade the latter. Ship compatibility by default, not a startup crash on upgrade.
  • Contract expansion is additive. When a wire/dict/DB shape gains a field, exact-equality tests (set(obj) == KEYS) will break by design. Add the key to the expected set — don't loosen the assertion to >= — and fix the fixtures in the same change. Expect this and budget for it whenever a track widens a shared shape.
  • Record everything, rate-limit the noise. Persist every event/hit; gate the user-facing notification behind a per-source cooldown so a lingering condition can't storm the user. The record is complete; the interruptions are bounded.

Verification discipline (a green suite is necessary, not sufficient)

  • One real roundtrip per round. Drive the feature through the real runtime and show the concrete result: a request is 401 without a token and 200 with it; a matching appearance on a second camera fires exactly one hit; an unreachable stream fails within its timeout rather than hanging. This catches seam bugs the unit suite structurally cannot.
  • Visual check for UI work. Build-clean and tests-green still ship layout regressions — an unconstrained thumbnail, a bar that overflows its track. A headless-browser screenshot against seeded data is cheap and catches what assertions miss. Worth doing for any user-facing surface.
  • Deterministic tests for time/IO seams. Fake the clock, the capture, the socket. A test that depends on wall-clock timing or real network is flaky, and a flaky seam test is worse than none because it trains everyone to ignore it.

Reviewer traps (don't manufacture false positives)

  • Before reporting a missing test, grep for the symbol under test across all test files, not just for a <Name>.test file — coverage frequently lives in a sibling. A confidently-wrong "no coverage" finding costs the pipeline a round.
  • Don't trust a capability claim from a comment or a track report; verify the behavior on the actual runtime before building a finding on it.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.