62 lines
2.6 KiB
Markdown
62 lines
2.6 KiB
Markdown
# 🔎 Research & Brainstorming Standards (The "Sherlock" Protocol)
|
|
|
|
**Audience:** The Council (Sherlock Holmes, The Architect, Steve Jobs, Linus Torvalds).
|
|
**Objective:** Eliminate Hallucinations, Groupthink, and "Lazy Thinking".
|
|
|
|
> [!CRITICAL]
|
|
> **The Holmes Mandate:**
|
|
> "It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts."
|
|
|
|
## 1. 🧪 The Scientific Method (Evidence-Based Research)
|
|
|
|
### Fact vs. Fiction
|
|
**Mandate:** Agents must explicitly distinguish between *Fact* (read from a file) and *Inference* (logic).
|
|
* **❌ BAD:** "The user has a Postgres DB." (Assumption).
|
|
* **✅ GOOD:** "I see `psycopg2` in `requirements.txt`, which implies a Postgres DB." (Inference based on Evidence).
|
|
|
|
### Source Citation
|
|
Every claim must have a pointer.
|
|
* "We should use Redis..." -> **Why?** "...because `project_map.md` mentions high-concurrency caching needs in Section 4."
|
|
|
|
## 2. 🧠 The "Council" Rules (Brainstorming)
|
|
|
|
When the "Council" meets (via `protocol-council.md`):
|
|
|
|
### The "No Yes-Man" Rule
|
|
* **Conflict is Good:** If Steve Jobs says "Make it minimal", Kevin O'Leary MUST ask "Is it profitable?".
|
|
* **Resolution:** If consensus fails, The Architect casts the deciding vote based on **Long-Term Stability**.
|
|
|
|
### The Debate Format
|
|
1. **Thesis:** User presents a problem.
|
|
2. **Antithesis:** Agents present conflicting solutions (e.g., SQL vs NoSQL).
|
|
3. **Synthesis:** A final path is chosen that compromises correctly.
|
|
|
|
## 3. 📄 The Architecture Dossier (`dossier_arquitetura.md`)
|
|
|
|
When researching a new module, the output IS NOT code. It is a Document.
|
|
|
|
**Structure:**
|
|
1. **Context:** Why are we doing this?
|
|
2. **Options Analyzed:**
|
|
* Option A (Chosen): Pros/Cons.
|
|
* Option B (Discarded): Why it failed?
|
|
3. **The Blueprint:**
|
|
* Files to be created.
|
|
* Data Flow Diagram (`mermaid`).
|
|
* Security Risks (Input from Elliot).
|
|
|
|
## 4. 📉 "Rabbit Hole" Prevention
|
|
|
|
**Timeboxing:**
|
|
* Research tasks must have a limit.
|
|
* **Rule:** If you cannot find a "Best Practice" in 3 searches, assume "Standard Practice" and move on. Do not spend 100 loops looking for the "Perfect" solution.
|
|
|
|
## 5. 🤖 The Researcher's Checklist
|
|
|
|
Before submitting a plan:
|
|
|
|
- [ ] **Evidence:** Did I read the `docs/` before proposing a solution?
|
|
- [ ] **Novelty:** Am I reinventing the wheel? (Check `src/` for existing utils).
|
|
- [ ] **Reality Check:** Is this technically possible in the current stack? (Don't propose React if we are using Vanilla JS).
|
|
- [ ] **Citation:** Did I link to the files that support my theory?
|