singularity/singularity-forge
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
singularity-forge/.sf/NON-GOALS.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.2 KiB
Raw Blame History

Non-goals

  • SF must not ship or revive an MCP server package or runtime endpoint. SF may consume external MCP servers as a client, but its own tools remain native SF/pi tools.
  • Runtime state files under .sf/ must not become a peer source of truth when SQLite can hold the structured state. JSON, JSONL, and Markdown runtime artifacts are generated evidence, projections, or legacy import inputs.
  • Do not design new SF repo state around "maybe no database." Initialized Forge repos always have SQLite; no-DB handling is bootstrap, import, or recovery code.
  • Do not add direct sqlite3 .sf/sf.db workflows to docs or agent guidance. Database access should go through runtime-owned SF commands, tools, or adapters so schema and validation rules stay centralized.
  • Do not commit transient .sf runtime directories such as eval outputs, harness scaffolds, milestone workspaces, locks, journals, or migration worktrees. Promote durable decisions and reviewed plans into docs/.
  • Do not add a second source tree for machine, web, editor, or protocol behavior when the existing axis-owned placement fits. Extend the current surface/protocol/package boundary instead of creating parallel implementations.