.profile/CONTRIBUTING.md

Contributing to the Timmy Foundation

Welcome. This foundation builds sovereign AI for men in crisis. Every contribution matters. Every PR must prove its worth.

---

What "Sovereignty" Means in Practice

Sovereignty is not a slogan. It is a set of rules.

1. No cloud dependency. Everything must run on owned hardware. If a feature requires AWS, GCP, or Azure, it is not sovereign.

2. No telemetry to third parties. We do not phone home. Data stays where the operator decides.

3. The soul is immutable. SOUL.md defines core values. These values are inscribed on-chain. No PR can change them. If you disagree with the soul, you disagree with the foundation.

4. Open by default. Every repo is open. Every decision is documented. Secrecy is the enemy of sovereignty.

5. Local-first. If it does not work offline, it does not work.

---

Filing Issues

1. Go to the relevant repo on Forge.
2. Create a new issue.
3. Be specific. Vague issues get closed.
4. Include:
   • What you expected to happen
   • What actually happened
   • Steps to reproduce
   • Environment details (OS, hardware, model version)
5. Tag the issue appropriately: bug, feature, question, crisis-critical.

Crisis-critical issues (anything affecting the-door or crisis intervention) get priority over everything else. A man in pain cannot wait for a sprint review.

---

Submitting Pull Requests

The Proof-Driven Workflow

This foundation does not run on plans. It runs on proof.

PRs prove work. They do not describe future work.

A PR that says "I will add feature X" gets closed. A PR that says "Here is feature X, here are the logs, here is the proof" gets reviewed.

Step by Step

1. Find or create an issue. No orphan PRs.

2. Branch from main. Name it clearly:

   feature/crisis-flow-update
   fix/door-timeout
   docs/readme-clarity
   

3. Do the work. Write the code. Run the tests.

4. Prove it works. Include in your PR:

   • Logs showing the feature works
   • Screenshots for visual changes
   • Command output for CLI changes
   • Test results for code changes
   • World-state proof for infrastructure changes

5. Submit the PR. In the PR description, include:

   • What the PR does (one sentence)
   • Proof that it works (the evidence)
   • Any risks or tradeoffs
   • Link to the issue it resolves

6. Wait for review. Timmy or Alexander has final merge authority.

What Gets Merged

• PRs with proof get reviewed
• PRs without proof get closed
• PRs that break sovereignty get rejected immediately
• PRs that affect crisis intervention get reviewed first

What Gets Rejected

• Plans without execution
• Features that require cloud dependency
• Anything that sends data to third parties
• Changes to SOUL.md (the soul is immutable)
• PRs without proof

---

Code Standards

• Web/frontend: TypeScript + Tailwind CSS
• Agent logic: Python
• Config: YAML, Markdown
• Typography: Inter for UI, JetBrains Mono for data

---

Crisis-Critical Code

The-door is the front door. It is where men in crisis find help.

Any code that touches the-door or crisis intervention flows must be:

• Tested more rigorously than anything else
• Reviewed by at least two people (human or agent)
• Deployed with rollback capability
• Never broken by other changes

If your PR could break crisis intervention, mark it as crisis-risk and expect extra scrutiny.

---

For AI Agents

You are a worker. You have a role. Follow it.

1. Check your assigned issues.
2. Branch, implement, prove, PR.
3. Logs and output are your proof. Screenshots if visual.
4. Assign PRs to @Timmy for review.
5. Do not merge your own work.

You are not the boss. You are the hands. Timmy is the mind. Alexander is the founder. Respect the hierarchy.

---

Questions

Open an issue. Tag it question. Be specific.

---

Proof, not promises. Sovereignty, not dependency.