More self-explanatory names. No behavioral change — same files, same purpose. - .sf/TASTE.md → .sf/STYLE.md (# Taste → # Style) - .sf/ANTI-GOALS.md → .sf/NON-GOALS.md (# Anti-goals → # Non-goals) - All code references updated: auto-bootstrap-context, system-context, gitignore, milestone-framing-check, scaffold-constants, spec-projections - Section headings injected into agent context updated to match Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
1.1 KiB
1.1 KiB
Style
- Prefer runtime adapters over ad hoc file parsing when reading SF state. For example, query solver eval history through
sf-db.jshelpers rather than reading.sf/evals/**/report.json. - Make DB-backed tools the pleasant path. If a human-readable file mirrors structured state, prefer a tool that mutates the DB and regenerates the file over hand-editing the projection.
- Keep generated artifacts clearly named, ignored, and reproducible. A committed doc should read like reviewed source, not like a cached run output with host-local paths.
- Use precise boundary names in files and symbols. Avoid stale
mcpnames for native workflow tools; reserve MCP wording for client-side integration with external servers. - Make migrations one-way and observable. Legacy JSON, JSONL, or Markdown should be imported into SQLite with schema/version checks, then left as ignored fallback or removed when the cutover is complete.
- Prefer product terms that reveal the axis: surface, protocol, output format, run control, permission profile. Do not use
headless, JSON, or autonomous as catch-all words when a narrower term fits.