singularity-forge/.sf/STYLE.md
Mikael Hugo 702ec3fc0e refactor(sf): rename guidance files TASTE.md→STYLE.md, ANTI-GOALS.md→NON-GOALS.md
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>
2026-05-10 21:28:31 +02:00

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.js helpers 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 mcp names 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.