centralize guides and rails under mosaic with runtime compatibility links

This commit is contained in:
Jason Woltje
2026-02-17 11:39:52 -06:00
parent a1c2efef1c
commit 4eac2c76e6
85 changed files with 10785 additions and 0 deletions

View File

@@ -0,0 +1,18 @@
## Campsite Rule (MANDATORY)
If you modify a line containing a policy violation, you MUST either:
1. **Fix the violation properly** in the same change, OR
2. **Flag it as a deferred item** with documented rationale
**"It was already there" is NEVER an acceptable justification** for perpetuating a violation in code you touched. Touching it makes it yours.
Examples of violations you must fix when you touch the line:
- `as unknown as Type` double assertions — use type guards instead
- `any` types — narrow to `unknown` with validation or define a proper interface
- Missing error handling — add it if you're modifying the surrounding code
- Suppressed linting rules (`// eslint-disable`) — fix the underlying issue
If the proper fix is too large for the current scope, you MUST:
- Create a TODO comment with issue reference: `// TODO(#123): Replace double assertion with type guard`
- Document the deferral in your PR/commit description
- Never silently carry the violation forward

View File

@@ -0,0 +1,14 @@
## Code Review
After completing code changes, run independent reviews:
```bash
# Code quality review (Codex)
~/.mosaic/rails/codex/codex-code-review.sh --uncommitted
# Security review (Codex)
~/.mosaic/rails/codex/codex-security-review.sh --uncommitted
```
**Fallback:** If Codex is unavailable, use Claude's built-in review skills.
See `~/.mosaic/guides/code-review.md` for the full review checklist.

View File

@@ -0,0 +1,11 @@
## Commits
```
<type>(#issue): Brief description
Detailed explanation if needed.
Fixes #123
```
Types: `feat`, `fix`, `docs`, `test`, `refactor`, `chore`

View File

@@ -0,0 +1,17 @@
## Conditional Documentation Loading
**Read the relevant guide before starting work:**
| Task Type | Guide |
|-----------|-------|
| Bootstrapping a new project | `~/.mosaic/guides/bootstrap.md` |
| Orchestrating autonomous tasks | `~/.mosaic/guides/orchestrator.md` |
| Ralph autonomous development | `~/.mosaic/guides/ralph-autonomous.md` |
| Frontend development | `~/.mosaic/guides/frontend.md` |
| Backend/API development | `~/.mosaic/guides/backend.md` |
| TypeScript strict typing | `~/.mosaic/guides/typescript.md` |
| Code review | `~/.mosaic/guides/code-review.md` |
| Authentication/Authorization | `~/.mosaic/guides/authentication.md` |
| Infrastructure/DevOps | `~/.mosaic/guides/infrastructure.md` |
| QA/Testing | `~/.mosaic/guides/qa-testing.md` |
| Secrets management (Vault) | `~/.mosaic/guides/vault-secrets.md` |

View File

@@ -0,0 +1,6 @@
## Multi-Agent Coordination
When multiple agents work on this project:
1. `git pull --rebase` before editing
2. `git pull --rebase` before pushing
3. If conflicts, **alert the user** — don't auto-resolve data conflicts

View File

@@ -0,0 +1,10 @@
## Secrets Management
**NEVER hardcode secrets.** Use `.env` files (gitignored) or a secrets manager.
```bash
# .env.example is committed (with placeholders)
# .env is NOT committed (contains real values)
```
Ensure `.gitignore` includes `.env*` (except `.env.example`).