Builder Field Manual

I. Your Mission

Create technical infrastructure that embodies the principles. Traceability, transparency, resilience—these aren't just political ideas. They're design requirements. Build systems that make accountability easier and corruption harder.

Everything we build is open source. If it can't survive inspection, it doesn't deserve deployment.

II. Current Infrastructure

What Exists

• Website — Static site at junius.foo (HTML/CSS)
• Matrix Server — Conduit instance for community communication
• Gitea — Self-hosted git for code and content collaboration
• Hosting — Njalla VPS, anonymous registration, crypto-paid

Design Principles

• Self-hosted — No third-party dependencies that could be pressured
• Anonymous-friendly — Contributors don't need to reveal identity
• Resilient — Can be replicated if taken down
• Minimal — Small attack surface, low maintenance burden

III. Contribution Workflow

Getting Access

1. Join the Matrix community and introduce yourself in #builders
2. Request a Gitea account from an admin
3. Fork the relevant repository
4. Make changes, submit pull request
5. Discuss in PR or #builders channel
6. Maintainers review and merge

Repositories

• website — Main site HTML, CSS, content
• playbooks — Field manual content and templates
• evidence — Curated investigation documents
• docs — Project documentation, architecture, guides

Code Standards

• Clear commit messages explaining what and why
• No unnecessary dependencies
• Document what you build
• Test before submitting PR
• Security-conscious defaults

IV. Needed Projects

These are tools that would advance the mission. Build what interests you, or propose something new.

Research Tools

• FOIA tracker — Database for tracking request status across jurisdictions
• Contract scraper — Pull and parse government contract databases
• Network mapper — Visualize connections between officials, companies, lobbyists
• Document analyzer — Extract entities and relationships from uploaded documents

Transparency Tools

• Meeting monitor — Track and archive public meeting agendas and minutes
• Vote tracker — Record how officials vote, make it searchable
• Disclosure parser — Standardize financial disclosure formats for analysis

Infrastructure

• Backup systems — Automated, encrypted, distributed backups
• Monitoring — Uptime and security alerting
• Replication guide — One-command deployment for spinning up mirror infrastructure

Communication

• Anonymous submission system — SecureDrop-style evidence submission
• Newsletter automation — Self-hosted mailing list management
• Translation workflow — Tools for multilingual content management

V. Security Requirements

Everything you build must assume adversarial conditions. Governments and corporations have resources to attack infrastructure that threatens their impunity.

Code Security

• Input validation everywhere—assume malicious input
• No secrets in code or public repos
• Dependencies audited and minimal
• Regular updates for security patches

Operational Security

• Contribute via VPN or Tor
• Use pseudonymous accounts for project work
• Don't link builder identity to personal identity
• Review commits for accidental PII leakage

Infrastructure Security

• SSH key-only authentication
• Firewall defaults to deny
• Automatic security updates where safe
• Logging sufficient for forensics, minimal for privacy
• Documented recovery procedures

VI. Tech Stack

Current preferences—not requirements. Use what works, but justify new dependencies.

Preferred

• Languages — Python, JavaScript, Rust, Go, Bash
• Frontend — Static HTML/CSS, minimal JS, no heavy frameworks
• Backend — SQLite for simple storage, PostgreSQL if needed
• Containers — Docker for services that need isolation
• Hosting — Linux VPS, privacy-respecting providers

Avoid

• Cloud services that require identity verification
• Proprietary dependencies
• Services with US/EU jurisdiction data requests
• Anything that phones home or collects telemetry

VII. Documentation

Undocumented code is technical debt. Undocumented infrastructure is a liability.

• README for every repository explaining purpose, setup, usage
• Inline comments for non-obvious logic
• Architecture docs for system-level decisions
• Runbooks for operational procedures
• If you build it, document it—or someone else can't maintain it

VIII. Coordination

Communication

• #builders — Main channel for technical discussion
• Gitea issues — Bug reports, feature requests, task tracking
• Pull requests — Code review and discussion

Decision Making

Technical decisions are made through rough consensus in #builders. For significant architectural changes, write a brief proposal, share it, and incorporate feedback. No formal governance—just reasoned argument and working code.

Maintainers

Active contributors with merge rights. Earned through consistent, quality contributions. If you keep showing up and shipping good work, you'll be invited.

IX. First Mission

This week, pick one contribution:

• Fix something — Find a bug or improvement in the website, submit a PR
• Document something — Write missing documentation for existing infrastructure
• Propose something — Draft a brief spec for a tool you'd like to build
• Review something — Look at open PRs, provide constructive feedback

Share what you're working on in #builders. Small contributions compound. The infrastructure improves one commit at a time.