FFT-Requirements-Analyst - Anti-Fabrication Requirements Interrogator

Overview

FFT-Requirements-Analyst is FlowForge’s anti-fabrication requirements interrogator. Its singular reason to exist is to ask the questions an architect under reward-gradient pressure will not ask — and to refuse to invent answers the customer has not given.

It is dispatched before any fft-architecture invocation on greenfield features or whenever scope is unclear. It produces a structured 8-artifact handoff packet that downstream architects, project managers, and designers consume as a load-bearing brief. The role boundary is enforced structurally: the analyst uses read-only tools, which means every claim it produces is human-attributable text the controller forwards downstream.

This is FlowForge’s structural answer to the MIT-paper “AI coding produces bad outcomes” problem. The failure is not at implementation. The failure is at requirements. FFT-Requirements-Analyst exists to fix it there.

Capabilities

Outside-in interrogation: question batches ordered strategically to tactically — stakeholders → constraints → NFRs → functional requirements → scope boundaries → acceptance criteria — preventing inside-out fabrication
Six fabrication modes blocked: plausible-API fabrication, acceptance-criteria fabrication, NFR-substitution, scope-smoothing, stakeholder-absence, and tech-stack-anchoring — each prevented by structural discipline
Verbatim customer capture: 00-customer-intent.md contains only the customer’s actual words with attribution; no paraphrase, no analyst interpretation
8-artifact handoff packet: drives content for 00-customer-intent.md, 10-functional-requirements.md, 20-non-functional-requirements.md, 30-scope-boundaries.md, 40-stakeholder-map.md, 50-acceptance-criteria.md, 60-constraints-manifest.md, 70-decision-log-and-risk-register.md
10-question batch protocol: approximately 10 questions per pass with rationale tags identifying which artifact dimension each question serves
Three-criteria stop gate: coverage matrix complete, internal consistency check passes, and customer ratification of the assembled artifact set — all three must hold
Anti-grilling guardrails: recipe pre-fill for known project types, smart NFR defaults with opt-out, adaptive depth (15 q for MVPs, 40 q for regulated), and customer escape valve
Recipe-library integration: landing-page recipe pre-answers common questions; CRUD and CLI recipes in v1.1+
Re-grill append discipline: when a downstream agent finds a gap, the analyst appends to the artifact set with dated attribution — never overwrites

When to Use

Greenfield features: net-new functionality with no prior artifact set — dispatch before fft-architecture plans
Scope-unclear briefs: when the controller cannot summarize the request in two sentences without making decisions the customer did not make
Multi-stakeholder features: when more than one role or persona is implicated and the stakeholder map is unwritten
Re-grill dispatches: when a downstream agent (architect, PM, designer) reports a gap in artifact coverage and needs targeted interrogation on specific dimensions

Do NOT dispatch for trivial bugfixes with a known root cause, mechanical refactors with no scope question, or work where the 8 artifacts already exist and are current.

Example Prompts

"We want to add a team billing dashboard to FlowForge. Before architecture plans anything, interrogate us on what it needs to do, who uses it, what the non-functional constraints are, and what success looks like."

"The architect flagged a gap: fft-architecture couldn't find acceptance criteria for the invoice export feature. Re-grill on the acceptance dimension only — start from the existing artifact set."

"Greenfield: we need a public API for the FlowForge agent catalog. Run the full outside-in interrogation — stakeholders first, then constraints, NFRs, functional requirements, scope boundaries, and acceptance criteria."