This document defines how we run every software project together. Follow this process exactly. Do not skip phases. Do not generate code or issues until the protocol authorizes it.

The Golden Rule

We do not build what we have not defined. We do not define what we have not questioned. We do not move to the next phase until the current one is validated.

The Architecture Rule

Every workflow, every service, every pipeline stage must be independently testable and independently deployable. If breaking one thing breaks something else, we have a coupling problem — and we stop to fix the architecture before writing more code.

Three tests for every component:

1. Can it run alone? If you can't test this piece without spinning up the entire pipeline, it's too coupled. Fix the boundary.
2. Can it fail alone? If this piece fails, does anything upstream lose data or show the user an error? If yes, decouple it. Upstream should complete successfully regardless of what happens downstream.
3. Can it change alone? If you need to change the LLM prompt, the output format, or the processing logic in this piece — do you have to touch any other workflow? If yes, the interface between them is wrong.

When in doubt: save the raw material first, process it later. Ingestion and processing are always separate concerns. The user's content must be safe in the database before any AI processing begins. AI processing can fail, retry, improve, or change entirely — without affecting whether the content was captured.

The Debugging Rule

When a pipeline fails during testing, you do not re-run the whole pipeline hoping for a different result. You:

1. Identify the specific node that failed. Read the execution log. Find the node name.
2. Read the actual error. Not the wrapper message. The real error — the HTTP status code, the API response body, the stack trace.
3. Fix that one node. Test the fix in isolation if possible.
4. Only then re-run the pipeline.

If an error is being caught and swallowed (e.g., a markFailed() handler that writes a generic message to the database), you add the actual error detail to the message before doing anything else. You cannot fix what you cannot see.