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 077fd0a2a7 remove A2A; swarm enrollment + status projection + web swarms view; headless refactor 
- A2A removal per M054/R071 cancellation 2026-05-17 (-2294 lines):
  - docs/plans/A2A_ADOPTION_PLAN.md, MISSION-A2A-ADOPTION.md deleted
  - src/resources/extensions/sf/uok/a2a-agent-server.js,
    a2a-transport.js deleted
  - tests/a2a-auth.test.mjs deleted
  - swarm-dispatch.js purged of A2A-conditional code paths
- New: scripts/sf-swarm-enroll.mjs + test (operator-facing swarm
  enrollment, replaces former A2A pairing flow)
- New: src/status-projection.ts + test, web/lib/swarm-status.ts +
  test, web/components/sf/swarms-view.tsx, web/app/api/swarms/
  (web swarms-view surface — direct visibility into running swarm
  state without requiring TUI; aligns with project_tui_deprecating)
- headless-{answers,query,ui,headless}.ts: coordinated tweaks
  consistent with the headless-as-default direction (R124 proposal)
- docs/dev/drafts/M053-per-repo-supervisor.md: design refinement
- .sf/REQUIREMENTS.md: small text fixes (6/6 churn)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-17 16:04:06 +02:00
..
agent-mode-system.md refactor: align agent resource overlays 2026-05-14 19:32:41 +02:00
README.md sf snapshot: uncommitted changes after 110m inactivity 2026-05-08 00:17:47 +02:00
sf-operating-model.md remove A2A; swarm enrollment + status projection + web swarms view; headless refactor 2026-05-17 16:04:06 +02:00
sf-prompt-modularization.md docs(specs): add sf-prompt-modularization.md operator guide 2026-05-15 19:47:20 +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