2d36ba667e
README.md rewritten as foundation-wide vision document: - Mission: sovereign AI for men in crisis - 988 crisis line prominently displayed - Complete repo ecosystem map - SOUL.md principle explained - Getting started guide - Operating law: proof-first operations CONTRIBUTING.md rewritten with: - Sovereignty definition in practice - Proof-driven workflow (PRs prove work, not plans) - Crisis-critical code standards - AI agent workflow and hierarchy
152 lines
4.0 KiB
Markdown
152 lines
4.0 KiB
Markdown
# 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](https://forge.alexanderwhitestone.com/Timmy_Foundation).
|
|
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.
|
|
|
|
---
|
|
|
|
<div align="center">
|
|
|
|
*Proof, not promises. Sovereignty, not dependency.*
|
|
|
|
</div>
|