e76fa586f1
Ship dual-track learning (daily accumulation vs textbook),沪教/商务词书 APIs and UI, native iOS wrapper with bundled H5, and production book import on deploy. Co-authored-by: Cursor <cursoragent@cursor.com>
46 lines
2.9 KiB
Markdown
46 lines
2.9 KiB
Markdown
# 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.
|