Skip to content

Commit ccb5442

Browse files
bradygasterCopilotbrady gaster
authored
feat: establish Squad Core, Charter, and draft specification suite (#2069) (#2074)
* feat: formalize Squad charter profile Part of #2069 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> fix: complete charter profile conformance Part of #2069 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> docs: remove specification trailing whitespace Part of #2069 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Source-Commit: d21ab99 * fix: enforce portable charter conformance Part of #2069 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Source-Commit: ab80da1 * fix: complete charter conformance gate Part of #2069 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Source-Commit: f7d430a * fix: enforce charter manifest schema Part of #2069 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Source-Commit: 71634fd * docs: draft Squad specification suite Part of #2069 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> (cherry picked from commit c03ba95) * fix: revise specification suite publication claims Part of #2069 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> (cherry picked from commit f5ced9d) * fix: close specification suite contracts Part of #2069 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> (cherry picked from commit 3a7fb53) * docs: align specification claim boundaries Part of #2069 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * fix: bind Charter claims to immutable revisions Part of #2069 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * docs: clarify specification scope and execution boundaries Part of #2069 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * fix: bind Charter digest to portable checkout bytes Part of #2069 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: brady gaster <bradygaster@github.com>
1 parent 59b0ee3 commit ccb5442

43 files changed

Lines changed: 8306 additions & 176 deletions

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.
Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
---
2+
'@bradygaster/squad-sdk': minor
3+
---
4+
5+
Add the draft `squad-charter/v0.1` artifact profile, explicit conformance profile selection, validation-before-runtime compilation, typed diagnostics and operation-exact capability metadata, canonical and lossless extension-preserving serialization, a schema-defined language-neutral conformance manifest with complete diagnostic coverage, and implementation-independent specification documents.

‎.gitattributes‎

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -56,4 +56,7 @@ Dockerfile.* text eol=lf
5656
# Squad: union merge for append-only team state files
5757
.squad/fact-checker/audit-trail.md merge=union
5858

59-
.github/workflows/*.lock.yml linguist-generated=true
59+
.github/workflows/*.lock.yml linguist-generated=true
60+
61+
# Charter conformance binds exact document bytes across platform checkouts.
62+
docs/specification/charter-v0.1.md text eol=lf

‎docs/specification/README.md‎

Lines changed: 169 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,169 @@
1+
# Squad Specification
2+
3+
**Core version:** 0.1
4+
5+
**Status:** Working Draft
6+
7+
**Draft date:** 2026-09-25
8+
9+
**Working-draft provenance:** [PR #2074](https://github.com/bradygaster/squad/pull/2074)
10+
contains the combined Core, Charter, and suite revision. The suite draft
11+
originated in [PR #2078](https://github.com/bradygaster/squad/pull/2078);
12+
the combined branch preserves its source-commit provenance.
13+
14+
The source index keeps `publication.revision` and `publication.digest` null
15+
while it is a working draft. After review, the exact head SHA is recorded in
16+
the PR body and review report. A publication pipeline may copy the source index
17+
into a release artifact, set `publication.status` to `published`, insert that
18+
already-existing reviewed head SHA, and compute the release artifact digest.
19+
The derived release index is attached to the tag or release; it is not committed
20+
back onto the same commit. This records an immutable revision in the suite
21+
index without a self-referential hash that would invalidate the commit.
22+
23+
Publication metadata is not a conformance-claim binding. Every claimable
24+
profile instead carries a non-null `revision` object in the suite registry and
25+
its executable manifest. For Charter v0.1, that object binds the exact Charter
26+
document bytes and the canonical manifest evidence payload with SHA-256
27+
digests. This makes working-draft claims reproducible while publication
28+
metadata remains null.
29+
30+
**Document class:** Informative registry and navigation index
31+
32+
**Foundation profile:** [Squad Charter Profile v0.1](charter-v0.1.md)
33+
34+
This directory maps a working inventory of stable or observable Squad surfaces,
35+
including composition and initialization capabilities without profiles in
36+
the [artifact inventory](artifact-inventory.md). It does not yet specify the
37+
complete model for how independent Squads compose and interact. Publication
38+
status is independent from maturity: this suite is an unpublished working
39+
draft. Charter is the only profile with executable conformance evidence.
40+
41+
## Maturity taxonomy
42+
43+
The suite uses exactly five maturity values:
44+
45+
| Maturity | Meaning | Claimable |
46+
|---|---|---|
47+
| `executable-normative-draft` | Normative working draft with an executable manifest and schema | Yes, only identifiers declared by that manifest; not published |
48+
| `experimental-normative-draft` | Normative working draft whose rules are exercised only through dependent profiles or partial evidence | No standalone claims |
49+
| `experimental-schema` | Machine-valid schema or fixture, but no complete conformance manifest | No |
50+
| `requirements-draft` | Conceptual and behavioral requirements awaiting portable fixtures | No |
51+
| `informative-draft` | Coverage, observations, or volatile requirements | No |
52+
53+
The document-class vocabulary is `normative-profile`, `normative-schema`,
54+
`requirements`, and `informative`. The only conformance-class vocabulary is
55+
`canonical`, `compatible`, `legacy`, and `runtime`. Implementation roles
56+
(`producer`, `consumer`, `editor`, `validator`, and `executor`) describe what
57+
software does; they are not claims.
58+
59+
Capability identifiers use one grammar:
60+
`squad-<profile>/v<major>.<minor>/<operation>`. The suite defines no `#operation`
61+
alias. A registry entry without an executable manifest has no claimable
62+
capabilities or conformance classes.
63+
64+
## Document registry
65+
66+
`Schema/manifest` uses `schema`, `manifest`, `fixture`, or `none`. Known
67+
deviations are summarized here and expanded in the
68+
[coverage matrix](artifact-inventory.md#known-unstable-and-non-conforming-behavior).
69+
70+
| ID | Maturity / class | Dependencies | Claimable capabilities | Schema/manifest | Implementation status | Known deviations | Reader entry path |
71+
|---|---|---|---|---|---|---|---|
72+
| `squad-core/v0.1` | `experimental-normative-draft` / normative profile | None | None | None | Normative rules are exercised by Charter; no standalone Core manifest | Canonical JSON and standalone Core cases incomplete | [Core](core-v0.1.md), then Charter |
73+
| `squad-interop/v0.1` | `requirements-draft` / requirements | Core | None | Reference evidence schema; no manifest | Schema and example records inform future profile design | No discovery, relational-invariant, or replay corpus | [Interoperability](interoperability-conventions-v0.1.md) |
74+
| `squad-charter/v0.1` | `executable-normative-draft` / normative profile | Core | `squad-charter/v0.1/parse`, `squad-charter/v0.1/validate`, `squad-charter/v0.1/edit`, `squad-charter/v0.1/legacy-consume`, `squad-charter/v0.1/runtime` | Manifest, schema, and immutable revision binding | Parser, validator, editor, compiler, and cases implemented | None registered | [Charter](charter-v0.1.md) |
75+
| `squad-team-routing/v0.1` | `requirements-draft` / requirements | Core, Interop, Charter | None | None | Roster and routing exist in multiple shapes | Fallback and ambiguity differ | [Roster, then routing](team-routing-v0.1.md) |
76+
| `squad-configuration-casting/v0.1` | `requirements-draft` / requirements | Core, Interop, Team/Routing | None | None | Configuration, registry, and history implemented | Legacy shapes and runtime-only keys | [Configuration, casting, provenance](configuration-casting-v0.1.md) |
77+
| `squad-governance-review/v0.1` | `requirements-draft` / requirements | Core, Interop, Team/Routing | None | Reference schema and rejection fixture; no manifest | TypeScript checks exercise implementation expectations only | No portable relational-invariant or transition corpus | [Evidence shape, then promotion criteria](governance-review-v0.1.md) |
78+
| `squad-execution-preferences/v0.1` | `requirements-draft` / requirements | Core, Interop, Charter, Configuration/Casting | None | None | Runtime selection exists | Provider catalogs and fallback are policy | [Execution preferences](execution-preferences-v0.1.md) |
79+
| `squad-planning-activation/v0.1` | `requirements-draft` / requirements | Core, Interop, Team/Routing, Work Lifecycle | None | None | gh-aw planning records exist | Safe-output and limits are provider-specific | [Planning and activation](planning-activation-v0.1.md) |
80+
| `squad-ceremony/v0.1` | `requirements-draft` / requirements | Core, Interop, Team/Routing | None | None | Builder preserves triggers and schedules | Event names, `auto`, and cooldown are unstable | [Ceremonies](ceremony-v0.1.md) |
81+
| `squad-work-lifecycle/v0.1` | `requirements-draft` / requirements | Core, Interop, Team/Routing, Governance | None | None | Neutral state design only | No shared transition traces | [Neutral lifecycle](work-lifecycle-v0.1.md) |
82+
| `squad-work-github/v0.1` | `requirements-draft` / requirements binding | Interop, Work Lifecycle, Governance | None | None | GitHub adapters exist | No deterministic provider transcripts | [GitHub binding](github-work-lifecycle-binding-v0.1.md) |
83+
| `squad-coordination-handoff/v0.1` | `requirements-draft` / requirements | Core, Interop, Team/Routing | None | None | Session and handoff implementations exist | Ordering and recovery are provider-specific | [Coordination](coordination-handoff-v0.1.md) |
84+
| `squad-automation/v0.1` | `requirements-draft` / requirements | Core, Interop, Coordination | None | None | Local and GitHub schedulers exist | Time, retry, and drift evidence differ | [Automation](automation-v0.1.md) |
85+
| `squad-state-memory-requirements/v0.1` | `informative-draft` / informative | Core, Interop | None | None | Several state and memory providers exist | No common authority, recovery, or privacy corpus | [State authority, then memory classification](state-memory-requirements-v0.1.md) |
86+
| `squad-portable-bundle/v1.0` | `informative-draft` / observed implementation surface | Core and Interop rules apply conceptually | None | Tested JSON shape; no published schema or manifest | `squad export` and `squad import` round-trip team, routing, decisions, casting, agents, and skills | Bundle `1.0` does not use Core profile grammar; histories, decisions, skills, and casting policy can contain sensitive data | [Coverage and promotion requirements](artifact-inventory.md#portable-export-and-import-bundle) |
87+
88+
The machine-readable registry is
89+
[`test-fixtures/spec/suite-v0.1/index.json`](../../test-fixtures/spec/suite-v0.1/index.json).
90+
The governance JSON is a reference fixture, not portable conformance evidence.
91+
Charter v0.1 is the only registered profile with a manifest, conformance
92+
classes, capability identifiers, and immutable claim revisions.
93+
94+
## Textual dependency adjacency and DAG
95+
96+
Adjacency list:
97+
98+
```text
99+
squad-core/v0.1 -> []
100+
squad-interop/v0.1 -> [squad-core/v0.1]
101+
squad-charter/v0.1 -> [squad-core/v0.1]
102+
squad-team-routing/v0.1 -> [squad-core/v0.1, squad-interop/v0.1, squad-charter/v0.1]
103+
squad-configuration-casting/v0.1 -> [squad-core/v0.1, squad-interop/v0.1, squad-team-routing/v0.1]
104+
squad-governance-review/v0.1 -> [squad-core/v0.1, squad-interop/v0.1, squad-team-routing/v0.1]
105+
squad-execution-preferences/v0.1 -> [squad-core/v0.1, squad-interop/v0.1, squad-charter/v0.1, squad-configuration-casting/v0.1]
106+
squad-work-lifecycle/v0.1 -> [squad-core/v0.1, squad-interop/v0.1, squad-team-routing/v0.1, squad-governance-review/v0.1]
107+
squad-work-github/v0.1 -> [squad-interop/v0.1, squad-work-lifecycle/v0.1, squad-governance-review/v0.1]
108+
squad-planning-activation/v0.1 -> [squad-core/v0.1, squad-interop/v0.1, squad-team-routing/v0.1, squad-work-lifecycle/v0.1]
109+
squad-ceremony/v0.1 -> [squad-core/v0.1, squad-interop/v0.1, squad-team-routing/v0.1]
110+
squad-coordination-handoff/v0.1 -> [squad-core/v0.1, squad-interop/v0.1, squad-team-routing/v0.1]
111+
squad-automation/v0.1 -> [squad-core/v0.1, squad-interop/v0.1, squad-coordination-handoff/v0.1]
112+
squad-state-memory-requirements/v0.1 -> [squad-core/v0.1, squad-interop/v0.1]
113+
squad-portable-bundle/v1.0 -> [conceptual Core and Interop constraints; no profile claim]
114+
```
115+
116+
DAG reading order:
117+
118+
```text
119+
Core
120+
├── Charter (only claimable profile)
121+
├── Interop requirements and reference schema
122+
│ ├── Team/Routing
123+
│ │ ├── Configuration/Casting
124+
│ │ │ └── Execution Preferences
125+
│ │ ├── Governance
126+
│ │ │ └── Work Lifecycle
127+
│ │ │ ├── GitHub Binding
128+
│ │ │ └── Planning/Activation
129+
│ │ ├── Ceremony
130+
│ │ └── Coordination
131+
│ │ └── Automation
132+
│ └── State/Memory Requirements
133+
└── Portable Bundle observation (applies Core/Interop constraints without a claim)
134+
```
135+
136+
There is no dependency cycle. Provider-neutral requirements precede the GitHub
137+
binding. State authority and memory classification remain separate promotion
138+
tracks. This composition diagram is informative: dependency edges do not confer
139+
transitive capabilities or conformance claims.
140+
141+
## External reference policy
142+
143+
Material external assumptions use stable, versioned, section-level links and
144+
are labeled normative or informative in the document that imports them. Core
145+
[§2](core-v0.1.md#2-normative-references) imports BCP 14, RFC 3339, and
146+
CommonMark 0.31.2. Interoperability
147+
[§10](interoperability-conventions-v0.1.md#10-versioned-references-and-precedents)
148+
and the GitHub binding
149+
[§8](github-work-lifecycle-binding-v0.1.md#8-versioned-provider-assumptions-and-references)
150+
identify their narrower assumptions. An informative precedent does not become
151+
a suite requirement merely by being cited.
152+
153+
`test/specification-suite.test.ts` deterministically checks every Markdown file
154+
in this directory for relative targets, local heading anchors, and absolute
155+
HTTPS external citations. It also verifies every indexed specification,
156+
schema, manifest, and fixture path. The check is intentionally offline:
157+
external URL availability and remote anchor existence remain review-time or
158+
publication-pipeline checks.
159+
160+
## Versioning policy
161+
162+
Profile identifiers use `vMAJOR.MINOR`; mutable state revisions, provider API
163+
versions, implementation versions, and the observed portable-bundle `1.0`
164+
version are distinct. Draft documents may change before promotion. Only a
165+
`publication.status` of `published` denotes an immutable publication; published
166+
normative revisions are immutable except for dated errata, and behavior changes
167+
require a new profile version. Claimable working drafts remain bound to exact
168+
content digests through each profile's `revision` object; mutable branch names,
169+
pull request numbers, and null publication fields are never claim revisions.

0 commit comments

Comments
 (0)