wordloop/AGENTS.md

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:

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.