chore: one version, one schema — repository hygiene for 1.0

[trustlayer-foundationuser]

One version, one schema — repository hygiene for 1.0

The rule applied: the repository presents 1.0 as the version, and only one. With a single exception that is not history but validation authority: schema/aid-v1.2.json stays at its path while a credential in circulation declares it — today, every one issued — because a schema is what issued credentials validate against, and that path is cited from the W3C DID Method Registry. No document speaks of a "preview line" or of "legacy"; the pre-1.0 history lives in the CHANGELOG under its own heading and in the private bundle.

Removed

What	Why
spec/legacy/ (2 files)	Pre-1.0 prose. It is in the private bundle.
schema/aid-v1.1.json, schema/aid-v1.3.json	No live credential declares 1.1; 1.3 was never issued against. (aid-v1.2.json stays: credentials in circulation declare it.)
examples/aid-example-v1.1.json	Example of a schema with no live credentials. (aid-example-v1.2.json stays beside its schema.)
—	The pre-1.0 CHANGELOG entries stay, under "Before 1.0 (pre-release)": a changelog is history and we do not rewrite it.

Renamed and rewritten

Before	Now	Detail
schema/aid-v1.2.json	schema/aid-1.0.json	$id and title at 1.0; spec_version const "1.0"; legalName as an organization name with the natural-person rule (COM-09, L0-03); descriptions without version numbers.
examples/aid-example-v1.2.json	examples/aid-example.json	spec_version: "1.0". Illustrative: its proof value does not verify, and the README says so.
test/fixtures/valid-aid-v15-compat.json	valid-aid-pre-cutover.json	Named for what it is rather than for an internal numbering.
SDK fixtures (7)	regenerated with pnpm run generate-fixtures	Re-signed with the test keys.
examples/atp-policy-example.txt	rewritten	Four ATP/1 examples: three-segment scopes, fresh=, enforce= mandatory, no qualify/ttl, rate marked informative.
schema/atp-policy-v1.json	corrected	ttl removed; fresh added (pattern, default 3600 s, floor 60 s); enforce required; req/deny with the three-segment grammar.
schema/intent-declaration-v1.json	corrected	principal_ref must be a DID (pattern ^did:), never a name — it said "DID or LEI", a neutrality leak inside a schema.
schema/enrollment-manifest-v1.json	descriptions	No version numbers; the ARIA canonicalisation rather than "JCS", which contradicted invariant 3.
examples/verify-example.ts	req: ['commerce:order:*']	It used the dotted form.

Documents

• README — one Version section, the schema and its example, holderKey required, credentialStatus set on every reissue, Evaluate against the configured policy, and a plain paragraph on what the two AID schemas are for.
• spec/README — the 1.0 schema; the Legacy section removed.
• INVARIANTS — §1 rewritten for aid-1.0.json; §11 carries the only rule that holds: the regime is decided by the issuer DID, never by spec_version (the ≥ 1.3 rule would have classified stable 1.0 credentials as pre-release); no link to a private path.
• DEPRECATIONS — the version-label and file-name rows are gone; the MCP resource URIs are described by what the server serves.
• CHANGELOG — [1.0.0] extended with this cleanup, and the earlier entries kept under Before 1.0.
• CONTRIBUTING and CI — no spec/legacy; the neutrality guard excludes only .github, CHANGELOG and DEPRECATIONS.

Added

sdk/verify-ts/test/vector11.test.ts — ATP/1 vector 11 in the form that circulates: the test builds the production composite proofValue (u32be(len) ‖ ML-DSA ‖ Ed25519, base64url) from the fixtures and asserts that tampering with either half is rejected, plus a malformed-length case, and does the same over the separate-field branch the fixtures use. This is the first executable proof that "both halves must pass" is true.

Four corrections made while reviewing this change

The policy schema forbade what ATP/1 requires be ignored. Dropping qualify and ttl while keeping additionalProperties: false turns a reservation into a rejection: a policy carrying qualify= became invalid, where §3 says an unknown parameter is ignored unless written with a leading !, and DEPRECATIONS.md repeats that in this same change. The schema now permits additional properties, declares qualify as reserved so the name stays visible, and states the rule in its own description. ttl stays out: it is retired, not reserved.

The legalName rule was not enforceable and was presented as if it were. aid-1.0.json is the v1.2 shape with a different const: same fields, same required list. The prohibition for natural-person principals lived in a description, with no if/then and nothing a validator reads — and invariant 1 says the schema is the authority and the prose is description. It is now stated as what it is: an issuance rule, with the reason JSON Schema cannot express it (nothing in the document distinguishes an organization from a person), who enforces it, and what a schema-valid but non-conformant document means.

No fixture had the shape the registry issues. The seven regenerated ones declare 1.0, the compatibility fixture declares none, and production issues 1.2 with a composite proofValue. The generator now emits valid-aid-production-form.json in that exact shape, and three tests exercise it: that it verifies, that parseCredential reads the real spec_version, and that revocationStatus comes back unknown. Suite: 51 passing. This absorbs the follow-up the change document left for a separate pull request.

The stable schema is published as a draft, not frozen. Nothing declares 1.0; the Verification Requirements it serves are still v1.3-draft with ten decisions open at TrustLayer Foundation; and fields already planned — a designated successor principal among them — have no place in it. Because credentialSubject declares additionalProperties: false, admitting one later costs a new file and a new spec_version. It is published to be implemented against and freezes the day the first credential declares 1.0. Stated in the file's _status, in invariant 1 and in the README.

No _comment was added to the example: the schema root declares additionalProperties: false and it would have made the example invalid. The warning that its proof does not verify lives in the README.

Kept on purpose, and why it is not stale

Item	Reason
context/v1.jsonld with "@version": 1.1	The JSON-LD 1.1 processing mode, a W3C standard, not an ARIA version. Changing it would break the context.
sdk/verify-ts/package.json at 1.1.0	The npm package's semver, independent of the protocol; npm does not allow going backwards.
schema/*-v1.json	v1 is the schema's major version, consistent with ARIA 1.0.
schema/aid-v1.2.json and its example	Validation authority for the credentials in circulation; the path is cited by the W3C. Retired when the last one expires or is revoked.
pre-cutover comments in the SDK	Production still issues the earlier spec_version until the cutover, and the verifier has to keep accepting those credentials.
termsVersion and privacyVersion in the example	Versions of the registry's Terms and Privacy Policy, not of the protocol.

Dependency on the backend

The 1.0 schema declares spec_version: "1.0"; production still issues "1.2", and those credentials validate against aid-v1.2.json, which stays published. The SDK accepts both. On the day of the cutover, issuance moves to 1.0 with no change here; the 1.2 schema is retired when the last credential declaring it expires or is revoked.

Checks

Five green. Suite 51 passing. Neutrality guard clean.