|
| 1 | +# Agent Instructions |
| 2 | + |
| 3 | +These instructions apply to Codex and other LLM coding agents working in this repository. |
| 4 | + |
| 5 | +## Coding Standards |
| 6 | + |
| 7 | +- Read `README.md`, `tasks.md`, `docs/architecture.md`, and the docs relevant to the current task before editing. |
| 8 | +- Keep each implementation step small and aligned with the V1/V2/V3 roadmap. |
| 9 | +- Prefer typed contracts and explicit validation over ad hoc objects. |
| 10 | +- Keep SQL out of route handlers when backend code is added; use repository or service modules. |
| 11 | +- Use parameterized SQL only. Never concatenate user input into SQL. |
| 12 | +- Treat missing data as unknown, not as zero, unless zero is semantically correct. |
| 13 | +- Keep application logic deterministic where user decisions depend on ranking, sorting, filtering, or scoring. |
| 14 | + |
| 15 | +## Validation Commands |
| 16 | + |
| 17 | +Real commands will be added as the apps are implemented. Expected future commands: |
| 18 | + |
| 19 | +```powershell |
| 20 | +cd apps/web; pnpm lint; pnpm build |
| 21 | +cd apps/api; pytest |
| 22 | +pnpm exec playwright test |
| 23 | +``` |
| 24 | + |
| 25 | +Until those runtimes exist, validate foundation changes with: |
| 26 | + |
| 27 | +```powershell |
| 28 | +Get-ChildItem -Recurse -File |
| 29 | +``` |
| 30 | + |
| 31 | +## Documentation Update Rules |
| 32 | + |
| 33 | +- Update `tasks.md` whenever a roadmap item changes status. |
| 34 | +- Update `docs/api-contract.md` in the same change as any endpoint contract. |
| 35 | +- Update `docs/data-dictionary.md` in the same change as schema, seed, or data-source changes. |
| 36 | +- Update `docs/scoring-methodology.md` in the same change as ranking or explanation logic. |
| 37 | +- Update `docs/deployment.md` when infrastructure, environment variables, or deployment steps change. |
| 38 | +- Do not claim measured performance, users, uptime, or deployment status unless those facts have been verified. |
| 39 | + |
| 40 | +## LLM Guardrails |
| 41 | + |
| 42 | +- Do not build V2 or V3 features before the required V1 foundation is stable. |
| 43 | +- Do not invent college facts, data-source freshness, performance numbers, users, or deployment status. |
| 44 | +- Do not present the product as admissions advice, guaranteed ROI, or financial advice. |
| 45 | +- Do not store sensitive student details without clear product boundaries and privacy documentation. |
| 46 | +- Prefer fixtures, seed data, tests, and typed schemas over mock-only demos. |
| 47 | + |
| 48 | +## Ranking and Generated Text |
| 49 | + |
| 50 | +Keep deterministic ranking separate from LLM-generated text. |
| 51 | + |
| 52 | +- Ranking scores, sort order, category scores, confidence, reason codes, and tradeoffs must come from deterministic code and structured data. |
| 53 | +- LLM-generated text may later summarize known deterministic outputs, but it must not create school facts, change scores, decide rankings, or hide missing data. |
| 54 | +- Every ranking logic change must update the scoring methodology docs and use a versioned ranking constant once the ranking engine exists. |
0 commit comments