Groundwork Dev Log 2: Closing the Gaps the Tamagotchi Found

In the first Groundwork dev log I pointed the plugin's requirements workflow at a desktop tamagotchi and let it run. Then I wrote down everything the output was missing. That list of complaints wasn't really a review — it was a backlog. This post is what happened after I built it.

Same pet. Same starting prompt. Here's the before and after.

The scoreboard

Every gap I flagged in the first post, and where it stands now:

Seven for seven. But the last row is the one that actually matters, so I'll come back to it.

What I built

The gaps sorted themselves into a handful of pieces, which became the M1 milestone:

• A real interview. The clarify step now drives past what to the business why (5-Whys), asks numbered-option questions instead of open-ended ones where it can, and runs a silent sweep over the categories LLMs habitually skip — error paths, compliance, data retention, accessibility, operations, legal, and roles beyond "the user." It's a gap check, not an interrogation: it only raises what's non-obvious and high-stakes.
• Specialist authors. Functional requirements come out of an agent that only knows EARS and Gherkin. Non-functional requirements come out of one that walks all nine ISO 25010 quality characteristics and writes each as a six-part scenario with a measurable response. Constraints and business rules get their own author, kept distinct from NFRs.
• A content linter. A deterministic pass that flags vague qualifiers ("fast", "robust"), compound requirements (and/or gluing two behaviors together), EARS non-conformance, passive voice that hides the actor, and implementation bias leaking into high-tier requirements. It's advisory — it feeds the critic and the human, it doesn't silently rewrite.
• Externalized assumptions. The one that the research called the highest-leverage anti-hallucination move: a dedicated section where the model has to write down what it's assuming, what it depends on, and what it still doesn't know — instead of quietly baking guesses into requirement text.
• Confidence triage. Every requirement carries a confidence level. Anything resting on an open question or an unconfirmed assumption is marked low and collected into a review queue, so the human gate is review the five uncertain things, not re-read all twenty-two.

The re-run

Same tamagotchi. The pipeline produced 22 atomic requirements — 10 functional, 7 non-functional, 3 constraints, 2 business rules — plus the assumptions file and a machine index.

Two gates ran over the result:

• The structural validator: 22/22 files pass. Schema-clean, IDs unique, EARS pattern present on every FR, no dangling traces, assumptions file present with its three sections.
• The content linter: zero findings. No vague qualifiers, no compound requirements, no passive-nameless subjects.

The first run gave me a page of bullets. This one gives me a validated, traceable set I could hand to an architect.

The moment that made it worth it

Here's the thing that actually sold me on the whole exercise.

In the original build, the plugin waved me toward Electron, I took it, and I later ripped it out for Tauri because the footprint was wrong for an always-on desktop pet. That switch cost real time. The requirements never flagged it — footprint just wasn't a thing the process thought about.

This time, the footprint question is impossible to miss. It shows up in three places, all pointing at the same decision.

NFR-002 turns it into a testable budget, written as a quality-attribute scenario:

CON-001 records the same thing as a hard boundary. And Q-4 in the assumptions file states the actual decision out loud:

Q-4: Which framework/runtime is chosen given the footprint constraint (Electron vs Tauri vs native)? (owner: engineering)

Because NFR-002 and CON-001 are both low-confidence, they land in the review queue with their reasons attached — alongside three other items whose uncertainty traces back to a different unanswered question:

review_queue:
  - id: FR-008
    confidence: low
    reason: "rests on open question Q-2 (is death permanent or a configurable soft reset)"
  - id: NFR-002
    confidence: low
    reason: "idle-footprint budget depends on open question Q-4 (framework/runtime choice: Electron vs Tauri vs native)"
  - id: CON-001
    confidence: low
    reason: "runtime footprint boundary rests on open question Q-4 (framework/runtime choice)"
  - id: CON-003
    confidence: low
    reason: "cross-platform delivery scope rests on open question Q-3 (which platforms ship in v1)"
  - id: BR-001
    confidence: low
    reason: "death/reset policy rests on open question Q-2 (death permanence)"

The workflow doesn't pretend to know the answer. It states the requirement, admits the uncertainty, and puts the framework decision in front of me before anyone writes code. That's exactly the decision I got wrong the first time by not making it a decision at all.

A look at the artifacts

The previously-missing error path is now a first-class requirement, and it's a nice showcase of the EARS "unwanted" pattern plus Gherkin acceptance criteria — including the negative scenario that the first run never thought to write:

AC-2 — Corrupted save file is quarantined, not loaded
  Given a saved state file whose integrity check fails
  When the application starts
  Then the application starts a new default pet
  And the unreadable file is retained under a quarantine name for diagnostics

The full generated set — all 22 requirements, the assumptions file, and the review queue — is consolidated into a single readable document: CONSOLIDATED.md. The raw atomic files, plus the README on how to re-run the validators, live in docs/requirements/examples/tamagotchi/.

Keeping myself honest

It's still an LLM writing requirements, and I want to be straight about what that means:

• The concrete numbers (the 150 MB budget, the 60-second thresholds) are reasonable placeholders, not gospel. They're testable, which is the point — but a human still has to sign off on the values.
• The low-confidence flags aren't a bug to be driven to zero. Five of twenty-two items are uncertain because the underlying product decisions genuinely aren't made yet. The win is that the uncertainty is labeled and collected instead of hidden.
• A human still gates the set. The whole design is to make that gate cheap — review the five flagged items and the four open questions, not the entire wall of text.

What's next

M1 — the requirements stage — is done. Next up is M2: turning a validated requirement set like this one into an architecture (component decomposition, interface design, ADRs, C4 diagrams) with the same discipline. The tamagotchi will be the guinea pig again.