feat: implement docker infrastructure (US-001)
- Add docker-compose.yml with postgres, redis, api, and web services - Add multi-stage Dockerfile for API (Python 3.11) - Add multi-stage Dockerfile for web (Node.js 20 + nginx) - Add Makefile with common development commands - Add .env.example with all required environment variables - Add placeholder pyproject.toml and package.json for builds - Configure health checks for all services - Setup persistent volumes for postgres, redis, and repos - Run services as non-root users
This commit is contained in:
@@ -1,84 +1,97 @@
|
||||
# Agent Instructions
|
||||
# AGENTS.md
|
||||
|
||||
This project uses **bd** (beads) for issue tracking. Run `bd prime` for full workflow context.
|
||||
## Core rule
|
||||
|
||||
## Quick Reference
|
||||
OpenSpec is the source of truth. Superpowers is the default workflow. Keep changes small, scoped, and verified.
|
||||
|
||||
```bash
|
||||
bd ready # Find available work
|
||||
bd show <id> # View issue details
|
||||
bd update <id> --claim # Claim work atomically
|
||||
bd close <id> # Complete work
|
||||
bd dolt push # Push beads data to remote
|
||||
```
|
||||
## Priority order
|
||||
|
||||
## Non-Interactive Shell Commands
|
||||
1. Current user instruction
|
||||
2. OpenSpec proposal, tasks, and spec deltas
|
||||
3. This `AGENTS.md`
|
||||
4. Existing project conventions
|
||||
5. Agent assumptions
|
||||
|
||||
**ALWAYS use non-interactive flags** with file operations to avoid hanging on confirmation prompts.
|
||||
When instructions conflict, follow the higher-priority source. Do not silently expand scope.
|
||||
|
||||
Shell commands like `cp`, `mv`, and `rm` may be aliased to include `-i` (interactive) mode on some systems, causing the agent to hang indefinitely waiting for y/n input.
|
||||
## Default workflow
|
||||
|
||||
**Use these forms instead:**
|
||||
```bash
|
||||
# Force overwrite without prompting
|
||||
cp -f source dest # NOT: cp source dest
|
||||
mv -f source dest # NOT: mv source dest
|
||||
rm -f file # NOT: rm file
|
||||
For any non-trivial change:
|
||||
|
||||
# For recursive operations
|
||||
rm -rf directory # NOT: rm -r directory
|
||||
cp -rf source dest # NOT: cp -r source dest
|
||||
```
|
||||
1. Read the relevant OpenSpec change, tasks, and spec deltas.
|
||||
2. Use `brainstorming` if scope, design, or requirements are unclear.
|
||||
3. Use `writing-plans` before implementation.
|
||||
4. Implement only the selected task or clearly requested change.
|
||||
5. Use tests, typecheck, lint, or targeted checks to verify.
|
||||
6. Use `verification-before-completion` before claiming completion.
|
||||
|
||||
**Other commands that may prompt:**
|
||||
- `scp` - use `-o BatchMode=yes` for non-interactive
|
||||
- `ssh` - use `-o BatchMode=yes` to fail instead of prompting
|
||||
- `apt-get` - use `-y` flag
|
||||
- `brew` - use `HOMEBREW_NO_AUTO_UPDATE=1` env var
|
||||
If namespacing is required, use:
|
||||
|
||||
<!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:ca08a54f -->
|
||||
## Beads Issue Tracker
|
||||
* `superpowers:brainstorming`
|
||||
* `superpowers:writing-plans`
|
||||
* `superpowers:test-driven-development`
|
||||
* `superpowers:systematic-debugging`
|
||||
* `superpowers:verification-before-completion`
|
||||
|
||||
This project uses **bd (beads)** for issue tracking. Run `bd prime` to see full workflow context and commands.
|
||||
## When OpenSpec is required
|
||||
|
||||
### Quick Reference
|
||||
Create or update an OpenSpec change before implementing:
|
||||
|
||||
```bash
|
||||
bd ready # Find available work
|
||||
bd show <id> # View issue details
|
||||
bd update <id> --claim # Claim work
|
||||
bd close <id> # Complete work
|
||||
```
|
||||
* New features
|
||||
* Behavior changes
|
||||
* API changes
|
||||
* Database/schema changes
|
||||
* Auth, security, billing, permissions, or data handling changes
|
||||
* Architecture changes
|
||||
* Large refactors
|
||||
* Anything with unclear acceptance criteria
|
||||
|
||||
### Rules
|
||||
Small local fixes may skip OpenSpec if they do not change behavior or public contracts.
|
||||
|
||||
- Use `bd` for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists
|
||||
- Run `bd prime` for detailed command reference and session close protocol
|
||||
- Use `bd remember` for persistent knowledge — do NOT use MEMORY.md files
|
||||
## Superpowers usage
|
||||
|
||||
## Session Completion
|
||||
Use:
|
||||
|
||||
**When ending a work session**, you MUST complete ALL steps below. Work is NOT complete until `git push` succeeds.
|
||||
* `brainstorming` for ambiguity, design choices, or scope questions.
|
||||
* `writing-plans` for multi-step or multi-file work.
|
||||
* `test-driven-development` for behavior changes and bug fixes where practical.
|
||||
* `systematic-debugging` for failing tests or unclear bugs.
|
||||
* `verification-before-completion` before final completion claims.
|
||||
* `using-git-worktrees` only for isolated risky or parallel work.
|
||||
* `dispatching-parallel-agents` only for independent subtasks with clear boundaries.
|
||||
|
||||
**MANDATORY WORKFLOW:**
|
||||
If a skill is unavailable, follow its intent manually and say so.
|
||||
|
||||
1. **File issues for remaining work** - Create issues for anything that needs follow-up
|
||||
2. **Run quality gates** (if code changed) - Tests, linters, builds
|
||||
3. **Update issue status** - Close finished work, update in-progress items
|
||||
4. **PUSH TO REMOTE** - This is MANDATORY:
|
||||
```bash
|
||||
git pull --rebase
|
||||
bd dolt push
|
||||
git push
|
||||
git status # MUST show "up to date with origin"
|
||||
```
|
||||
5. **Clean up** - Clear stashes, prune remote branches
|
||||
6. **Verify** - All changes committed AND pushed
|
||||
7. **Hand off** - Provide context for next session
|
||||
## Scope discipline
|
||||
|
||||
Do not:
|
||||
|
||||
* Implement outside the selected OpenSpec task.
|
||||
* Mix unrelated cleanup with feature work.
|
||||
* Introduce new dependencies without clear justification.
|
||||
* Treat existing code as more authoritative than OpenSpec for intended behavior.
|
||||
* Decide product behavior silently when the spec is unclear.
|
||||
|
||||
If scope must change, propose an OpenSpec update first.
|
||||
|
||||
## Verification
|
||||
|
||||
Before completion, report:
|
||||
|
||||
* What changed
|
||||
* Which OpenSpec task/change it addresses
|
||||
* Tests/checks run
|
||||
* Any failures, skipped checks, assumptions, or risks
|
||||
|
||||
Do not claim completion without verification evidence.
|
||||
|
||||
## Definition of done
|
||||
|
||||
A task is done when:
|
||||
|
||||
* It matches OpenSpec.
|
||||
* The diff is focused.
|
||||
* Relevant tests/checks passed or limitations are stated.
|
||||
* No unrelated scope was added.
|
||||
* Remaining risks or follow-ups are documented.
|
||||
|
||||
**CRITICAL RULES:**
|
||||
- Work is NOT complete until `git push` succeeds
|
||||
- NEVER stop before pushing - that leaves work stranded locally
|
||||
- NEVER say "ready to push when you are" - YOU must push
|
||||
- If push fails, resolve and retry until it succeeds
|
||||
<!-- END BEADS INTEGRATION -->
|
||||
|
||||
Reference in New Issue
Block a user