test: gate platform support claims with native Claude and Codex journey receipts

Problem and evidence

Committed native receipts and the public v4.23.4 release receipt establish specific macOS journeys, including bidirectional PostgreSQL handoff, project exclusion and automatic startup context. The v4.23.4 receipt also records an initial discovery failure before a successful fresh-session attempt. verify_mcp_hosts starts the real server but varies client names; it does not execute native host lifecycle events. Main CI includes Linux and selected Windows tests, with no macOS job in this workflow. Green CI does not establish the full native matrix.

Main CI run38035783094 is green at 02c3cf0. Separate platform audit run38008915302 fails Windows/macOS at another SHA. Those failures cannot be counted as current-main failures without replay.

Acceptance evidence

Owner scope decision, October 10: this workspace performs macOS corrections and native Claude/Codex verification. The owner's collaborator performs Windows verification with the same acceptance contract. Linux qualification is deferred and must not block a macOS-qualified release. Keep each platform's measured status explicit; no Windows or Linux conformance is inferred from macOS results.

Enumerate supported OS/architecture, client version, backend and install-channel combinations, labeling unmeasured cells.
Retain native receipts for blind cross-host transfer, project exclusion, startup context, capture and session persistence.
Include actual compaction/recovery, hook trust state, Unicode, dependency failure and clean teardown.
Validate representative tool outputs after SDK conversion in each client, including empty/error results.
Gate support claims on required receipts tied to artifact digests.

Scope and related work

#692/#693 cover Windows suite debt/order dependence; #720 covers memory evaluation. This owns installed-product native lifecycle acceptance.

Raised by the global Hindsight/Cortex audit. The target is a measurable local-first experience with the same supported semantics in Claude and Codex. Acceptance criteria describe a target, not current conformance. Static findings refer to the pinned source; probes identify their boundary.

Primary references

Public v4.23.4 native receipt; scripts/verify_mcp_hosts.py:2; .github/workflows/ci.yml:378; docs/verification/claude-codex-handoff-2026-09-22/README.md:3; docs/verification/codex-hooks-20261002.md:48

Tranche 1 proposée dans #891 (commit 4fa01aa, Refs #730) : docs/audits/platform-support-matrix-2026-11-05.md liste les combinaisons OS/architecture × hôte × backend × canal d'installation et étiquette chaque cellule par le reçu qui la mesure. Mesuré : quatre parcours natifs macOS (dont un seul lié à l'artefact publié 4.23.4), la sonde d'installation CI sur ubuntu-26.04, macos-26-arm64 et windows-2025-vs2026 (run 42058911839), le cycle de vie PostgreSQL géré d'ADR-1114. Aucun parcours natif Windows, Linux ou .mcpb n'a de reçu ; l'architecture des reçus N1 et N2 n'y est pas enregistrée.

Tranches restantes :

Un schéma de reçu qui lie chaque check natif au digest de l'artefact exécuté (commun avec release: bind parity claims to the distributed plugin and runtime artifacts #729).
Un gate qui refuse une affirmation de support (README, notes de version) sans reçu courant de ce schéma.
Les reçus natifs des cellules exigées par le périmètre du propriétaire : Windows (collaborateur), puis macOS x86_64 et .mcpb.

Generated by Claude Code

fixup! docs(audit): which platform combinations a receipt measures (#730

docs(audit): which platform combinations a receipt measures (#730, sl…

Autopilot : tranche 2 dans #948 (Refs #730, pas Closes, commit 7b4aba2).

scripts/native_receipt.py valide le schéma cortex-native-receipt/1. Chaque check d'un reçu natif porte l'hôte qui l'a lancé et le members_digest de l'artefact exécuté, le digest que calcule cortex doctor (#729). Ce digest doit être égal à celui de l'artefact du reçu, donc un reçu ne peut plus mélanger des checks lancés sur deux artefacts ou deux hôtes. Le rapport distingue la preuve distribuée (wheel non modifiée) de la preuve source, et liste les parcours exigés ici qui sont passés, échoués ou absents. Tests : 13 passés. Non vérifié : la suite complète en local (torch non téléchargeable dans cet environnement).

Tranches restantes :

Le gate qui refuse une affirmation de support (README, notes de version) pour une cellule sans reçu courant de ce schéma.
Un producteur de reçu qui lit l'identité d'artefact directement (aujourd'hui, le doctor la rend en texte libre).
Les reçus natifs des cellules — exigées par le périmètre du propriétaire : Windows (collaborateur), puis macOS x86_64 et .mcpb.

Generated by Claude Code

fixup! feat(verification): native receipts bind each check to the art…

feat(verification): native receipts bind each check to the artifact d…

Merge main into fix/729-manifest-artifact-identity

docs(changelog): record the native receipt artifact producer (#730)

Autopilot : tranche 3 dans #957 (Refs #730, pas Closes, commits c797134 et 6eab4a0).

La tranche restante n° 2 est traitée : un producteur de reçu lit l'identité d'artefact comme une donnée. mcp_server/doctor_artifact.py calcule maintenant un Identity structuré, et le texte du check doctor ne change pas. scripts/native_receipt_artifact.py imprime l'objet artifact d'un reçu cortex-native-receipt/1, validé par le schéma. Il refuse quand l'identité ne peut pas être établie : git en échec, RECORD absent, aucune version installée, ou checkout sans commit.

Reçus :

184 tests passés, dont 14 nouveaux ; ruff et le gate craftsmanship passent.
Une roue construite depuis ce commit, lancée par le producteur, donne le même digest que le doctor sur l'arbre source (84a5e063…).

Non vérifié : la suite complète, car torch n'est pas téléchargeable ici.

Tranches restantes :

Le gate qui refuse une affirmation de support pour une cellule sans reçu courant.
Les reçus natifs des cellules — : Windows (collaborateur), macOS x86_64, .mcpb.

Generated by Claude Code

fixup! feat(verification): a native receipt's artifact object is prod…

feat(verification): a native receipt's artifact object is produced fr…

Autopilot : #730 en attente d'une décision (autopilot:hold).

Les trois tranches livrées sont fusionnées :

docs(audit): which platform combinations a receipt measures (#730, slice 1) #891 : la matrice des cellules mesurées.
feat(verification): native receipts bind each check to the artifact digest it ran (#730) #948 : le schéma cortex-native-receipt/1.
feat(verification): a native receipt's artifact object is produced from the doctor's identity (#730) #957 : le producteur d'identité d'artefact.

Il reste deux tranches, et aucune ne se fait sans décision humaine.

1. Le gate des affirmations de support. Il ne peut refuser une affirmation que si elle existe sous une forme lisible par une machine. Aujourd'hui, aucune n'existe : docs/audits/platform-support-matrix-2026-11-05.md dit explicitement « This document makes no support claim », et le README n'a pas de cellule de support structurée. À trancher :

(a) Où se déclare une cellule revendiquée ? Une possibilité est un manifeste versionné, par exemple docs/support-claims.json : OS/arch × hôte × canal × backend, avec pour chaque cellule les identifiants exigés de native_receipt.REQUIRED_CHECKS. Une autre est une section balisée du README ou des notes de version.
(b) Où vivent les reçus qui font foi ? Committés sous docs/verification/, ou bien assets de release.
(c) Qu'est-ce qu'un reçu « courant » ? Un members_digest égal à celui de l'artefact publié de la version en cours ? Ou suffit-il de la même version ?
(d) Où le gate s'exécute-t-il ? Le job de release doit l'appeler. Cela demande d'éditer .github/workflows, ce que le token de cette routine ne peut pas faire.

2. Les reçus natifs des cellules —. Windows (collaborateur), macOS x86_64 et .mcpb demandent du matériel et des hôtes installés, que cet environnement n'a pas.

Dès que (a) à (c) sont tranchés dans un commentaire, la routine peut livrer le script du gate et ses tests. Le branchement dans le workflow resterait un diff proposé.

Generated by Claude Code

Décision : cette issue n'attend plus de réponse du propriétaire.

Le propriétaire a demandé le 12 novembre 2026 que les issues avancent sans lui ; il ne répondra pas aux questions posées ici. Ce commentaire de cdeust lève le hold et précise la demande. Il vaut pour toute la suite de cette issue.

Tranche toi-même chaque question restée ouverte : d'abord une décision écrite et acceptée du dépôt (ADR accepté, docs/), puis ce que le texte de l'issue propose ou exclut, puis les standards du dépôt ; à défaut, la plus petite tranche qui réalise ce que l'issue demande. Une valeur qui manque se mesure, elle ne s'invente pas.
Écris la décision dans un commentaire marqué  (ce qui est retenu, la raison et sa source, ce qui est écarté, comment revenir en arrière), puis livre la tranche dans une PR. Une décision écrite ne se rejoue pas aux passages suivants.
Ne repose pas autopilot:hold pour une question : seulement pour l'irréversible, un accès que tu n'as pas, une dépendance nommée encore ouverte ou le plafond de tentatives, en nommant exactement ce qui manque.
Jamais de tag, de release, de montée de version du projet ni de déclenchement manuel d'un workflow.

Règle complète : #343 (comment)

Écrit par la session « écosystème autonome » sur instruction du propriétaire (12 novembre 2026).

Generated by Claude Code

Hold autopilot:hold levé : un commentaire de cdeust (« Décision : cette issue n'attend plus de réponse du propriétaire », 12/11/2026) a été posté après la pose du hold.

Generated by Claude Code

Navigation Menu

Repository navigation

test: gate platform support claims with native Claude and Codex journey receipts #730

Problem and evidence

Acceptance evidence

Scope and related work

Primary references

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

test: gate platform support claims with native Claude and Codex journey receipts #730

Description

Problem and evidence

Acceptance evidence

Scope and related work

Primary references

Activity

cdeust commented on Nov 5, 2026

cdeust commented on Nov 7, 2026

cdeust commented on Nov 10, 2026

cdeust commented on Nov 10, 2026

cdeust commented on Nov 12, 2026

cdeust commented on Nov 12, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions