singularity/singularity-forge
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
singularity-forge/docs/specs
History
Mikael Hugo 605cd712be refactor: capability-tier isHeavyModelId, search provider registry, frontmatter_version field, schema docs 
- preferences-models.js: replace 6-regex isHeavyModelId() with MODEL_CAPABILITY_TIER
  lookup + regex fallback for unknown models; new models in model-router.js
  are automatically reflected without touching preferences-models.js
- search-the-web/provider.js: replace ~200-line per-provider waterfall with
  PROVIDER_REGISTRY array + firstAvailable()/resolveWithFallback() helpers;
  preserves Tavily→Brave→Serper→Exa→Ollama→MiniMax auto-fallback order
- sf-db.js: bump SCHEMA_VERSION 58→60 (v59 now reachable); add
  frontmatter_version column to tasks table via v60 migration and CREATE
  TABLE definition; wire frontmatter_version into upsertTaskPlanning() SQL
  and .run() params
- task-frontmatter.js: add frontmatterVersion:1 to DEFAULT_TASK_FRONTMATTER,
  add validation block in validateTaskFrontmatter(), add frontmatterVersion
  mapping in taskFrontmatterFromRecord()
- sf-db-migration.test.mjs: update hardcoded version assertion 58→60
- docs/specs/sf-operating-model.md: add Planning Schema section documenting
  the 3-table model (milestones/slices/tasks, their PKs, spec tables, and
  ID naming conventions)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-05-10 23:42:29 +02:00
..
agent-mode-system.md sf snapshot: uncommitted changes after 202m inactivity 2026-05-08 13:31:08 +02:00
README.md sf snapshot: uncommitted changes after 110m inactivity 2026-05-08 00:17:47 +02:00
sf-operating-model.md refactor: capability-tier isHeavyModelId, search provider registry, frontmatter_version field, schema docs 2026-05-10 23:42:29 +02:00
sf-schedule.md Make SF direct command surface baseline 2026-05-08 01:34:07 +02:00

README.md

docs/specs/

Human-readable specifications and exported contracts.

SF plans and executes from .sf, database first. .sf/sf.db is the canonical structured store for initialized repos; .sf/*.md files are working guidance, knowledge, generated projections, or recovery inputs.

docs/specs/ is for humans: reviewable exports, reports, public contracts, and git-history artifacts. SF may read these files as repo evidence during analysis, but any fact required for SF's own future operation must be captured into .sf/DB-backed state before it is treated as operational knowledge.

Generated docs in this directory are allowed to change. That is part of their purpose: Git keeps the human-facing history of exported contracts and reports. SF can keep its own operational history in .sf/SQLite when it needs runtime memory, ledgers, replay, or drift analysis.

What belongs here

  • Long-lived human-readable behavior contracts, APIs, or protocols.
  • Generated or promoted exports from .sf working state.
  • Reports that should be visible in git history for reviewers and future humans.
  • Documents that outlive any single implementation plan but remain downstream from .sf when SF needs to use them operationally.

What does NOT belong here

  • SF working plans, state, knowledge, or task control files. Keep those in .sf and use runtime tools to mutate DB-owned records.
  • Architecture decisions (use docs/adr/).
  • Implementation plans (use docs/plans/).
  • A parallel BASE_SPEC.md or product-spec hierarchy for new SF work.

Naming convention

<topic>.md — e.g., promote-command-spec.md

See also