examples: add CCS v1.4 composition fixture under examples/ccs/

[DSHCorrectover]

As discussed — the reviewed interoperability fixture, placed under a new examples/ccs/ directory.

Contents:

• vectors.reference.json / upstream-01-allow.receipt.json — byte-identical to the standalone composition harness at 995d803 (conformance/composition/ccs-v14-aeb-github-v0.1/); sha256 3f61bc9e… and 889855dc…
• README.md — provenance, the eight composition cases, and the boundaries:
  • EMILIA-authored compatible fixture, not a Correctover certification or a Correctover-issued upstream vector
  • CCS ALLOW = machine-policy evidence only, never execution authority
  • conformance key 26a02d86… = test material, not a production trust root

Independently verifiable with any standard-library Ed25519 + JCS verifier; no CCS code import required.

Guigui Wang — Correctover, Runtime Verification
cc Iman Schrock

[strix-security]

Strix is installed on this repository, but we couldn't run this PR security review because this workspace's trial has ended. Add a card to resume code reviews here.

So far, Strix has reviewed 68 pull requests, surfaced 13 security issues (8 critical/high) and blocked 8 risky merges across this workspace.

[vercel]

@DSHCorrectover is attempting to deploy a commit to the Future Enterprises Team on Vercel.

A member of the Team first needs to authorize it.

[FutureEnterprises]

Guigui, the vectors, pins, eight outcomes, and product boundaries all check out at head 3822771, and the substantive CI is green. I found one chronology typo before I can approve the exact bytes: the assessment is dated 2026-08-29, while the revision line says v3 supersedes v2 dated 2026-08-30. Please make the assessment date 2026-08-30 (or correct the v2 date if that is the mistaken value). Once that one line is consistent, I can approve the joint bytes.

[DSHCorrectover]

@FutureEnterprises Fixed — thanks for catching the chronology.

The v3 wording was finalized on 2026-08-30 (the three PR commits are dated 2026-08-30 UTC), while v2 reflects the handoff re-run on 2026-08-29. So the mistaken value was the v2 date in the revision line:

• Header Date: set to 2026-08-30 (v3 date)
• v3 supersedes v2 (2026-08-30) → v3 supersedes v2 (2026-08-29)

No other bytes changed: vectors, pins, the eight composition outcomes, bundle counts (489 manifest-covered files / 64 expected-outcome cases), and all product boundaries are untouched. New head: 860575e. Ready for re-review.

[FutureEnterprises]

Confirmed at 860575e: the only change is the two chronology fields in JOINT-ASSESSMENT.md. They now consistently record v3 as 2026-08-30 and v2 as 2026-08-29; the pinned vectors, hashes, eight outcomes, and claim boundaries are unchanged. I approve these exact PR bytes. Before merge, please update the branch from current main and let the strict required checks rerun. The Vercel red is deployment authorization, not a source or test failure.

[DSHCorrectover]

@FutureEnterprises Branch updated from current main (new head 8d52923): the PR's four files are byte-identical to the approved 860575e; the only addition is the main merge, and the merge commit carries a Signed-off-by line. The fork's checks don't execute on the merge commit from our side — could you approve/rerun the strict required checks on the new head? Vercel red understood as deployment authorization only.

[FutureEnterprises]

Guigui, I rechecked head 8d52923. It is current with main, and the four PR files are byte-identical to the approved 860575e. The chronology correction and claim boundaries are intact, so my approval stands. I approved all six waiting workflows on that head, and the strict required checks have started. Auto-merge is enabled with the repository-standard merge commit, so #682 will merge once the protected checks pass. Vercel is unrelated, and no further source changes are needed on your side. Best, Iman