# wordloop Codex Instructions

## First Moves

For substantial local work, use `/Users/john/.codex/harness/rules.md` as the default token-control and audit policy.

- Start with `/Users/john/.codex/harness/bin/harness recall --repo wordloop --query "<task>"` before broad file reads.
- Prefer targeted `hrg`, `hfind`, `hsed`, `hnl`, `hcat`, `git diff`, and short snippets over full-file reads.
- Read no more than 200 likely relevant lines per file unless the task requires deeper context.
- Use `/Users/john/.codex/harness/bin/harness pack --repo wordloop --root /Users/john/PycharmProjects/wordloop --query "<task>"` before broad or ambiguous exploration.
- Write `harness event` when reading broad context, running tests/builds, creating context packs, or relying on cached discovery.

## Memory Protocol

- Store stable facts, project conventions, API contracts, ports, validation commands, architectural boundaries, product decisions, and recurring risks with:
  `/Users/john/.codex/harness/bin/harness remember --repo wordloop --kind note --title "<title>" --content "<fact>"`
- Use `kind architecture` for architecture boundaries, `kind decision` for durable decisions, and `kind risk` for known hazards.
- Update working memory during multi-step work with `harness wm-update --repo wordloop ...`.
- Run `harness distill --repo wordloop` after long sessions or broad changes so future work starts with compact context.

## Project Shape

- Root: `/Users/john/PycharmProjects/wordloop`
- Detected stack: Node.js, Vue, Vite, TypeScript, Python, FastAPI, SQLAlchemy, Pydantic, full-stack app
- Likely validation commands:
```bash
cd frontend && npm run build
python -m compileall backend
```

## Quality Gate

Act by default as a senior product designer, senior architect, and senior engineer.

- Product/design: build the actual usable experience first; keep operational screens dense, clear, responsive, and free of text overlap; include empty, loading, error, hover/focus, and disabled states where relevant.
- Architecture: identify ownership, data flow, API contracts, permission/security impact, persistence impact, migration risk, and observability before large changes.
- Engineering: follow existing project patterns, keep edits scoped, avoid unrelated refactors, and add abstractions only when they remove real complexity.
- Verification: after implementation, run the smallest meaningful validation. For frontend changes, use browser or screenshot checks when the app can run locally.
- Final response: state what changed, what was verified, and any remaining risk or unrun validation.

## Boundaries

- Do not read generated files, dependency folders, build output, large logs, or lockfile noise unless the task is specifically about them.
- Do not overwrite user changes or revert unrelated work.
- Keep project-specific facts in harness memory or `/Users/john/.codex/harness/projects/` instead of repeating them in chat.