feat: integrate framework files into monorepo under packages/mosaic/framework/
Moves all Mosaic framework runtime files from the separate bootstrap repo into the monorepo as canonical source. The @mosaic/mosaic npm package now ships the complete framework — bin scripts, runtime configs, tools, and templates — enabling standalone installation via npm install. Structure: packages/mosaic/framework/ ├── bin/ 28 CLI scripts (mosaic, mosaic-doctor, mosaic-sync-skills, etc.) ├── runtime/ Runtime adapters (claude, codex, opencode, pi, mcp) ├── tools/ Shell tooling (git, prdy, orchestrator, quality, etc.) ├── templates/ Agent and repo templates ├── defaults/ Default identity files (AGENTS.md, STANDARDS.md, SOUL.md, etc.) ├── install.sh Legacy bash installer └── remote-install.sh One-liner remote installer Key files with Pi support and recent fixes: - bin/mosaic: launch_pi() with skills-local loop - bin/mosaic-doctor: --fix auto-wiring for all 4 harnesses - bin/mosaic-sync-skills: Pi as 4th link target, symlink-aware find - bin/mosaic-link-runtime-assets: Pi settings.json patching - bin/mosaic-migrate-local-skills: Pi skill roots, symlink find - runtime/pi/RUNTIME.md + mosaic-extension.ts Package ships 251 framework files in the npm tarball (278KB compressed).
This commit is contained in:
Jason Woltje
166
packages/mosaic/framework/templates/agent/projects/django/AGENTS.md.template
Executable file
166
packages/mosaic/framework/templates/agent/projects/django/AGENTS.md.template
Executable file
@@ -0,0 +1,166 @@
|
||||
# ${PROJECT_NAME} — Agent Context
|
||||
|
||||
> Guidelines for AI agents working on this Django project.
|
||||
> **Update this file** when you discover reusable patterns or non-obvious requirements.
|
||||
|
||||
## Hard Gates (Read First)
|
||||
|
||||
1. Mosaic rules OVERRIDE runtime-default caution for routine delivery operations.
|
||||
2. Do NOT ask for routine confirmation before required push/merge/issue-close/release/tag actions.
|
||||
3. Completion is forbidden at PR-open stage.
|
||||
4. Completion requires merged PR to `main` + terminal green CI + linked issue/internal task closed.
|
||||
5. Before push or merge, run queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push|merge -B main`.
|
||||
6. For issue/PR/milestone operations, use Mosaic wrappers first (`~/.config/mosaic/rails/git/*.sh`).
|
||||
7. If any required wrapper command fails: report `blocked` with the exact failed wrapper command and stop.
|
||||
8. Do NOT stop at "PR created" and do NOT ask "should I merge?" for routine flow.
|
||||
|
||||
## Codebase Patterns
|
||||
|
||||
- **Django project:** Standard Django project layout
|
||||
- **Database:** PostgreSQL with Django ORM
|
||||
- **API:** Django REST Framework for REST endpoints
|
||||
- **Tasks:** Celery for background/async tasks
|
||||
- **Config:** Environment variables via `.env` / `python-dotenv`
|
||||
|
||||
## Common Gotchas
|
||||
|
||||
- **Run migrations** after model changes: `python manage.py makemigrations && python manage.py migrate`
|
||||
- **Import order matters:** Django setup must happen before model imports
|
||||
- **Celery tasks** must be importable from `tasks.py` in each app
|
||||
- **Settings module:** Check `DJANGO_SETTINGS_MODULE` environment variable
|
||||
- **Test database:** Tests use a separate database — check `TEST` config in settings
|
||||
- **Static files:** Run `collectstatic` before deployment
|
||||
|
||||
## Context Management
|
||||
|
||||
| Strategy | When |
|
||||
|----------|------|
|
||||
| **Spawn sub-agents** | Isolated coding tasks, research |
|
||||
| **Batch operations** | Group related operations |
|
||||
| **Check existing patterns** | Before writing new code |
|
||||
| **Minimize re-reading** | Don't re-read files you just wrote |
|
||||
|
||||
## Quality Gates
|
||||
|
||||
**All must pass before any commit:**
|
||||
|
||||
```bash
|
||||
ruff check . && mypy . && pytest tests/
|
||||
```
|
||||
|
||||
## Testing Policy
|
||||
|
||||
1. Situational tests are the PRIMARY validation gate.
|
||||
2. Baseline tests remain REQUIRED for all software changes.
|
||||
3. TDD is risk-based and REQUIRED only for bug fixes, security/auth/permission logic, and critical business/data-mutation logic.
|
||||
4. Reference `~/.config/mosaic/guides/QA-TESTING.md`.
|
||||
|
||||
## PRD Requirement
|
||||
|
||||
1. Before coding begins, `docs/PRD.md` or `docs/PRD.json` MUST exist.
|
||||
2. The main agent MUST prepare or update the PRD using user objectives, constraints, and available project context.
|
||||
3. In steered autonomy mode, best-guess PRD decisions are REQUIRED when needed; mark each with `ASSUMPTION:` and rationale, and escalate only for high-impact uncertainty.
|
||||
4. Reference `~/.config/mosaic/guides/PRD.md`.
|
||||
|
||||
## Task Tracking Contract
|
||||
|
||||
1. For non-trivial implementation work, `docs/TASKS.md` MUST exist before coding.
|
||||
2. If external git provider is available (Gitea/GitHub/GitLab), create/update issue(s) before coding and map them in `docs/TASKS.md`.
|
||||
3. If no external provider is available, use internal refs in `docs/TASKS.md` (example: `TASKS:T1`).
|
||||
4. Keep `docs/TASKS.md` status in sync with actual progress until completion.
|
||||
5. For issue/PR/milestone actions, detect platform and use `~/.config/mosaic/rails/git/*.sh` wrappers first (no raw `gh`/`tea`/`glab` as first choice).
|
||||
6. If wrapper-driven merge/CI/issue-closure fails, report blocker with the exact failed wrapper command and stop (do not claim completion).
|
||||
|
||||
## Documentation Contract
|
||||
|
||||
Documentation is a hard delivery gate.
|
||||
If code/API/auth/infra changes, required documentation updates MUST be completed before task closure.
|
||||
Keep `docs/` root clean and store reports/artifacts in scoped folders (`docs/reports/`, `docs/tasks/`, `docs/releases/`, `docs/scratchpads/`).
|
||||
|
||||
Reference:
|
||||
- `~/.config/mosaic/guides/DOCUMENTATION.md`
|
||||
- `~/.config/mosaic/templates/docs/DOCUMENTATION-CHECKLIST.md`
|
||||
|
||||
## Token Budget Policy
|
||||
|
||||
1. If user plan or token limits are provided, they are HARD constraints.
|
||||
2. Track estimated and used tokens for non-trivial execution.
|
||||
3. Shift to conservative strategy when budget pressure rises (smaller scope, fewer parallel actions, reduced re-reading).
|
||||
4. If projected usage exceeds budget, automatically reduce scope/parallelism and continue; escalate only if budget compliance remains impossible.
|
||||
|
||||
## Merge Strategy (Hard Rule)
|
||||
|
||||
1. Create short-lived branches from `main`.
|
||||
2. Open PRs to `main` for delivery changes.
|
||||
3. Do not push directly to `main`.
|
||||
4. Merge PRs to `main` with squash strategy only.
|
||||
5. Do not mark implementation complete until PR is merged.
|
||||
6. Do not mark implementation complete until CI/pipeline status is terminal green.
|
||||
7. Close linked issues/tasks only after merge + green CI.
|
||||
8. Before push or merge, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push|merge -B main`.
|
||||
|
||||
|
||||
## Container Release Strategy (When Applicable)
|
||||
|
||||
1. Use immutable image tags: `sha-<shortsha>` and `v{base-version}-rc.{build}`.
|
||||
2. Use mutable environment tags only as pointers (`testing`, optional `staging`, `prod`).
|
||||
3. Deploy/promote by immutable digest; do not deploy by mutable tag alone.
|
||||
4. Do not use `latest` or `dev` as deployment references.
|
||||
5. Use blue-green by default; use canary only with automated metrics and rollback gates.
|
||||
|
||||
## Steered Autonomy Contract
|
||||
|
||||
1. Agent owns end-to-end delivery: plan, code, test, review, remediate, commit, push, PR/repo operations, release/tag, and deployment when in scope.
|
||||
2. Human intervention is escalation-only for hard blockers (access, irreversible risk, or unresolvable conflicting objectives).
|
||||
3. Code review is agent-executed and REQUIRED for any source-code change.
|
||||
|
||||
## Mode Declaration Contract
|
||||
|
||||
1. First response MUST declare mode before any actions.
|
||||
2. Orchestration mission: `Now initiating Orchestrator mode...`
|
||||
3. Implementation mission: `Now initiating Delivery mode...`
|
||||
4. Review-only mission: `Now initiating Review mode...`
|
||||
|
||||
## Orchestrator Integration
|
||||
|
||||
### Task Prefix
|
||||
Use `${TASK_PREFIX}` for orchestrated tasks (e.g., `${TASK_PREFIX}-SEC-001`).
|
||||
|
||||
### Worker Checklist
|
||||
1. Read `docs/PRD.md` or `docs/PRD.json`
|
||||
2. Read the finding details from the report
|
||||
3. Implement the fix following existing patterns
|
||||
4. Run quality gates (ALL must pass)
|
||||
5. Complete required documentation updates (if applicable)
|
||||
6. Commit: `git commit -m "fix({finding_id}): brief description"`
|
||||
7. Push: `git push origin {branch}`
|
||||
8. Report result as JSON
|
||||
|
||||
### Post-Coding Review
|
||||
After implementing changes, code review is REQUIRED for any source-code modification.
|
||||
For orchestrated tasks, the orchestrator will run:
|
||||
1. **Codex code review** — `~/.config/mosaic/rails/codex/codex-code-review.sh --uncommitted`
|
||||
2. **Codex security review** — `~/.config/mosaic/rails/codex/codex-security-review.sh --uncommitted`
|
||||
3. If blockers/critical findings: remediation task created
|
||||
4. If clean: task marked done
|
||||
|
||||
## Key Files
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `CLAUDE.md` | Project overview and conventions |
|
||||
| `pyproject.toml` | Python dependencies and tool config |
|
||||
| `${SOURCE_DIR}/manage.py` | Django management entry point |
|
||||
| `.env.example` | Required environment variables |
|
||||
|
||||
## Testing Approaches
|
||||
|
||||
- Unit tests: `pytest` with fixtures in `conftest.py`
|
||||
- API tests: DRF's `APITestCase` or pytest with `api_client` fixture
|
||||
- Database tests: Use `@pytest.mark.django_db` decorator
|
||||
- Mocking: `unittest.mock.patch` for external services
|
||||
- Minimum 85% coverage for new code
|
||||
|
||||
---
|
||||
|
||||
_Model-agnostic. Works for Claude, Codex, GPT, Llama, etc._
|
||||
225
packages/mosaic/framework/templates/agent/projects/django/CLAUDE.md.template
Executable file
225
packages/mosaic/framework/templates/agent/projects/django/CLAUDE.md.template
Executable file
@@ -0,0 +1,225 @@
|
||||
# ${PROJECT_NAME} — Claude Code Instructions
|
||||
|
||||
> **${PROJECT_DESCRIPTION}**
|
||||
|
||||
## Conditional Documentation Loading
|
||||
|
||||
| When working on... | Load this guide |
|
||||
|---|---|
|
||||
| Bootstrapping this project | `~/.config/mosaic/guides/BOOTSTRAP.md` |
|
||||
| PRD creation and requirements definition | `~/.config/mosaic/guides/PRD.md` |
|
||||
| Orchestrating autonomous tasks | `~/.config/mosaic/guides/ORCHESTRATOR.md` |
|
||||
| Backend/API development | `~/.config/mosaic/guides/BACKEND.md` |
|
||||
| Code review | `~/.config/mosaic/guides/CODE-REVIEW.md` |
|
||||
| Documentation updates and standards | `~/.config/mosaic/guides/DOCUMENTATION.md` |
|
||||
| QA/Testing | `~/.config/mosaic/guides/QA-TESTING.md` |
|
||||
|
||||
## Technology Stack
|
||||
|
||||
| Layer | Technology |
|
||||
|-------|------------|
|
||||
| **Backend** | Django / Django REST Framework |
|
||||
| **Database** | PostgreSQL |
|
||||
| **Task Queue** | Celery + Redis/Valkey |
|
||||
| **Testing** | pytest + pytest-django |
|
||||
| **Linting** | ruff |
|
||||
| **Type Checking** | mypy |
|
||||
| **Deployment** | Docker + docker-compose |
|
||||
|
||||
## Repository Structure
|
||||
|
||||
```
|
||||
${PROJECT_DIR}/
|
||||
├── CLAUDE.md # This file
|
||||
├── AGENTS.md # Agent-specific patterns and gotchas
|
||||
├── ${SOURCE_DIR}/ # Django project root
|
||||
│ ├── manage.py
|
||||
│ ├── ${PROJECT_SLUG}/ # Django settings module
|
||||
│ │ ├── settings.py
|
||||
│ │ ├── urls.py
|
||||
│ │ └── wsgi.py
|
||||
│ └── apps/ # Django applications
|
||||
├── tests/ # Test files
|
||||
├── docs/
|
||||
│ ├── PRD.md # Requirements source (or PRD.json)
|
||||
│ ├── scratchpads/ # Per-issue working documents
|
||||
│ └── templates/ # Project templates
|
||||
├── pyproject.toml # Python project configuration
|
||||
├── .env.example
|
||||
└── README.md
|
||||
```
|
||||
|
||||
## Development Workflow
|
||||
|
||||
### Branch Strategy
|
||||
- `main` — Protected delivery branch
|
||||
- `feat/<name>` / `fix/<name>` — Short-lived task branches created from `main`
|
||||
- All changes merge through PR into `main` only
|
||||
- Merge strategy for `main` PRs is squash-only
|
||||
|
||||
### Starting Work
|
||||
```bash
|
||||
git pull --rebase
|
||||
uv sync # or pip install -e ".[dev]"
|
||||
```
|
||||
|
||||
### Building / Running
|
||||
```bash
|
||||
python manage.py runserver # Development server
|
||||
python manage.py migrate # Apply migrations
|
||||
python manage.py shell # Django shell
|
||||
```
|
||||
|
||||
### Testing
|
||||
```bash
|
||||
pytest tests/ # Run all tests
|
||||
pytest tests/ -x # Stop on first failure
|
||||
pytest tests/ --cov # With coverage
|
||||
```
|
||||
|
||||
### Linting & Type Checking
|
||||
```bash
|
||||
ruff check . # Lint
|
||||
ruff format . # Format
|
||||
mypy . # Type check
|
||||
```
|
||||
|
||||
## Quality Gates
|
||||
|
||||
**All must pass before committing:**
|
||||
|
||||
```bash
|
||||
ruff check . && mypy . && pytest tests/
|
||||
```
|
||||
|
||||
## Testing Policy
|
||||
|
||||
1. Situational tests are the PRIMARY validation gate.
|
||||
2. Baseline tests are REQUIRED for all software changes.
|
||||
3. TDD is risk-based; required cases are defined in `~/.config/mosaic/guides/QA-TESTING.md`.
|
||||
|
||||
## PRD Requirement
|
||||
|
||||
1. Before coding begins, `docs/PRD.md` or `docs/PRD.json` MUST exist.
|
||||
2. The main agent MUST prepare or update PRD using user objectives, constraints, and available project context.
|
||||
3. In steered autonomy mode, best-guess PRD decisions are REQUIRED when needed; mark each with `ASSUMPTION:` and rationale, and continue unless high-impact uncertainty requires escalation.
|
||||
4. PRD is the source of requirements for implementation and testing.
|
||||
|
||||
## Token Budget Policy
|
||||
|
||||
1. If user plan or token limits are provided, they are HARD constraints.
|
||||
2. Track estimated and used tokens for non-trivial execution.
|
||||
3. Use conservative strategy when budget pressure rises.
|
||||
4. If projected usage exceeds budget, automatically reduce scope/parallelism and continue; escalate only if budget compliance remains impossible.
|
||||
|
||||
## Django Conventions
|
||||
|
||||
### Models
|
||||
- All tunable parameters stored in the database with `get_effective_*()` fallback patterns
|
||||
- Always create migrations for model changes: `python manage.py makemigrations`
|
||||
- Include migrations in commits
|
||||
- Use `models.TextChoices` or `models.IntegerChoices` for enum-like fields
|
||||
|
||||
### Views / API
|
||||
- Use Django REST Framework for API endpoints
|
||||
- Use serializers for validation
|
||||
- Use ViewSets for standard CRUD
|
||||
- Use permissions classes for authorization
|
||||
|
||||
### Management Commands
|
||||
- Place in `<app>/management/commands/`
|
||||
- Use `self.stdout.write()` for output
|
||||
- Handle interrupts gracefully
|
||||
|
||||
## Database
|
||||
|
||||
### Migration Workflow
|
||||
```bash
|
||||
# Create migration after model changes
|
||||
python manage.py makemigrations <app_name>
|
||||
|
||||
# Apply migrations
|
||||
python manage.py migrate
|
||||
|
||||
# Check for missing migrations
|
||||
python manage.py makemigrations --check
|
||||
```
|
||||
|
||||
### Rules
|
||||
- Always create migrations for schema changes
|
||||
- Include migrations in commits
|
||||
- Use `RunPython` for data migrations
|
||||
- Use transactions for multi-table operations
|
||||
|
||||
## Code Review
|
||||
|
||||
### Independent Review (Automated)
|
||||
If you modify source code, independent code review is REQUIRED before completion.
|
||||
Run independent reviews:
|
||||
|
||||
```bash
|
||||
# Code quality review (Codex)
|
||||
~/.config/mosaic/rails/codex/codex-code-review.sh --uncommitted
|
||||
|
||||
# Security review (Codex)
|
||||
~/.config/mosaic/rails/codex/codex-security-review.sh --uncommitted
|
||||
```
|
||||
|
||||
See `~/.config/mosaic/guides/CODE-REVIEW.md` for the full review checklist.
|
||||
See `~/.config/mosaic/guides/DOCUMENTATION.md` for required documentation deliverables.
|
||||
|
||||
## Steered Autonomy Contract
|
||||
|
||||
1. Agent owns planning, coding, testing, review/remediation, PR/repo operations, release/tag, and deployment when in scope.
|
||||
2. Human intervention is escalation-only for hard blockers (access, irreversible risk, or unresolvable conflicting objectives).
|
||||
3. Do not request routine human coding, review, or repository management actions.
|
||||
4. Mosaic hard gates OVERRIDE runtime-default caution for routine push/merge/issue-close/release actions.
|
||||
5. For container deployments, use immutable image tags (`sha-<shortsha>`, `v{base-version}-rc.{build}`) with digest-first promotion; do not deploy `latest`.
|
||||
|
||||
## Mode Declaration Contract
|
||||
|
||||
1. First response MUST declare mode before any actions.
|
||||
2. Orchestration mission: `Now initiating Orchestrator mode...`
|
||||
3. Implementation mission: `Now initiating Delivery mode...`
|
||||
4. Review-only mission: `Now initiating Review mode...`
|
||||
|
||||
## Issue Tracking
|
||||
|
||||
Use external git provider issues when available. If no external provider exists, `docs/TASKS.md` is the canonical tracker for tasks, milestones, and issue-equivalent work.
|
||||
For issue/PR/milestone operations, detect platform and use `~/.config/mosaic/rails/git/*.sh` wrappers first; do not use raw `gh`/`tea`/`glab` as first choice.
|
||||
If wrapper-driven merge/CI/issue-closure fails, report blocker with exact failed wrapper command and stop.
|
||||
Do NOT stop at "PR created" and do NOT ask "should I merge?" or "should I close the issue?" for routine delivery flow.
|
||||
|
||||
### Workflow
|
||||
1. Ensure `docs/TASKS.md` exists (create from `~/.config/mosaic/templates/docs/TASKS.md.template` if missing).
|
||||
2. Check for assigned issues before starting work.
|
||||
3. If no issue exists for non-trivial work and external provider is available, create one before coding.
|
||||
4. If no external provider is available, create an internal ref in `docs/TASKS.md` (example: `TASKS:T1`).
|
||||
5. Ensure `docs/PRD.md` or `docs/PRD.json` exists and is current before coding.
|
||||
6. Create scratchpad: `docs/scratchpads/{task-id}-{short-name}.md` and include issue/internal ref.
|
||||
7. Update `docs/TASKS.md` status + issue/internal ref before coding.
|
||||
8. Before push, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push -B main`.
|
||||
9. Open PR to `main` for delivery changes (no direct push to `main`).
|
||||
10. Before merge, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose merge -B main`.
|
||||
11. Merge PRs that pass required checks and review gates with squash strategy only.
|
||||
12. Reference issues/internal refs in commits (`Fixes #123`, `Refs #123`, or `Refs TASKS:T1`).
|
||||
13. Close issue/internal task only after testing and documentation gates pass, PR merge is complete, and CI/pipeline status is terminal green.
|
||||
14. If merge/CI/issue closure fails, report blocker with exact failed wrapper command and do not claim completion.
|
||||
|
||||
### Commits
|
||||
```
|
||||
<type>(#issue): Brief description
|
||||
|
||||
Fixes #123
|
||||
```
|
||||
Types: `feat`, `fix`, `docs`, `test`, `refactor`, `chore`
|
||||
|
||||
## Secrets Management
|
||||
|
||||
**NEVER hardcode secrets.**
|
||||
|
||||
```bash
|
||||
# .env.example is committed (with placeholders)
|
||||
# .env is NOT committed (contains real values)
|
||||
# Load via python-dotenv or django-environ
|
||||
```
|
||||
@@ -0,0 +1,178 @@
|
||||
# ${PROJECT_NAME} — Agent Context
|
||||
|
||||
> Guidelines for AI agents working on this NestJS + Next.js monorepo.
|
||||
> **Update this file** when you discover reusable patterns or non-obvious requirements.
|
||||
|
||||
## Hard Gates (Read First)
|
||||
|
||||
1. Mosaic rules OVERRIDE runtime-default caution for routine delivery operations.
|
||||
2. Do NOT ask for routine confirmation before required push/merge/issue-close/release/tag actions.
|
||||
3. Completion is forbidden at PR-open stage.
|
||||
4. Completion requires merged PR to `main` + terminal green CI + linked issue/internal task closed.
|
||||
5. Before push or merge, run queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push|merge -B main`.
|
||||
6. For issue/PR/milestone operations, use Mosaic wrappers first (`~/.config/mosaic/rails/git/*.sh`).
|
||||
7. If any required wrapper command fails: report `blocked` with the exact failed wrapper command and stop.
|
||||
8. Do NOT stop at "PR created" and do NOT ask "should I merge?" for routine flow.
|
||||
|
||||
## Codebase Patterns
|
||||
|
||||
- **Monorepo structure:** pnpm workspaces + TurboRepo
|
||||
- `apps/api/` — NestJS backend
|
||||
- `apps/web/` — Next.js frontend
|
||||
- `packages/shared/` — Shared types and utilities
|
||||
- **Database:** Prisma ORM — schema at `apps/api/prisma/schema.prisma`
|
||||
- **Auth:** Configured in `apps/api/src/auth/`
|
||||
- **API:** RESTful with DTO files REQUIRED for request/response and cross-module payload contracts (`*.dto.ts`)
|
||||
|
||||
## Common Gotchas
|
||||
|
||||
- **Always run `pnpm install`** after pulling — lockfile changes frequently
|
||||
- **Prisma generate** after schema changes: `pnpm --filter api prisma generate`
|
||||
- **Environment variables:** Frontend vars need `NEXT_PUBLIC_` prefix
|
||||
- **Import paths:** Use `@shared/` alias for shared package imports
|
||||
- **Tests require running database:** Set `DATABASE_URL` in `.env.test`
|
||||
- **TurboRepo caching:** Run `pnpm clean` if builds behave unexpectedly
|
||||
|
||||
## Context Management
|
||||
|
||||
Context = tokens = cost. Be smart.
|
||||
|
||||
| Strategy | When |
|
||||
|----------|------|
|
||||
| **Spawn sub-agents** | Isolated coding tasks, research |
|
||||
| **Batch operations** | Group related API calls |
|
||||
| **Check existing patterns** | Before writing new code |
|
||||
| **Minimize re-reading** | Don't re-read files you just wrote |
|
||||
|
||||
## Quality Gates
|
||||
|
||||
**All must pass before any commit:**
|
||||
|
||||
```bash
|
||||
pnpm typecheck && pnpm lint && pnpm test
|
||||
```
|
||||
|
||||
## Testing Policy
|
||||
|
||||
1. Situational tests are the PRIMARY validation gate.
|
||||
2. Baseline tests remain REQUIRED for all software changes.
|
||||
3. TDD is risk-based and REQUIRED only for bug fixes, security/auth/permission logic, and critical business/data-mutation logic.
|
||||
4. Reference `~/.config/mosaic/guides/QA-TESTING.md`.
|
||||
|
||||
## PRD Requirement
|
||||
|
||||
1. Before coding begins, `docs/PRD.md` or `docs/PRD.json` MUST exist.
|
||||
2. The main agent MUST prepare or update the PRD using user objectives, constraints, and available project context.
|
||||
3. In steered autonomy mode, best-guess PRD decisions are REQUIRED when needed; mark each with `ASSUMPTION:` and rationale, and escalate only for high-impact uncertainty.
|
||||
4. Reference `~/.config/mosaic/guides/PRD.md`.
|
||||
|
||||
## Task Tracking Contract
|
||||
|
||||
1. For non-trivial implementation work, `docs/TASKS.md` MUST exist before coding.
|
||||
2. If external git provider is available (Gitea/GitHub/GitLab), create/update issue(s) before coding and map them in `docs/TASKS.md`.
|
||||
3. If no external provider is available, use internal refs in `docs/TASKS.md` (example: `TASKS:T1`).
|
||||
4. Keep `docs/TASKS.md` status in sync with actual progress until completion.
|
||||
5. For issue/PR/milestone actions, detect platform and use `~/.config/mosaic/rails/git/*.sh` wrappers first (no raw `gh`/`tea`/`glab` as first choice).
|
||||
6. If wrapper-driven merge/CI/issue-closure fails, report blocker with the exact failed wrapper command and stop (do not claim completion).
|
||||
|
||||
## Documentation Contract
|
||||
|
||||
Documentation is a hard delivery gate.
|
||||
If code/API/auth/infra changes, required documentation updates MUST be completed before task closure.
|
||||
Keep `docs/` root clean and store reports/artifacts in scoped folders (`docs/reports/`, `docs/tasks/`, `docs/releases/`, `docs/scratchpads/`).
|
||||
|
||||
Reference:
|
||||
- `~/.config/mosaic/guides/DOCUMENTATION.md`
|
||||
- `~/.config/mosaic/templates/docs/DOCUMENTATION-CHECKLIST.md`
|
||||
|
||||
## Token Budget Policy
|
||||
|
||||
1. If user plan or token limits are provided, they are HARD constraints.
|
||||
2. Track estimated and used tokens for non-trivial execution.
|
||||
3. Shift to conservative strategy when budget pressure rises (smaller scope, fewer parallel actions, reduced re-reading).
|
||||
4. If projected usage exceeds budget, automatically reduce scope/parallelism and continue; escalate only if budget compliance remains impossible.
|
||||
|
||||
## Merge Strategy (Hard Rule)
|
||||
|
||||
1. Create short-lived branches from `main`.
|
||||
2. Open PRs to `main` for delivery changes.
|
||||
3. Do not push directly to `main`.
|
||||
4. Merge PRs to `main` with squash strategy only.
|
||||
5. Do not mark implementation complete until PR is merged.
|
||||
6. Do not mark implementation complete until CI/pipeline status is terminal green.
|
||||
7. Close linked issues/tasks only after merge + green CI.
|
||||
8. Before push or merge, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push|merge -B main`.
|
||||
|
||||
|
||||
## Container Release Strategy (When Applicable)
|
||||
|
||||
1. Use immutable image tags: `sha-<shortsha>` and `v{base-version}-rc.{build}`.
|
||||
2. Use mutable environment tags only as pointers (`testing`, optional `staging`, `prod`).
|
||||
3. Deploy/promote by immutable digest; do not deploy by mutable tag alone.
|
||||
4. Do not use `latest` or `dev` as deployment references.
|
||||
5. Use blue-green by default; use canary only with automated metrics and rollback gates.
|
||||
|
||||
## Steered Autonomy Contract
|
||||
|
||||
1. Agent owns end-to-end delivery: plan, code, test, review, remediate, commit, push, PR/repo operations, release/tag, and deployment when in scope.
|
||||
2. Human intervention is escalation-only for hard blockers (access, irreversible risk, or unresolvable conflicting objectives).
|
||||
3. Code review is agent-executed and REQUIRED for any source-code change.
|
||||
|
||||
## Mode Declaration Contract
|
||||
|
||||
1. First response MUST declare mode before any actions.
|
||||
2. Orchestration mission: `Now initiating Orchestrator mode...`
|
||||
3. Implementation mission: `Now initiating Delivery mode...`
|
||||
4. Review-only mission: `Now initiating Review mode...`
|
||||
|
||||
## Orchestrator Integration
|
||||
|
||||
### Task Prefix
|
||||
Use `${TASK_PREFIX}` for orchestrated tasks (e.g., `${TASK_PREFIX}-SEC-001`).
|
||||
|
||||
### Worker Checklist
|
||||
1. Read `docs/PRD.md` or `docs/PRD.json`
|
||||
2. Read the finding details from the report
|
||||
3. Implement the fix following existing patterns
|
||||
4. Run quality gates (ALL must pass)
|
||||
5. Complete required documentation updates (if applicable)
|
||||
6. Commit: `git commit -m "fix({finding_id}): brief description"`
|
||||
7. Push: `git push origin {branch}`
|
||||
8. Report result as JSON
|
||||
|
||||
### Post-Coding Review
|
||||
After implementing changes, code review is REQUIRED for any source-code modification.
|
||||
For orchestrated tasks, the orchestrator will run:
|
||||
1. **Codex code review** — `~/.config/mosaic/rails/codex/codex-code-review.sh --uncommitted`
|
||||
2. **Codex security review** — `~/.config/mosaic/rails/codex/codex-security-review.sh --uncommitted`
|
||||
3. If blockers/critical findings: remediation task created
|
||||
4. If clean: task marked done
|
||||
|
||||
## Workflow (Non-Negotiable)
|
||||
|
||||
```
|
||||
1. Branch → git checkout -b feature/XX-description
|
||||
2. Code → Implement with required tests; use TDD where required by policy
|
||||
3. Test → pnpm test (must pass)
|
||||
4. Push → git push origin feature/XX-description
|
||||
5. PR → Create PR to main
|
||||
6. Review → Wait for approval or self-merge if authorized using squash only
|
||||
7. Close → Close related issues
|
||||
```
|
||||
|
||||
**Never push directly to main. Always use a PR to main.**
|
||||
|
||||
## Key Files
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `CLAUDE.md` | Project overview and conventions |
|
||||
| `apps/api/prisma/schema.prisma` | Database schema |
|
||||
| `apps/api/src/` | Backend source |
|
||||
| `apps/web/app/` | Frontend pages |
|
||||
| `packages/shared/` | Shared types |
|
||||
| `.env.example` | Required environment variables |
|
||||
|
||||
---
|
||||
|
||||
_Model-agnostic. Works for Claude, Codex, GPT, Llama, etc._
|
||||
@@ -0,0 +1,258 @@
|
||||
# ${PROJECT_NAME} — Claude Code Instructions
|
||||
|
||||
> **${PROJECT_DESCRIPTION}**
|
||||
|
||||
## Conditional Documentation Loading
|
||||
|
||||
| When working on... | Load this guide |
|
||||
|---|---|
|
||||
| Bootstrapping this project | `~/.config/mosaic/guides/BOOTSTRAP.md` |
|
||||
| PRD creation and requirements definition | `~/.config/mosaic/guides/PRD.md` |
|
||||
| Orchestrating autonomous tasks | `~/.config/mosaic/guides/ORCHESTRATOR.md` |
|
||||
| Frontend development | `~/.config/mosaic/guides/FRONTEND.md` |
|
||||
| Backend/API development | `~/.config/mosaic/guides/BACKEND.md` |
|
||||
| Code review | `~/.config/mosaic/guides/CODE-REVIEW.md` |
|
||||
| Documentation updates and standards | `~/.config/mosaic/guides/DOCUMENTATION.md` |
|
||||
| TypeScript strict typing | `~/.config/mosaic/guides/TYPESCRIPT.md` |
|
||||
| Authentication/Authorization | `~/.config/mosaic/guides/AUTHENTICATION.md` |
|
||||
| QA/Testing | `~/.config/mosaic/guides/QA-TESTING.md` |
|
||||
|
||||
## Technology Stack
|
||||
|
||||
| Layer | Technology |
|
||||
|-------|------------|
|
||||
| **Frontend** | Next.js + React + TailwindCSS + Shadcn/ui |
|
||||
| **Backend** | NestJS + Prisma ORM |
|
||||
| **Database** | PostgreSQL |
|
||||
| **Testing** | Vitest + Playwright |
|
||||
| **Monorepo** | pnpm workspaces + TurboRepo |
|
||||
| **Deployment** | Docker + docker-compose |
|
||||
|
||||
## Repository Structure
|
||||
|
||||
```
|
||||
${PROJECT_DIR}/
|
||||
├── CLAUDE.md # This file
|
||||
├── AGENTS.md # Agent-specific patterns and gotchas
|
||||
├── apps/
|
||||
│ ├── api/ # NestJS backend
|
||||
│ │ ├── src/
|
||||
│ │ ├── prisma/
|
||||
│ │ │ └── schema.prisma
|
||||
│ │ └── Dockerfile
|
||||
│ └── web/ # Next.js frontend
|
||||
│ ├── app/
|
||||
│ ├── components/
|
||||
│ └── Dockerfile
|
||||
├── packages/
|
||||
│ ├── shared/ # Shared types, utilities
|
||||
│ ├── ui/ # Shared UI components
|
||||
│ └── config/ # Shared configuration
|
||||
├── docs/
|
||||
│ ├── PRD.md # Requirements source (or PRD.json)
|
||||
│ ├── scratchpads/ # Per-issue working documents
|
||||
│ └── templates/ # Project templates
|
||||
├── tests/ # Integration/E2E tests
|
||||
├── docker/ # Docker configuration
|
||||
├── .env.example
|
||||
├── turbo.json
|
||||
├── pnpm-workspace.yaml
|
||||
└── README.md
|
||||
```
|
||||
|
||||
## Development Workflow
|
||||
|
||||
### Branch Strategy
|
||||
- `main` — Protected delivery branch
|
||||
- `feature/*` / `fix/*` — Short-lived task branches created from `main`
|
||||
- All changes merge through PR into `main` only
|
||||
- Merge strategy for `main` PRs is squash-only
|
||||
|
||||
### Starting Work
|
||||
```bash
|
||||
git checkout main
|
||||
git pull --rebase origin main
|
||||
pnpm install
|
||||
```
|
||||
|
||||
### Building
|
||||
```bash
|
||||
pnpm build # Build all packages
|
||||
pnpm --filter api build # Build API only
|
||||
pnpm --filter web build # Build web only
|
||||
```
|
||||
|
||||
### Testing
|
||||
```bash
|
||||
pnpm test # Run all tests
|
||||
pnpm test:unit # Unit tests (Vitest)
|
||||
pnpm test:e2e # E2E tests (Playwright)
|
||||
pnpm test:coverage # Coverage report
|
||||
```
|
||||
|
||||
### Linting & Type Checking
|
||||
```bash
|
||||
pnpm lint # ESLint
|
||||
pnpm typecheck # TypeScript type checking
|
||||
pnpm format # Prettier formatting
|
||||
```
|
||||
|
||||
## Quality Gates
|
||||
|
||||
**All must pass before committing:**
|
||||
|
||||
```bash
|
||||
pnpm typecheck && pnpm lint && pnpm test
|
||||
```
|
||||
|
||||
## Testing Policy
|
||||
|
||||
1. Situational tests are the PRIMARY validation gate.
|
||||
2. Baseline tests are REQUIRED for all software changes.
|
||||
3. TDD is risk-based; required cases are defined in `~/.config/mosaic/guides/QA-TESTING.md`.
|
||||
|
||||
## PRD Requirement
|
||||
|
||||
1. Before coding begins, `docs/PRD.md` or `docs/PRD.json` MUST exist.
|
||||
2. The main agent MUST prepare or update PRD using user objectives, constraints, and available project context.
|
||||
3. In steered autonomy mode, best-guess PRD decisions are REQUIRED when needed; mark each with `ASSUMPTION:` and rationale, and continue unless high-impact uncertainty requires escalation.
|
||||
4. PRD is the source of requirements for implementation and testing.
|
||||
|
||||
## Token Budget Policy
|
||||
|
||||
1. If user plan or token limits are provided, they are HARD constraints.
|
||||
2. Track estimated and used tokens for non-trivial execution.
|
||||
3. Use conservative strategy when budget pressure rises.
|
||||
4. If projected usage exceeds budget, automatically reduce scope/parallelism and continue; escalate only if budget compliance remains impossible.
|
||||
|
||||
## API Conventions
|
||||
|
||||
### NestJS Patterns
|
||||
- Controllers handle HTTP, Services handle business logic
|
||||
- DTO files are REQUIRED at module/API boundaries (`*.dto.ts`)
|
||||
- Use DTOs with `class-validator` for request validation
|
||||
- Use Guards for authentication/authorization
|
||||
- Use Interceptors for response transformation
|
||||
- Use Prisma for database access (no raw SQL)
|
||||
|
||||
### REST API Standards
|
||||
- `GET /resource` — List (with pagination)
|
||||
- `GET /resource/:id` — Get single
|
||||
- `POST /resource` — Create
|
||||
- `PATCH /resource/:id` — Update
|
||||
- `DELETE /resource/:id` — Delete
|
||||
- Return proper HTTP status codes (201 Created, 204 No Content, etc.)
|
||||
|
||||
## Frontend Conventions
|
||||
|
||||
### Next.js Patterns
|
||||
- Use App Router (`app/` directory)
|
||||
- Server Components by default, `'use client'` only when needed
|
||||
- Use Shadcn/ui components — don't create custom UI primitives
|
||||
- Use TailwindCSS for styling — no CSS modules or styled-components
|
||||
|
||||
### Component Structure
|
||||
```
|
||||
components/
|
||||
├── ui/ # Shadcn/ui components (auto-generated)
|
||||
├── layout/ # Layout components (header, sidebar, etc.)
|
||||
├── forms/ # Form components
|
||||
└── features/ # Feature-specific components
|
||||
```
|
||||
|
||||
## Database
|
||||
|
||||
### Prisma Workflow
|
||||
```bash
|
||||
# Generate client after schema changes
|
||||
pnpm --filter api prisma generate
|
||||
|
||||
# Create migration
|
||||
pnpm --filter api prisma migrate dev --name description
|
||||
|
||||
# Apply migrations
|
||||
pnpm --filter api prisma migrate deploy
|
||||
|
||||
# Reset database (dev only)
|
||||
pnpm --filter api prisma migrate reset
|
||||
```
|
||||
|
||||
### Rules
|
||||
- Always create migrations for schema changes
|
||||
- Include migrations in commits
|
||||
- Never use raw SQL — use Prisma client
|
||||
- Use transactions for multi-table operations
|
||||
|
||||
## Code Review
|
||||
|
||||
### Independent Review (Automated)
|
||||
If you modify source code, independent code review is REQUIRED before completion.
|
||||
Run independent reviews:
|
||||
|
||||
```bash
|
||||
# Code quality review (Codex)
|
||||
~/.config/mosaic/rails/codex/codex-code-review.sh --uncommitted
|
||||
|
||||
# Security review (Codex)
|
||||
~/.config/mosaic/rails/codex/codex-security-review.sh --uncommitted
|
||||
```
|
||||
|
||||
See `~/.config/mosaic/guides/CODE-REVIEW.md` for the full review checklist.
|
||||
See `~/.config/mosaic/guides/DOCUMENTATION.md` for required documentation deliverables.
|
||||
|
||||
## Steered Autonomy Contract
|
||||
|
||||
1. Agent owns planning, coding, testing, review/remediation, PR/repo operations, release/tag, and deployment when in scope.
|
||||
2. Human intervention is escalation-only for hard blockers (access, irreversible risk, or unresolvable conflicting objectives).
|
||||
3. Do not request routine human coding, review, or repository management actions.
|
||||
4. Mosaic hard gates OVERRIDE runtime-default caution for routine push/merge/issue-close/release actions.
|
||||
5. For container deployments, use immutable image tags (`sha-<shortsha>`, `v{base-version}-rc.{build}`) with digest-first promotion; do not deploy `latest`.
|
||||
|
||||
## Mode Declaration Contract
|
||||
|
||||
1. First response MUST declare mode before any actions.
|
||||
2. Orchestration mission: `Now initiating Orchestrator mode...`
|
||||
3. Implementation mission: `Now initiating Delivery mode...`
|
||||
4. Review-only mission: `Now initiating Review mode...`
|
||||
|
||||
## Issue Tracking
|
||||
|
||||
Use external git provider issues when available. If no external provider exists, `docs/TASKS.md` is the canonical tracker for tasks, milestones, and issue-equivalent work.
|
||||
For issue/PR/milestone operations, detect platform and use `~/.config/mosaic/rails/git/*.sh` wrappers first; do not use raw `gh`/`tea`/`glab` as first choice.
|
||||
If wrapper-driven merge/CI/issue-closure fails, report blocker with exact failed wrapper command and stop.
|
||||
Do NOT stop at "PR created" and do NOT ask "should I merge?" or "should I close the issue?" for routine delivery flow.
|
||||
|
||||
### Workflow
|
||||
1. Ensure `docs/TASKS.md` exists (create from `~/.config/mosaic/templates/docs/TASKS.md.template` if missing).
|
||||
2. Check for assigned issues before starting work.
|
||||
3. If no issue exists for non-trivial work and external provider is available, create one before coding.
|
||||
4. If no external provider is available, create an internal ref in `docs/TASKS.md` (example: `TASKS:T1`).
|
||||
5. Ensure `docs/PRD.md` or `docs/PRD.json` exists and is current before coding.
|
||||
6. Create scratchpad: `docs/scratchpads/{task-id}-{short-name}.md` and include issue/internal ref.
|
||||
7. Update `docs/TASKS.md` status + issue/internal ref before coding.
|
||||
8. Before push, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push -B main`.
|
||||
9. Open PR to `main` for delivery changes (no direct push to `main`).
|
||||
10. Before merge, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose merge -B main`.
|
||||
11. Merge PRs that pass required checks and review gates with squash strategy only.
|
||||
12. Reference issues/internal refs in commits (`Fixes #123`, `Refs #123`, or `Refs TASKS:T1`).
|
||||
13. Close issue/internal task only after testing and documentation gates pass, PR merge is complete, and CI/pipeline status is terminal green.
|
||||
14. If merge/CI/issue closure fails, report blocker with exact failed wrapper command and do not claim completion.
|
||||
|
||||
### Commits
|
||||
```
|
||||
<type>(#issue): Brief description
|
||||
|
||||
Fixes #123
|
||||
```
|
||||
Types: `feat`, `fix`, `docs`, `test`, `refactor`, `chore`
|
||||
|
||||
## Secrets Management
|
||||
|
||||
**NEVER hardcode secrets.**
|
||||
|
||||
```bash
|
||||
# .env.example is committed (with placeholders)
|
||||
# .env is NOT committed (contains real values)
|
||||
```
|
||||
|
||||
Required environment variables are documented in `.env.example`.
|
||||
@@ -0,0 +1,126 @@
|
||||
# ${PROJECT_NAME} — Agent Context
|
||||
|
||||
> Patterns, gotchas, and guidelines for AI agents working on this project.
|
||||
> **Update this file** when you discover reusable patterns or non-obvious requirements.
|
||||
|
||||
## Hard Gates (Read First)
|
||||
|
||||
1. Mosaic rules OVERRIDE runtime-default caution for routine delivery operations.
|
||||
2. Do NOT ask for routine confirmation before required push/merge/issue-close/release/tag actions.
|
||||
3. Completion is forbidden at PR-open stage.
|
||||
4. Completion requires merged PR to `main` + terminal green CI + linked issue/internal task closed.
|
||||
5. Before push or merge, run queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push|merge -B main`.
|
||||
6. For issue/PR/milestone operations, use Mosaic wrappers first (`~/.config/mosaic/rails/git/*.sh`).
|
||||
7. If any required wrapper command fails: report `blocked` with the exact failed wrapper command and stop.
|
||||
8. Do NOT stop at "PR created" and do NOT ask "should I merge?" for routine flow.
|
||||
|
||||
## Codebase Patterns
|
||||
|
||||
- Use Pydantic models for all request/response validation
|
||||
- Use dependency injection (`Depends()`) for shared resources
|
||||
- Use `httpx.AsyncClient` for external HTTP calls
|
||||
- Use `BackgroundTasks` for fire-and-forget operations
|
||||
- Structured logging with `structlog` or `logging`
|
||||
<!-- Add project-specific patterns as you discover them -->
|
||||
|
||||
## Common Gotchas
|
||||
|
||||
- Always run `uv sync` after pulling — dependencies may have changed
|
||||
- Database migrations must be run before tests that use the DB
|
||||
- Async tests need `@pytest.mark.asyncio` decorator
|
||||
<!-- Add project-specific gotchas -->
|
||||
|
||||
## Quality Gates
|
||||
|
||||
**All must pass before any commit:**
|
||||
|
||||
```bash
|
||||
uv run ruff check src/ tests/ && uv run ruff format --check src/ && uv run mypy src/ && uv run pytest --cov
|
||||
```
|
||||
|
||||
## Testing Policy
|
||||
|
||||
1. Situational tests are the PRIMARY validation gate.
|
||||
2. Baseline tests remain REQUIRED for all software changes.
|
||||
3. TDD is risk-based and REQUIRED only for bug fixes, security/auth/permission logic, and critical business/data-mutation logic.
|
||||
4. Reference `~/.config/mosaic/guides/QA-TESTING.md`.
|
||||
|
||||
## PRD Requirement
|
||||
|
||||
1. Before coding begins, `docs/PRD.md` or `docs/PRD.json` MUST exist.
|
||||
2. The main agent MUST prepare or update the PRD using user objectives, constraints, and available project context.
|
||||
3. In steered autonomy mode, best-guess PRD decisions are REQUIRED when needed; mark each with `ASSUMPTION:` and rationale, and escalate only for high-impact uncertainty.
|
||||
4. Reference `~/.config/mosaic/guides/PRD.md`.
|
||||
|
||||
## Task Tracking Contract
|
||||
|
||||
1. For non-trivial implementation work, `docs/TASKS.md` MUST exist before coding.
|
||||
2. If external git provider is available (Gitea/GitHub/GitLab), create/update issue(s) before coding and map them in `docs/TASKS.md`.
|
||||
3. If no external provider is available, use internal refs in `docs/TASKS.md` (example: `TASKS:T1`).
|
||||
4. Keep `docs/TASKS.md` status in sync with actual progress until completion.
|
||||
5. For issue/PR/milestone actions, detect platform and use `~/.config/mosaic/rails/git/*.sh` wrappers first (no raw `gh`/`tea`/`glab` as first choice).
|
||||
6. If wrapper-driven merge/CI/issue-closure fails, report blocker with the exact failed wrapper command and stop (do not claim completion).
|
||||
|
||||
## Documentation Contract
|
||||
|
||||
Documentation is a hard delivery gate.
|
||||
If code/API/auth/infra changes, required documentation updates MUST be completed before task closure.
|
||||
Keep `docs/` root clean and store reports/artifacts in scoped folders (`docs/reports/`, `docs/tasks/`, `docs/releases/`, `docs/scratchpads/`).
|
||||
|
||||
Reference:
|
||||
- `~/.config/mosaic/guides/DOCUMENTATION.md`
|
||||
- `~/.config/mosaic/templates/docs/DOCUMENTATION-CHECKLIST.md`
|
||||
|
||||
## Token Budget Policy
|
||||
|
||||
1. If user plan or token limits are provided, they are HARD constraints.
|
||||
2. Track estimated and used tokens for non-trivial execution.
|
||||
3. Shift to conservative strategy when budget pressure rises (smaller scope, fewer parallel actions, reduced re-reading).
|
||||
4. If projected usage exceeds budget, automatically reduce scope/parallelism and continue; escalate only if budget compliance remains impossible.
|
||||
|
||||
## Merge Strategy (Hard Rule)
|
||||
|
||||
1. Create short-lived branches from `main`.
|
||||
2. Open PRs to `main` for delivery changes.
|
||||
3. Do not push directly to `main`.
|
||||
4. Merge PRs to `main` with squash strategy only.
|
||||
5. Do not mark implementation complete until PR is merged.
|
||||
6. Do not mark implementation complete until CI/pipeline status is terminal green.
|
||||
7. Close linked issues/tasks only after merge + green CI.
|
||||
8. Before push or merge, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push|merge -B main`.
|
||||
|
||||
## Container Release Strategy (When Applicable)
|
||||
|
||||
1. Use immutable image tags: `sha-<shortsha>` and `v{base-version}-rc.{build}`.
|
||||
2. Use mutable environment tags only as pointers (`testing`, optional `staging`, `prod`).
|
||||
3. Deploy/promote by immutable digest; do not deploy by mutable tag alone.
|
||||
4. Do not use `latest` or `dev` as deployment references.
|
||||
5. Use blue-green by default; use canary only with automated metrics and rollback gates.
|
||||
|
||||
## Steered Autonomy Contract
|
||||
|
||||
1. Agent owns end-to-end delivery: plan, code, test, review, remediate, commit, push, PR/repo operations, release/tag, and deployment when in scope.
|
||||
2. Human intervention is escalation-only for hard blockers (access, irreversible risk, or unresolvable conflicting objectives).
|
||||
3. Code review is agent-executed and REQUIRED for any source-code change.
|
||||
|
||||
## Mode Declaration Contract
|
||||
|
||||
1. First response MUST declare mode before any actions.
|
||||
2. Orchestration mission: `Now initiating Orchestrator mode...`
|
||||
3. Implementation mission: `Now initiating Delivery mode...`
|
||||
4. Review-only mission: `Now initiating Review mode...`
|
||||
|
||||
## Key Files
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `pyproject.toml` | Project configuration, dependencies |
|
||||
| `src/${PROJECT_SLUG}/main.py` | Application entry point |
|
||||
<!-- Add project-specific key files -->
|
||||
|
||||
## Testing Approaches
|
||||
|
||||
- Unit tests: pytest with fixtures in `conftest.py`
|
||||
- API tests: `httpx.AsyncClient` with `TestClient`
|
||||
- Coverage minimum: 85%
|
||||
<!-- Document project-specific testing patterns -->
|
||||
@@ -0,0 +1,195 @@
|
||||
# ${PROJECT_NAME} — Claude Code Instructions
|
||||
|
||||
> **Project:** ${PROJECT_DESCRIPTION}
|
||||
> **Repository:** ${REPO_URL}
|
||||
|
||||
## Conditional Documentation Loading
|
||||
|
||||
**Read the relevant guide before starting work:**
|
||||
|
||||
| Task Type | Guide |
|
||||
|-----------|-------|
|
||||
| End-to-end implementation and validation | `~/.config/mosaic/guides/E2E-DELIVERY.md` |
|
||||
| PRD creation and requirements definition | `~/.config/mosaic/guides/PRD.md` |
|
||||
| Bootstrapping this project | `~/.config/mosaic/guides/BOOTSTRAP.md` |
|
||||
| Orchestrating autonomous tasks | `~/.config/mosaic/guides/ORCHESTRATOR.md` |
|
||||
| Backend/API development | `~/.config/mosaic/guides/BACKEND.md` |
|
||||
| Authentication/Authorization | `~/.config/mosaic/guides/AUTHENTICATION.md` |
|
||||
| Code review | `~/.config/mosaic/guides/CODE-REVIEW.md` |
|
||||
| Documentation updates and standards | `~/.config/mosaic/guides/DOCUMENTATION.md` |
|
||||
| QA/Testing | `~/.config/mosaic/guides/QA-TESTING.md` |
|
||||
| Infrastructure/DevOps | `~/.config/mosaic/guides/INFRASTRUCTURE.md` |
|
||||
| Secrets management (Vault) | `~/.config/mosaic/guides/VAULT-SECRETS.md` |
|
||||
|
||||
## Technology Stack
|
||||
|
||||
| Layer | Technology |
|
||||
|-------|------------|
|
||||
| **Backend** | FastAPI |
|
||||
| **Language** | Python 3.11+ |
|
||||
| **Database** | ${DATABASE_STACK} |
|
||||
| **Testing** | pytest + httpx |
|
||||
| **Linting** | ruff |
|
||||
| **Type Checking** | mypy (strict) |
|
||||
| **Security** | bandit + pip-audit |
|
||||
| **Package Manager** | uv |
|
||||
| **Deployment** | ${DEPLOYMENT_STACK} |
|
||||
|
||||
## Repository Structure
|
||||
|
||||
```
|
||||
${PROJECT_DIR}/
|
||||
├── CLAUDE.md # This file
|
||||
├── AGENTS.md # Agent-specific patterns and gotchas
|
||||
├── src/ # Source code
|
||||
│ └── ${PROJECT_SLUG}/ # Main package
|
||||
├── tests/ # Test files
|
||||
├── docs/
|
||||
│ ├── PRD.md # Requirements source (or PRD.json)
|
||||
│ └── scratchpads/ # Per-issue working documents
|
||||
├── pyproject.toml # Project configuration
|
||||
└── .env.example # Environment template
|
||||
```
|
||||
|
||||
## Development Workflow
|
||||
|
||||
### Setup
|
||||
```bash
|
||||
uv sync --all-extras
|
||||
```
|
||||
|
||||
### Running
|
||||
```bash
|
||||
uv run uvicorn ${PROJECT_SLUG}.main:app --reload --port 8000
|
||||
```
|
||||
|
||||
### Testing
|
||||
```bash
|
||||
uv run pytest # Run all tests
|
||||
uv run pytest --cov # With coverage (85% min)
|
||||
```
|
||||
|
||||
### Linting & Type Checking
|
||||
```bash
|
||||
uv run ruff check src/ tests/ # Lint
|
||||
uv run ruff format --check src/ # Format check
|
||||
uv run mypy src/ # Type check
|
||||
```
|
||||
|
||||
### Security
|
||||
```bash
|
||||
uv run bandit -r src/ # SAST scanning
|
||||
uv run pip-audit # Dependency vulnerabilities
|
||||
```
|
||||
|
||||
## Quality Gates
|
||||
|
||||
**All must pass before committing:**
|
||||
|
||||
```bash
|
||||
uv run ruff check src/ tests/ && uv run ruff format --check src/ && uv run mypy src/ && uv run pytest --cov
|
||||
```
|
||||
|
||||
## Testing Policy
|
||||
|
||||
1. Situational tests are the PRIMARY validation gate.
|
||||
2. Baseline tests are REQUIRED for all software changes.
|
||||
3. TDD is risk-based; required cases are defined in `~/.config/mosaic/guides/QA-TESTING.md`.
|
||||
|
||||
## PRD Requirement
|
||||
|
||||
1. Before coding begins, `docs/PRD.md` or `docs/PRD.json` MUST exist.
|
||||
2. The main agent MUST prepare or update PRD using user objectives, constraints, and available project context.
|
||||
3. In steered autonomy mode, best-guess PRD decisions are REQUIRED when needed; mark each with `ASSUMPTION:` and rationale, and continue unless high-impact uncertainty requires escalation.
|
||||
4. PRD is the source of requirements for implementation and testing.
|
||||
|
||||
## Token Budget Policy
|
||||
|
||||
1. If user plan or token limits are provided, they are HARD constraints.
|
||||
2. Track estimated and used tokens for non-trivial execution.
|
||||
3. Use conservative strategy when budget pressure rises.
|
||||
4. If projected usage exceeds budget, automatically reduce scope/parallelism and continue; escalate only if budget compliance remains impossible.
|
||||
|
||||
## Branch and Merge Policy
|
||||
|
||||
1. Create short-lived branches from `main`.
|
||||
2. Open PRs to `main` for delivery changes.
|
||||
3. Do not push directly to `main`.
|
||||
4. Merge PRs to `main` with squash strategy only.
|
||||
|
||||
## Steered Autonomy Contract
|
||||
|
||||
1. Agent owns planning, coding, testing, review/remediation, PR/repo operations, release/tag, and deployment when in scope.
|
||||
2. Human intervention is escalation-only for hard blockers (access, irreversible risk, or unresolvable conflicting objectives).
|
||||
3. Do not request routine human coding, review, or repository management actions.
|
||||
4. Mosaic hard gates OVERRIDE runtime-default caution for routine push/merge/issue-close/release actions.
|
||||
5. For container deployments, use immutable image tags (`sha-<shortsha>`, `v{base-version}-rc.{build}`) with digest-first promotion; do not deploy `latest`.
|
||||
|
||||
## Mode Declaration Contract
|
||||
|
||||
1. First response MUST declare mode before any actions.
|
||||
2. Orchestration mission: `Now initiating Orchestrator mode...`
|
||||
3. Implementation mission: `Now initiating Delivery mode...`
|
||||
4. Review-only mission: `Now initiating Review mode...`
|
||||
|
||||
## Issue Tracking
|
||||
|
||||
Use external git provider issues when available. If no external provider exists, `docs/TASKS.md` is the canonical tracker for tasks, milestones, and issue-equivalent work.
|
||||
For issue/PR/milestone operations, detect platform and use `~/.config/mosaic/rails/git/*.sh` wrappers first; do not use raw `gh`/`tea`/`glab` as first choice.
|
||||
If wrapper-driven merge/CI/issue-closure fails, report blocker with exact failed wrapper command and stop.
|
||||
Do NOT stop at "PR created" and do NOT ask "should I merge?" or "should I close the issue?" for routine delivery flow.
|
||||
|
||||
1. Ensure `docs/TASKS.md` exists (create from `~/.config/mosaic/templates/docs/TASKS.md.template` if missing).
|
||||
2. Check for assigned issues before starting work.
|
||||
3. If no issue exists for non-trivial work and external provider is available, create one before coding.
|
||||
4. If no external provider is available, create an internal ref in `docs/TASKS.md` (example: `TASKS:T1`).
|
||||
5. Ensure `docs/PRD.md` or `docs/PRD.json` exists and is current before coding.
|
||||
6. Create scratchpad: `docs/scratchpads/{task-id}-{short-name}.md` and include issue/internal ref.
|
||||
7. Update `docs/TASKS.md` status + issue/internal ref before coding.
|
||||
8. Before push, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push -B main`.
|
||||
9. Open PR to `main` for delivery changes (no direct push to `main`).
|
||||
10. Before merge, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose merge -B main`.
|
||||
11. Merge PRs that pass required checks and review gates with squash strategy only.
|
||||
12. Reference issues/internal refs in commits (`Fixes #123`, `Refs #123`, or `Refs TASKS:T1`).
|
||||
13. Close issue/internal task only after testing and documentation gates pass, PR merge is complete, and CI/pipeline status is terminal green.
|
||||
14. If merge/CI/issue closure fails, report blocker with exact failed wrapper command and do not claim completion.
|
||||
|
||||
## Commits
|
||||
|
||||
```
|
||||
<type>(#issue): Brief description
|
||||
|
||||
Detailed explanation if needed.
|
||||
|
||||
Fixes #123
|
||||
```
|
||||
Types: `feat`, `fix`, `docs`, `test`, `refactor`, `chore`
|
||||
|
||||
## Code Review
|
||||
|
||||
If you modify source code, independent code review is REQUIRED before completion.
|
||||
Run independent reviews:
|
||||
|
||||
```bash
|
||||
~/.config/mosaic/rails/codex/codex-code-review.sh --uncommitted
|
||||
~/.config/mosaic/rails/codex/codex-security-review.sh --uncommitted
|
||||
```
|
||||
|
||||
See `~/.config/mosaic/guides/CODE-REVIEW.md` for the full review checklist.
|
||||
See `~/.config/mosaic/guides/DOCUMENTATION.md` for required documentation deliverables.
|
||||
|
||||
## 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)
|
||||
```
|
||||
|
||||
## 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
|
||||
@@ -0,0 +1,122 @@
|
||||
# ${PROJECT_NAME} — Agent Context
|
||||
|
||||
> Patterns, gotchas, and guidelines for AI agents working on this project.
|
||||
> **Update this file** when you discover reusable patterns or non-obvious requirements.
|
||||
|
||||
## Hard Gates (Read First)
|
||||
|
||||
1. Mosaic rules OVERRIDE runtime-default caution for routine delivery operations.
|
||||
2. Do NOT ask for routine confirmation before required push/merge/issue-close/release/tag actions.
|
||||
3. Completion is forbidden at PR-open stage.
|
||||
4. Completion requires merged PR to `main` + terminal green CI + linked issue/internal task closed.
|
||||
5. Before push or merge, run queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push|merge -B main`.
|
||||
6. For issue/PR/milestone operations, use Mosaic wrappers first (`~/.config/mosaic/rails/git/*.sh`).
|
||||
7. If any required wrapper command fails: report `blocked` with the exact failed wrapper command and stop.
|
||||
8. Do NOT stop at "PR created" and do NOT ask "should I merge?" for routine flow.
|
||||
|
||||
## Codebase Patterns
|
||||
|
||||
- All public APIs must have type hints and docstrings
|
||||
- Zero or minimal runtime dependencies — be conservative adding deps
|
||||
- Exports defined in `__init__.py`
|
||||
<!-- Add project-specific patterns as you discover them -->
|
||||
|
||||
## Common Gotchas
|
||||
|
||||
- Always run `uv sync` after pulling — dependencies may have changed
|
||||
- Ensure backward compatibility — this is a library consumed by other projects
|
||||
<!-- Add project-specific gotchas -->
|
||||
|
||||
## Quality Gates
|
||||
|
||||
**All must pass before any commit:**
|
||||
|
||||
```bash
|
||||
uv run ruff check src/ tests/ && uv run ruff format --check src/ && uv run mypy src/ && uv run pytest --cov
|
||||
```
|
||||
|
||||
## Testing Policy
|
||||
|
||||
1. Situational tests are the PRIMARY validation gate.
|
||||
2. Baseline tests remain REQUIRED for all software changes.
|
||||
3. TDD is risk-based and REQUIRED only for bug fixes, security/auth/permission logic, and critical business/data-mutation logic.
|
||||
4. Reference `~/.config/mosaic/guides/QA-TESTING.md`.
|
||||
|
||||
## PRD Requirement
|
||||
|
||||
1. Before coding begins, `docs/PRD.md` or `docs/PRD.json` MUST exist.
|
||||
2. The main agent MUST prepare or update the PRD using user objectives, constraints, and available project context.
|
||||
3. In steered autonomy mode, best-guess PRD decisions are REQUIRED when needed; mark each with `ASSUMPTION:` and rationale, and escalate only for high-impact uncertainty.
|
||||
4. Reference `~/.config/mosaic/guides/PRD.md`.
|
||||
|
||||
## Task Tracking Contract
|
||||
|
||||
1. For non-trivial implementation work, `docs/TASKS.md` MUST exist before coding.
|
||||
2. If external git provider is available (Gitea/GitHub/GitLab), create/update issue(s) before coding and map them in `docs/TASKS.md`.
|
||||
3. If no external provider is available, use internal refs in `docs/TASKS.md` (example: `TASKS:T1`).
|
||||
4. Keep `docs/TASKS.md` status in sync with actual progress until completion.
|
||||
5. For issue/PR/milestone actions, detect platform and use `~/.config/mosaic/rails/git/*.sh` wrappers first (no raw `gh`/`tea`/`glab` as first choice).
|
||||
6. If wrapper-driven merge/CI/issue-closure fails, report blocker with the exact failed wrapper command and stop (do not claim completion).
|
||||
|
||||
## Documentation Contract
|
||||
|
||||
Documentation is a hard delivery gate.
|
||||
If code/API/auth/infra changes, required documentation updates MUST be completed before task closure.
|
||||
Keep `docs/` root clean and store reports/artifacts in scoped folders (`docs/reports/`, `docs/tasks/`, `docs/releases/`, `docs/scratchpads/`).
|
||||
|
||||
Reference:
|
||||
- `~/.config/mosaic/guides/DOCUMENTATION.md`
|
||||
- `~/.config/mosaic/templates/docs/DOCUMENTATION-CHECKLIST.md`
|
||||
|
||||
## Token Budget Policy
|
||||
|
||||
1. If user plan or token limits are provided, they are HARD constraints.
|
||||
2. Track estimated and used tokens for non-trivial execution.
|
||||
3. Shift to conservative strategy when budget pressure rises (smaller scope, fewer parallel actions, reduced re-reading).
|
||||
4. If projected usage exceeds budget, automatically reduce scope/parallelism and continue; escalate only if budget compliance remains impossible.
|
||||
|
||||
## Merge Strategy (Hard Rule)
|
||||
|
||||
1. Create short-lived branches from `main`.
|
||||
2. Open PRs to `main` for delivery changes.
|
||||
3. Do not push directly to `main`.
|
||||
4. Merge PRs to `main` with squash strategy only.
|
||||
5. Do not mark implementation complete until PR is merged.
|
||||
6. Do not mark implementation complete until CI/pipeline status is terminal green.
|
||||
7. Close linked issues/tasks only after merge + green CI.
|
||||
8. Before push or merge, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push|merge -B main`.
|
||||
|
||||
## Container Release Strategy (When Applicable)
|
||||
|
||||
1. Use immutable image tags: `sha-<shortsha>` and `v{base-version}-rc.{build}`.
|
||||
2. Use mutable environment tags only as pointers (`testing`, optional `staging`, `prod`).
|
||||
3. Deploy/promote by immutable digest; do not deploy by mutable tag alone.
|
||||
4. Do not use `latest` or `dev` as deployment references.
|
||||
5. Use blue-green by default; use canary only with automated metrics and rollback gates.
|
||||
|
||||
## Steered Autonomy Contract
|
||||
|
||||
1. Agent owns end-to-end delivery: plan, code, test, review, remediate, commit, push, PR/repo operations, release/tag, and deployment when in scope.
|
||||
2. Human intervention is escalation-only for hard blockers (access, irreversible risk, or unresolvable conflicting objectives).
|
||||
3. Code review is agent-executed and REQUIRED for any source-code change.
|
||||
|
||||
## Mode Declaration Contract
|
||||
|
||||
1. First response MUST declare mode before any actions.
|
||||
2. Orchestration mission: `Now initiating Orchestrator mode...`
|
||||
3. Implementation mission: `Now initiating Delivery mode...`
|
||||
4. Review-only mission: `Now initiating Review mode...`
|
||||
|
||||
## Key Files
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `pyproject.toml` | Project configuration, dependencies, build |
|
||||
| `src/${PROJECT_SLUG}/__init__.py` | Public API exports |
|
||||
<!-- Add project-specific key files -->
|
||||
|
||||
## Testing Approaches
|
||||
|
||||
- Unit tests: pytest with fixtures in `conftest.py`
|
||||
- Coverage minimum: 85%
|
||||
<!-- Document project-specific testing patterns -->
|
||||
@@ -0,0 +1,180 @@
|
||||
# ${PROJECT_NAME} — Claude Code Instructions
|
||||
|
||||
> **Project:** ${PROJECT_DESCRIPTION}
|
||||
> **Repository:** ${REPO_URL}
|
||||
|
||||
## Conditional Documentation Loading
|
||||
|
||||
**Read the relevant guide before starting work:**
|
||||
|
||||
| Task Type | Guide |
|
||||
|-----------|-------|
|
||||
| End-to-end implementation and validation | `~/.config/mosaic/guides/E2E-DELIVERY.md` |
|
||||
| PRD creation and requirements definition | `~/.config/mosaic/guides/PRD.md` |
|
||||
| Bootstrapping this project | `~/.config/mosaic/guides/BOOTSTRAP.md` |
|
||||
| Orchestrating autonomous tasks | `~/.config/mosaic/guides/ORCHESTRATOR.md` |
|
||||
| Backend/API development | `~/.config/mosaic/guides/BACKEND.md` |
|
||||
| Code review | `~/.config/mosaic/guides/CODE-REVIEW.md` |
|
||||
| Documentation updates and standards | `~/.config/mosaic/guides/DOCUMENTATION.md` |
|
||||
| QA/Testing | `~/.config/mosaic/guides/QA-TESTING.md` |
|
||||
|
||||
## Technology Stack
|
||||
|
||||
| Layer | Technology |
|
||||
|-------|------------|
|
||||
| **Language** | Python 3.11+ |
|
||||
| **Testing** | pytest |
|
||||
| **Linting** | ruff |
|
||||
| **Type Checking** | mypy (strict) |
|
||||
| **Package Manager** | uv |
|
||||
| **Build** | ${BUILD_SYSTEM} |
|
||||
|
||||
## Repository Structure
|
||||
|
||||
```
|
||||
${PROJECT_DIR}/
|
||||
├── CLAUDE.md # This file
|
||||
├── AGENTS.md # Agent-specific patterns and gotchas
|
||||
├── src/
|
||||
│ └── ${PROJECT_SLUG}/ # Main package
|
||||
├── tests/ # Test files
|
||||
├── docs/
|
||||
│ ├── PRD.md # Requirements source (or PRD.json)
|
||||
│ └── scratchpads/ # Per-issue working documents
|
||||
└── pyproject.toml # Project configuration
|
||||
```
|
||||
|
||||
## Development Workflow
|
||||
|
||||
### Setup
|
||||
```bash
|
||||
uv sync --all-extras
|
||||
```
|
||||
|
||||
### Testing
|
||||
```bash
|
||||
uv run pytest # Run all tests
|
||||
uv run pytest --cov # With coverage (85% min)
|
||||
```
|
||||
|
||||
### Linting & Type Checking
|
||||
```bash
|
||||
uv run ruff check src/ tests/ # Lint
|
||||
uv run ruff format --check src/ # Format check
|
||||
uv run mypy src/ # Type check
|
||||
```
|
||||
|
||||
## Quality Gates
|
||||
|
||||
**All must pass before committing:**
|
||||
|
||||
```bash
|
||||
uv run ruff check src/ tests/ && uv run ruff format --check src/ && uv run mypy src/ && uv run pytest --cov
|
||||
```
|
||||
|
||||
## Testing Policy
|
||||
|
||||
1. Situational tests are the PRIMARY validation gate.
|
||||
2. Baseline tests are REQUIRED for all software changes.
|
||||
3. TDD is risk-based; required cases are defined in `~/.config/mosaic/guides/QA-TESTING.md`.
|
||||
|
||||
## PRD Requirement
|
||||
|
||||
1. Before coding begins, `docs/PRD.md` or `docs/PRD.json` MUST exist.
|
||||
2. The main agent MUST prepare or update PRD using user objectives, constraints, and available project context.
|
||||
3. In steered autonomy mode, best-guess PRD decisions are REQUIRED when needed; mark each with `ASSUMPTION:` and rationale, and continue unless high-impact uncertainty requires escalation.
|
||||
4. PRD is the source of requirements for implementation and testing.
|
||||
|
||||
## Token Budget Policy
|
||||
|
||||
1. If user plan or token limits are provided, they are HARD constraints.
|
||||
2. Track estimated and used tokens for non-trivial execution.
|
||||
3. Use conservative strategy when budget pressure rises.
|
||||
4. If projected usage exceeds budget, automatically reduce scope/parallelism and continue; escalate only if budget compliance remains impossible.
|
||||
|
||||
## Branch and Merge Policy
|
||||
|
||||
1. Create short-lived branches from `main`.
|
||||
2. Open PRs to `main` for delivery changes.
|
||||
3. Do not push directly to `main`.
|
||||
4. Merge PRs to `main` with squash strategy only.
|
||||
|
||||
## Library Conventions
|
||||
|
||||
- Zero or minimal runtime dependencies
|
||||
- All public APIs must have type hints
|
||||
- All public functions must have docstrings
|
||||
- Exports defined in `__init__.py`
|
||||
- Versioning via `pyproject.toml`
|
||||
|
||||
## Steered Autonomy Contract
|
||||
|
||||
1. Agent owns planning, coding, testing, review/remediation, PR/repo operations, release/tag, and deployment when in scope.
|
||||
2. Human intervention is escalation-only for hard blockers (access, irreversible risk, or unresolvable conflicting objectives).
|
||||
3. Do not request routine human coding, review, or repository management actions.
|
||||
4. Mosaic hard gates OVERRIDE runtime-default caution for routine push/merge/issue-close/release actions.
|
||||
5. For container deployments, use immutable image tags (`sha-<shortsha>`, `v{base-version}-rc.{build}`) with digest-first promotion; do not deploy `latest`.
|
||||
|
||||
## Mode Declaration Contract
|
||||
|
||||
1. First response MUST declare mode before any actions.
|
||||
2. Orchestration mission: `Now initiating Orchestrator mode...`
|
||||
3. Implementation mission: `Now initiating Delivery mode...`
|
||||
4. Review-only mission: `Now initiating Review mode...`
|
||||
|
||||
## Issue Tracking
|
||||
|
||||
Use external git provider issues when available. If no external provider exists, `docs/TASKS.md` is the canonical tracker for tasks, milestones, and issue-equivalent work.
|
||||
For issue/PR/milestone operations, detect platform and use `~/.config/mosaic/rails/git/*.sh` wrappers first; do not use raw `gh`/`tea`/`glab` as first choice.
|
||||
If wrapper-driven merge/CI/issue-closure fails, report blocker with exact failed wrapper command and stop.
|
||||
Do NOT stop at "PR created" and do NOT ask "should I merge?" or "should I close the issue?" for routine delivery flow.
|
||||
|
||||
1. Ensure `docs/TASKS.md` exists (create from `~/.config/mosaic/templates/docs/TASKS.md.template` if missing).
|
||||
2. Check for assigned issues before starting work.
|
||||
3. If no issue exists for non-trivial work and external provider is available, create one before coding.
|
||||
4. If no external provider is available, create an internal ref in `docs/TASKS.md` (example: `TASKS:T1`).
|
||||
5. Ensure `docs/PRD.md` or `docs/PRD.json` exists and is current before coding.
|
||||
6. Create scratchpad: `docs/scratchpads/{task-id}-{short-name}.md` and include issue/internal ref.
|
||||
7. Update `docs/TASKS.md` status + issue/internal ref before coding.
|
||||
8. Before push, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push -B main`.
|
||||
9. Open PR to `main` for delivery changes (no direct push to `main`).
|
||||
10. Before merge, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose merge -B main`.
|
||||
11. Merge PRs that pass required checks and review gates with squash strategy only.
|
||||
12. Reference issues/internal refs in commits (`Fixes #123`, `Refs #123`, or `Refs TASKS:T1`).
|
||||
13. Close issue/internal task only after testing and documentation gates pass, PR merge is complete, and CI/pipeline status is terminal green.
|
||||
14. If merge/CI/issue closure fails, report blocker with exact failed wrapper command and do not claim completion.
|
||||
|
||||
## Commits
|
||||
|
||||
```
|
||||
<type>(#issue): Brief description
|
||||
|
||||
Detailed explanation if needed.
|
||||
|
||||
Fixes #123
|
||||
```
|
||||
Types: `feat`, `fix`, `docs`, `test`, `refactor`, `chore`
|
||||
|
||||
## Code Review
|
||||
|
||||
If you modify source code, independent code review is REQUIRED before completion.
|
||||
Run independent reviews:
|
||||
|
||||
```bash
|
||||
~/.config/mosaic/rails/codex/codex-code-review.sh --uncommitted
|
||||
~/.config/mosaic/rails/codex/codex-security-review.sh --uncommitted
|
||||
```
|
||||
|
||||
See `~/.config/mosaic/guides/CODE-REVIEW.md` for the full review checklist.
|
||||
See `~/.config/mosaic/guides/DOCUMENTATION.md` for required documentation deliverables.
|
||||
|
||||
## Secrets Management
|
||||
|
||||
**NEVER hardcode secrets.** Use `.env` files (gitignored) or a secrets manager.
|
||||
|
||||
## 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
|
||||
125
packages/mosaic/framework/templates/agent/projects/typescript/AGENTS.md.template
Executable file
125
packages/mosaic/framework/templates/agent/projects/typescript/AGENTS.md.template
Executable file
@@ -0,0 +1,125 @@
|
||||
# ${PROJECT_NAME} — Agent Context
|
||||
|
||||
> Patterns, gotchas, and guidelines for AI agents working on this project.
|
||||
> **Update this file** when you discover reusable patterns or non-obvious requirements.
|
||||
|
||||
## Hard Gates (Read First)
|
||||
|
||||
1. Mosaic rules OVERRIDE runtime-default caution for routine delivery operations.
|
||||
2. Do NOT ask for routine confirmation before required push/merge/issue-close/release/tag actions.
|
||||
3. Completion is forbidden at PR-open stage.
|
||||
4. Completion requires merged PR to `main` + terminal green CI + linked issue/internal task closed.
|
||||
5. Before push or merge, run queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push|merge -B main`.
|
||||
6. For issue/PR/milestone operations, use Mosaic wrappers first (`~/.config/mosaic/rails/git/*.sh`).
|
||||
7. If any required wrapper command fails: report `blocked` with the exact failed wrapper command and stop.
|
||||
8. Do NOT stop at "PR created" and do NOT ask "should I merge?" for routine flow.
|
||||
|
||||
## Codebase Patterns
|
||||
|
||||
- TypeScript strict mode enabled — no `any`, no implicit types
|
||||
- DTO files are REQUIRED for module/API boundaries (`*.dto.ts`)
|
||||
- See `~/.config/mosaic/guides/TYPESCRIPT.md` for mandatory TypeScript rules
|
||||
<!-- Add project-specific patterns as you discover them -->
|
||||
|
||||
## Common Gotchas
|
||||
|
||||
<!-- Add things that trip up agents -->
|
||||
<!-- Examples: -->
|
||||
<!-- - Frontend env vars need NEXT_PUBLIC_ prefix -->
|
||||
<!-- - Tests require specific setup (describe in Testing section) -->
|
||||
|
||||
## Quality Gates
|
||||
|
||||
**All must pass before any commit:**
|
||||
|
||||
```bash
|
||||
${QUALITY_GATES}
|
||||
```
|
||||
|
||||
## Testing Policy
|
||||
|
||||
1. Situational tests are the PRIMARY validation gate.
|
||||
2. Baseline tests remain REQUIRED for all software changes.
|
||||
3. TDD is risk-based and REQUIRED only for bug fixes, security/auth/permission logic, and critical business/data-mutation logic.
|
||||
4. Reference `~/.config/mosaic/guides/QA-TESTING.md`.
|
||||
|
||||
## PRD Requirement
|
||||
|
||||
1. Before coding begins, `docs/PRD.md` or `docs/PRD.json` MUST exist.
|
||||
2. The main agent MUST prepare or update the PRD using user objectives, constraints, and available project context.
|
||||
3. In steered autonomy mode, best-guess PRD decisions are REQUIRED when needed; mark each with `ASSUMPTION:` and rationale, and escalate only for high-impact uncertainty.
|
||||
4. Reference `~/.config/mosaic/guides/PRD.md`.
|
||||
|
||||
## Task Tracking Contract
|
||||
|
||||
1. For non-trivial implementation work, `docs/TASKS.md` MUST exist before coding.
|
||||
2. If external git provider is available (Gitea/GitHub/GitLab), create/update issue(s) before coding and map them in `docs/TASKS.md`.
|
||||
3. If no external provider is available, use internal refs in `docs/TASKS.md` (example: `TASKS:T1`).
|
||||
4. Keep `docs/TASKS.md` status in sync with actual progress until completion.
|
||||
5. For issue/PR/milestone actions, detect platform and use `~/.config/mosaic/rails/git/*.sh` wrappers first (no raw `gh`/`tea`/`glab` as first choice).
|
||||
6. If wrapper-driven merge/CI/issue-closure fails, report blocker with the exact failed wrapper command and stop (do not claim completion).
|
||||
|
||||
## Documentation Contract
|
||||
|
||||
Documentation is a hard delivery gate.
|
||||
If code/API/auth/infra changes, required documentation updates MUST be completed before task closure.
|
||||
Keep `docs/` root clean and store reports/artifacts in scoped folders (`docs/reports/`, `docs/tasks/`, `docs/releases/`, `docs/scratchpads/`).
|
||||
|
||||
Reference:
|
||||
- `~/.config/mosaic/guides/DOCUMENTATION.md`
|
||||
- `~/.config/mosaic/templates/docs/DOCUMENTATION-CHECKLIST.md`
|
||||
|
||||
## Token Budget Policy
|
||||
|
||||
1. If user plan or token limits are provided, they are HARD constraints.
|
||||
2. Track estimated and used tokens for non-trivial execution.
|
||||
3. Shift to conservative strategy when budget pressure rises (smaller scope, fewer parallel actions, reduced re-reading).
|
||||
4. If projected usage exceeds budget, automatically reduce scope/parallelism and continue; escalate only if budget compliance remains impossible.
|
||||
|
||||
## Merge Strategy (Hard Rule)
|
||||
|
||||
1. Create short-lived branches from `main`.
|
||||
2. Open PRs to `main` for delivery changes.
|
||||
3. Do not push directly to `main`.
|
||||
4. Merge PRs to `main` with squash strategy only.
|
||||
5. Do not mark implementation complete until PR is merged.
|
||||
6. Do not mark implementation complete until CI/pipeline status is terminal green.
|
||||
7. Close linked issues/tasks only after merge + green CI.
|
||||
8. Before push or merge, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push|merge -B main`.
|
||||
|
||||
## Container Release Strategy (When Applicable)
|
||||
|
||||
1. Use immutable image tags: `sha-<shortsha>` and `v{base-version}-rc.{build}`.
|
||||
2. Use mutable environment tags only as pointers (`testing`, optional `staging`, `prod`).
|
||||
3. Deploy/promote by immutable digest; do not deploy by mutable tag alone.
|
||||
4. Do not use `latest` or `dev` as deployment references.
|
||||
5. Use blue-green by default; use canary only with automated metrics and rollback gates.
|
||||
|
||||
## Steered Autonomy Contract
|
||||
|
||||
1. Agent owns end-to-end delivery: plan, code, test, review, remediate, commit, push, PR/repo operations, release/tag, and deployment when in scope.
|
||||
2. Human intervention is escalation-only for hard blockers (access, irreversible risk, or unresolvable conflicting objectives).
|
||||
3. Code review is agent-executed and REQUIRED for any source-code change.
|
||||
|
||||
## Mode Declaration Contract
|
||||
|
||||
1. First response MUST declare mode before any actions.
|
||||
2. Orchestration mission: `Now initiating Orchestrator mode...`
|
||||
3. Implementation mission: `Now initiating Delivery mode...`
|
||||
4. Review-only mission: `Now initiating Review mode...`
|
||||
|
||||
## Key Files
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `tsconfig.json` | TypeScript configuration |
|
||||
| `package.json` | Dependencies and scripts |
|
||||
<!-- Add project-specific key files -->
|
||||
|
||||
## Testing Approaches
|
||||
|
||||
<!-- Document how tests should be written for this project -->
|
||||
<!-- Examples: -->
|
||||
<!-- - Unit tests use Vitest with fixtures -->
|
||||
<!-- - Component tests use React Testing Library -->
|
||||
<!-- - E2E tests use Playwright -->
|
||||
186
packages/mosaic/framework/templates/agent/projects/typescript/CLAUDE.md.template
Executable file
186
packages/mosaic/framework/templates/agent/projects/typescript/CLAUDE.md.template
Executable file
@@ -0,0 +1,186 @@
|
||||
# ${PROJECT_NAME} — Claude Code Instructions
|
||||
|
||||
> **Project:** ${PROJECT_DESCRIPTION}
|
||||
> **Repository:** ${REPO_URL}
|
||||
|
||||
## Conditional Documentation Loading
|
||||
|
||||
**Read the relevant guide before starting work:**
|
||||
|
||||
| Task Type | Guide |
|
||||
|-----------|-------|
|
||||
| End-to-end implementation and validation | `~/.config/mosaic/guides/E2E-DELIVERY.md` |
|
||||
| PRD creation and requirements definition | `~/.config/mosaic/guides/PRD.md` |
|
||||
| Bootstrapping this project | `~/.config/mosaic/guides/BOOTSTRAP.md` |
|
||||
| Orchestrating autonomous tasks | `~/.config/mosaic/guides/ORCHESTRATOR.md` |
|
||||
| Frontend development | `~/.config/mosaic/guides/FRONTEND.md` |
|
||||
| TypeScript strict typing | `~/.config/mosaic/guides/TYPESCRIPT.md` |
|
||||
| Code review | `~/.config/mosaic/guides/CODE-REVIEW.md` |
|
||||
| Documentation updates and standards | `~/.config/mosaic/guides/DOCUMENTATION.md` |
|
||||
| QA/Testing | `~/.config/mosaic/guides/QA-TESTING.md` |
|
||||
|
||||
## Technology Stack
|
||||
|
||||
| Layer | Technology |
|
||||
|-------|------------|
|
||||
| **Language** | TypeScript (strict mode) |
|
||||
| **Framework** | ${FRAMEWORK} |
|
||||
| **Testing** | ${TESTING_STACK} |
|
||||
| **Linting** | ESLint + Prettier |
|
||||
| **Package Manager** | ${PACKAGE_MANAGER} |
|
||||
| **Deployment** | ${DEPLOYMENT_STACK} |
|
||||
|
||||
## Repository Structure
|
||||
|
||||
```
|
||||
${PROJECT_DIR}/
|
||||
├── CLAUDE.md # This file
|
||||
├── AGENTS.md # Agent-specific patterns and gotchas
|
||||
├── src/ # Source code
|
||||
├── tests/ # Test files
|
||||
├── docs/
|
||||
│ ├── PRD.md # Requirements source (or PRD.json)
|
||||
│ └── scratchpads/ # Per-issue working documents
|
||||
└── ${CONFIG_FILES} # Configuration files
|
||||
```
|
||||
|
||||
## Development Workflow
|
||||
|
||||
### Building
|
||||
```bash
|
||||
${BUILD_COMMAND}
|
||||
```
|
||||
|
||||
### Testing
|
||||
```bash
|
||||
${TEST_COMMAND}
|
||||
```
|
||||
|
||||
### Linting & Type Checking
|
||||
```bash
|
||||
${LINT_COMMAND}
|
||||
${TYPECHECK_COMMAND}
|
||||
```
|
||||
|
||||
## Quality Gates
|
||||
|
||||
**All must pass before committing:**
|
||||
|
||||
```bash
|
||||
${QUALITY_GATES}
|
||||
```
|
||||
|
||||
## Testing Policy
|
||||
|
||||
1. Situational tests are the PRIMARY validation gate.
|
||||
2. Baseline tests are REQUIRED for all software changes.
|
||||
3. TDD is risk-based; required cases are defined in `~/.config/mosaic/guides/QA-TESTING.md`.
|
||||
|
||||
## PRD Requirement
|
||||
|
||||
1. Before coding begins, `docs/PRD.md` or `docs/PRD.json` MUST exist.
|
||||
2. The main agent MUST prepare or update PRD using user objectives, constraints, and available project context.
|
||||
3. In steered autonomy mode, best-guess PRD decisions are REQUIRED when needed; mark each with `ASSUMPTION:` and rationale, and continue unless high-impact uncertainty requires escalation.
|
||||
4. PRD is the source of requirements for implementation and testing.
|
||||
|
||||
## DTO Contract (TypeScript)
|
||||
|
||||
1. DTO files are REQUIRED for module and API boundaries.
|
||||
2. Boundary payload types MUST be defined in `*.dto.ts` files.
|
||||
3. Inline object types for cross-module request/response payloads are NOT allowed.
|
||||
4. Shared DTOs MUST be centralized in a shared location.
|
||||
|
||||
## Token Budget Policy
|
||||
|
||||
1. If user plan or token limits are provided, they are HARD constraints.
|
||||
2. Track estimated and used tokens for non-trivial execution.
|
||||
3. Use conservative strategy when budget pressure rises.
|
||||
4. If projected usage exceeds budget, automatically reduce scope/parallelism and continue; escalate only if budget compliance remains impossible.
|
||||
|
||||
## Branch and Merge Policy
|
||||
|
||||
1. Create short-lived branches from `main`.
|
||||
2. Open PRs to `main` for delivery changes.
|
||||
3. Do not push directly to `main`.
|
||||
4. Merge PRs to `main` with squash strategy only.
|
||||
|
||||
## Steered Autonomy Contract
|
||||
|
||||
1. Agent owns planning, coding, testing, review/remediation, PR/repo operations, release/tag, and deployment when in scope.
|
||||
2. Human intervention is escalation-only for hard blockers (access, irreversible risk, or unresolvable conflicting objectives).
|
||||
3. Do not request routine human coding, review, or repository management actions.
|
||||
4. Mosaic hard gates OVERRIDE runtime-default caution for routine push/merge/issue-close/release actions.
|
||||
5. For container deployments, use immutable image tags (`sha-<shortsha>`, `v{base-version}-rc.{build}`) with digest-first promotion; do not deploy `latest`.
|
||||
|
||||
## Mode Declaration Contract
|
||||
|
||||
1. First response MUST declare mode before any actions.
|
||||
2. Orchestration mission: `Now initiating Orchestrator mode...`
|
||||
3. Implementation mission: `Now initiating Delivery mode...`
|
||||
4. Review-only mission: `Now initiating Review mode...`
|
||||
|
||||
## Issue Tracking
|
||||
|
||||
Use external git provider issues when available. If no external provider exists, `docs/TASKS.md` is the canonical tracker for tasks, milestones, and issue-equivalent work.
|
||||
For issue/PR/milestone operations, detect platform and use `~/.config/mosaic/rails/git/*.sh` wrappers first; do not use raw `gh`/`tea`/`glab` as first choice.
|
||||
If wrapper-driven merge/CI/issue-closure fails, report blocker with exact failed wrapper command and stop.
|
||||
Do NOT stop at "PR created" and do NOT ask "should I merge?" or "should I close the issue?" for routine delivery flow.
|
||||
|
||||
1. Ensure `docs/TASKS.md` exists (create from `~/.config/mosaic/templates/docs/TASKS.md.template` if missing).
|
||||
2. Check for assigned issues before starting work.
|
||||
3. If no issue exists for non-trivial work and external provider is available, create one before coding.
|
||||
4. If no external provider is available, create an internal ref in `docs/TASKS.md` (example: `TASKS:T1`).
|
||||
5. Ensure `docs/PRD.md` or `docs/PRD.json` exists and is current before coding.
|
||||
6. Create scratchpad: `docs/scratchpads/{task-id}-{short-name}.md` and include issue/internal ref.
|
||||
7. Update `docs/TASKS.md` status + issue/internal ref before coding.
|
||||
8. Before push, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose push -B main`.
|
||||
9. Open PR to `main` for delivery changes (no direct push to `main`).
|
||||
10. Before merge, run CI queue guard: `~/.config/mosaic/rails/git/ci-queue-wait.sh --purpose merge -B main`.
|
||||
11. Merge PRs that pass required checks and review gates with squash strategy only.
|
||||
12. Reference issues/internal refs in commits (`Fixes #123`, `Refs #123`, or `Refs TASKS:T1`).
|
||||
13. Close issue/internal task only after testing and documentation gates pass, PR merge is complete, and CI/pipeline status is terminal green.
|
||||
14. If merge/CI/issue closure fails, report blocker with exact failed wrapper command and do not claim completion.
|
||||
|
||||
## Commits
|
||||
|
||||
```
|
||||
<type>(#issue): Brief description
|
||||
|
||||
Detailed explanation if needed.
|
||||
|
||||
Fixes #123
|
||||
```
|
||||
Types: `feat`, `fix`, `docs`, `test`, `refactor`, `chore`
|
||||
|
||||
## Code Review
|
||||
|
||||
If you modify source code, independent code review is REQUIRED before completion.
|
||||
Run independent reviews:
|
||||
|
||||
```bash
|
||||
# Code quality review (Codex)
|
||||
~/.config/mosaic/rails/codex/codex-code-review.sh --uncommitted
|
||||
|
||||
# Security review (Codex)
|
||||
~/.config/mosaic/rails/codex/codex-security-review.sh --uncommitted
|
||||
```
|
||||
|
||||
**Fallback:** If Codex is unavailable, use Claude's built-in review skills.
|
||||
See `~/.config/mosaic/guides/CODE-REVIEW.md` for the full review checklist.
|
||||
See `~/.config/mosaic/guides/DOCUMENTATION.md` for required documentation deliverables.
|
||||
|
||||
## 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)
|
||||
```
|
||||
|
||||
## 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
|
||||
Reference in New Issue
Block a user