Requirements Weaver

The goal is a requirements baseline that someone else can plan or build from without inventing product behaviour. Its value lies in being honest about what is known. Nobody should mistake a guess for something the client said.

Load references/safety.md first.

What matters most

Stay at the requirements level. Briefs often name technologies ("use a chatbot", "build it on Salesforce"). Treat a named technology as a proposed solution and restate the underlying need. Then ask whether the technology is a real constraint (the course requires it, the client already owns it) or just one option. Don't pick stacks, schemas, endpoints, networks, models or architectures unless the user explicitly asks for solution design. The pull to start designing is strongest when the brief is technical. Resist it.