xytara 3.1.0 → 3.1.2

package/adapters/THIRD_PARTY_SUBMISSION_PROCESS.md

@@ -1,84 +1,84 @@
-# Third-Party Submission Process
-
-This note is the shortest end-to-end path for a third party building on `xytara`.
-
-## Goal
-
-Produce one reviewable integration package that can move from local development to staging review without inventing custom process per adapter.
-
-## Submission artifact stack
-
-Every serious third-party integration should converge on four artifacts:
-
-1. adapter manifest
-2. registration record
-3. certification pack
-4. submission bundle
-
-If multiple integrations are being reviewed together, package them as a submission bundle set.
-
-## Recommended flow
-
-1. Choose the adapter class.
-2. Implement the adapter against the public interface contract.
-3. Build the manifest against the public schema.
-4. Run local verification with `npm run verify:adapters`.
-5. Create the registration record.
-6. Create the certification pack.
-7. Assemble the submission bundle.
-8. Review the bundle locally.
-9. Export a bundle set if multiple integrations are being reviewed together.
-10. Derive a registry snapshot from the reviewed bundle set.
-11. Only then consider staging registration or production-default promotion.
-
-## Review commands
-
-From a cloned `xytara` repo:
-
-```bash
-node scripts/registry_cli.js validate-bundle --example protocol
-node scripts/registry_cli.js validate-bundle --example identity
-node scripts/registry_cli.js validate-bundle --example settlement
-node scripts/registry_cli.js review-bundle --example protocol
-node scripts/registry_cli.js review-bundle --example identity
-node scripts/registry_cli.js review-bundle --example settlement
-node scripts/registry_cli.js review-bundle-set --notes "review batch"
-node scripts/registry_cli.js review-snapshot
-node scripts/registry_cli.js promotion-readiness --integration partner.protocol.acme_mcp
-```
-
-## Promotion posture
-
-These states should stay explicit:
-
-- `review_ready`
-- `default_eligible`
-- `production_default_ready`
-
-Typical staged third-party posture:
-
-- discoverable: yes
-- reviewable: yes
-- explicitly selectable: yes
-- default-eligible: no
-- production-default-ready: no
-
-That is the safe default. Promotion should be intentional.
-
-## What not to do
-
-- Do not assume discovery means default selection.
-- Do not skip the registration record and jump straight from manifest to runtime use.
-- Do not treat certification evidence as an undocumented side channel.
-- Do not add adapter-specific workflow rules when the registry model can already express the posture.
-
-## Clean handoff rule
-
-If another team receives only the submission bundle and bundle-set artifacts, they should still be able to:
-
-- validate the integration
-- inspect the claimed posture
-- understand blockers
-- derive a normalized registry snapshot
-
-That is the standard we want to preserve as the integration surface grows.
+# Third-Party Submission Process
+
+This note is the shortest end-to-end path for a third party building on `xytara`.
+
+## Goal
+
+Produce one reviewable integration package that can move from local development to staging review without inventing custom process per adapter.
+
+## Submission artifact stack
+
+Every serious third-party integration should converge on four artifacts:
+
+1. adapter manifest
+2. registration record
+3. certification pack
+4. submission bundle
+
+If multiple integrations are being reviewed together, package them as a submission bundle set.
+
+## Recommended flow
+
+1. Choose the adapter class.
+2. Implement the adapter against the public interface contract.
+3. Build the manifest against the public schema.
+4. Run local verification with `npm run verify:adapters`.
+5. Create the registration record.
+6. Create the certification pack.
+7. Assemble the submission bundle.
+8. Review the bundle locally.
+9. Export a bundle set if multiple integrations are being reviewed together.
+10. Derive a registry snapshot from the reviewed bundle set.
+11. Only then consider staging registration or production-default promotion.
+
+## Review commands
+
+From a cloned `xytara` repo:
+
+```bash
+node scripts/registry_cli.js validate-bundle --example protocol
+node scripts/registry_cli.js validate-bundle --example identity
+node scripts/registry_cli.js validate-bundle --example settlement
+node scripts/registry_cli.js review-bundle --example protocol
+node scripts/registry_cli.js review-bundle --example identity
+node scripts/registry_cli.js review-bundle --example settlement
+node scripts/registry_cli.js review-bundle-set --notes "review batch"
+node scripts/registry_cli.js review-snapshot
+node scripts/registry_cli.js promotion-readiness --integration partner.protocol.acme_mcp
+```
+
+## Promotion posture
+
+These states should stay explicit:
+
+- `review_ready`
+- `default_eligible`
+- `production_default_ready`
+
+Typical staged third-party posture:
+
+- discoverable: yes
+- reviewable: yes
+- explicitly selectable: yes
+- default-eligible: no
+- production-default-ready: no
+
+That is the safe default. Promotion should be intentional.
+
+## What not to do
+
+- Do not assume discovery means default selection.
+- Do not skip the registration record and jump straight from manifest to runtime use.
+- Do not treat certification evidence as an undocumented side channel.
+- Do not add adapter-specific workflow rules when the registry model can already express the posture.
+
+## Clean handoff rule
+
+If another team receives only the submission bundle and bundle-set artifacts, they should still be able to:
+
+- validate the integration
+- inspect the claimed posture
+- understand blockers
+- derive a normalized registry snapshot
+
+That is the standard we want to preserve as the integration surface grows.