xytara 3.1.0 → 3.1.2

package/adapters/AUTHORING_GUIDE.md

@@ -1,244 +1,244 @@
-# Adapter Authoring Guide
-
-This guide describes the minimum process for a third party to build an adapter on top of `xytara`.
-
-## 1. Choose an adapter class
-
-Supported starter classes:
-
-- `execution_adapter`
-- `payment_rail_adapter`
-- `settlement_adapter`
-- `agent_protocol_adapter`
-- `identity_registry_adapter`
-
-Pick the class that matches the boundary you are integrating.
-
-## 2. Start from the manifest schema
-
-Use:
-
-- [adapter-manifest.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/adapter-manifest.schema.json)
-- [integration-registration-record.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-registration-record.schema.json)
-- [integration-certification-pack.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-certification-pack.schema.json)
-- [integration-submission-bundle.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-submission-bundle.schema.json)
-- [integration-submission-bundle-set.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-submission-bundle-set.schema.json)
-
-Every adapter must publish a manifest that defines:
-
-- adapter identity
-- adapter class
-- interface version
-- registration contract
-- certification contract
-- compatibility
-- health contract
-- idempotency contract
-- failure contract
-- proof contract
-
-## 3. Implement the interface contract
-
-Use:
-
-- [interfaces.js](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/interfaces.js)
-
-All adapters must provide:
-
-- `manifest`
-- `getHealth()`
-- `describeCapabilities()`
-
-Execution adapters should also provide:
-
-- `preview()`
-- `execute()`
-
-Settlement adapters should also provide:
-
-- `settle()`
-- `getFinality()`
-
-## 4. Start from an example
-
-Current examples:
-
-- [example-execution-adapter.manifest.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-execution-adapter.manifest.json)
-- [example-execution-adapter.js](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-execution-adapter.js)
-- [example-settlement-adapter.manifest.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-settlement-adapter.manifest.json)
-- [example-settlement-adapter.js](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-settlement-adapter.js)
-- [example-third-party-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-registration.submission-bundle.json)
-- [example-third-party-acp-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-acp-registration.submission-bundle.json)
-- [example-third-party-identity-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-identity-registration.submission-bundle.json)
-- [example-third-party-erc8004-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-erc8004-registration.submission-bundle.json)
-- [example-third-party-langchain-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-langchain-registration.submission-bundle.json)
-- [example-third-party-mpp-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-mpp-registration.submission-bundle.json)
-- [example-third-party-settlement-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-settlement-registration.submission-bundle.json)
-
-If you want the shortest reviewable end-to-end path, use:
-
-- [THIRD_PARTY_SUBMISSION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/THIRD_PARTY_SUBMISSION_PROCESS.md)
-
-## 5. Run certification
-
-Run:
-
-```bash
-npm run verify:adapters
-```
-
-That currently validates:
-
-- manifest shape
-- interface version
-- manifest/implementation agreement
-- representative health/capability behavior
-- representative method behavior for example adapters
-
-## 6. Declare registration posture
-
-Each manifest should also declare how the integration is intended to enter runtime selection:
-
-- `registration_contract.integration_id`
-- `registration_contract.integration_maturity`
-- `registration_contract.bundled`
-- `registration_contract.default_selection_enabled`
-- optional selection controls such as priority and explicit-selection posture
-
-This keeps registration explicit and makes future third-party promotion predictable.
-
-## 7. Declare certification posture
-
-Each manifest should say what level of trust it is claiming:
-
-- `reference_example`
-- `self_attested`
-- `certified`
-
-and which checks that claim is based on through:
-
-- `certification_contract.certification_scope`
-- `certification_contract.verified_with`
-- `certification_contract.last_verified_contract_version`
-
-This lets discovery and promotion make trust visible instead of hidden.
-
-## 8. Prepare a registration record
-
-Before an adapter is promoted into staging or production, create a registration record that captures:
-
-- registration state
-- maturity
-- certification state
-- bundled vs third-party posture
-- default-selection posture
-- who registered it and when
-
-Use:
-
-- [integration-registration-record.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-registration-record.schema.json)
-- [example-third-party-registration.record.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-registration.record.json)
-- [example-third-party-settlement-registration.record.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-settlement-registration.record.json)
-
-This keeps promotion explicit and gives future registry services a stable data shape to adopt.
-
-Toolkit helpers are also available in the package surface for registry-side tooling:
-
-- `validateIntegrationRegistration(...)`
-- `validateIntegrationCertificationPack(...)`
-- `validateIntegrationSubmission(...)`
-- `importRegisteredIntegration(...)`
-- `createIntegrationRegistrySnapshot(...)`
-- `exportIntegrationRegistrySnapshot(...)`
-- `validateIntegrationSubmissionBundle(...)`
-- `createIntegrationSubmissionBundle(...)`
-- `importIntegrationSubmissionBundle(...)`
-- `exportIntegrationSubmissionBundles(...)`
-- `createIntegrationRegistrySnapshotFromBundles(...)`
-- `createIntegrationSubmissionBundleSet(...)`
-- `validateIntegrationSubmissionBundleSet(...)`
-- `exportIntegrationSubmissionBundleSet(...)`
-
-That means future registry automation can validate and normalize a manifest + registration-record pair without reimplementing the rules.
-
-## 9. Prepare a certification pack
-
-Before a staged or production registration is trusted, assemble a certification pack that records:
-
-- claimed certification state
-- certification scope
-- verification evidence and reports
-- submission timestamp and operator
-
-Use:
-
-- [integration-certification-pack.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-certification-pack.schema.json)
-- [example-third-party-registration.certification-pack.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-registration.certification-pack.json)
-- [example-third-party-settlement-registration.certification-pack.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-settlement-registration.certification-pack.json)
-
-This keeps certification evidence explicit instead of leaving it as an undocumented side channel.
-
-## 10. Assemble a submission bundle
-
-When you want one reusable handoff artifact for staging or review, combine:
-
-- manifest
-- registration record
-- certification pack
-- optional normalized snapshot entry
-
-Use:
-
-- [integration-submission-bundle.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-submission-bundle.schema.json)
-- [example-third-party-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-registration.submission-bundle.json)
-- [example-third-party-settlement-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-settlement-registration.submission-bundle.json)
-
-This gives future integrations one predictable artifact for authoring review, staging review, or registry import.
-
-Public posture rule:
-
-- native support means `xytara` ships a bundled first-party integration in the registry
-- adapter support means the public contract and authoring path are available for that class or lane
-- third-party plugin posture means the integration should normally enter through explicit submission bundles and staged registration before default rollout
-
-Bundle-driven staging/export is also supported, so a set of reviewed third-party integrations can be turned into a normalized registry snapshot without custom glue code.
-
-If you need to hand off multiple reviewed integrations together, package them as a bundle set rather than inventing a one-off folder convention each time.
-
-Practical rule:
-
-- staged third-party integrations can be visible in discovery
-- staged third-party integrations should normally require explicit selection
-- becoming visible is not the same thing as becoming a default
-
-That keeps reviewable integrations easy to inspect without letting them quietly replace bundled defaults.
-
-## 11. Bundle-set review flow
-
-For a small multi-integration review pass, the clean sequence is:
-
-1. validate each submission bundle
-2. export a submission bundle set
-3. derive a registry snapshot from that reviewed set
-4. only then consider staging or production registration
-
-The repo-local CLI supports that review loop directly when working from a cloned `xytara` repository:
-
-```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 export-bundle-set --notes "review batch"
-node scripts/registry_cli.js export-snapshot
-```
-
-## 12. Keep the boundary clean
-
-Adapters should integrate external systems without redefining:
-
-- proof semantics
-- quote semantics
-- core commerce lifecycle semantics
-
-They translate external systems into the stack contract. They do not replace the stack contract.
+# Adapter Authoring Guide
+
+This guide describes the minimum process for a third party to build an adapter on top of `xytara`.
+
+## 1. Choose an adapter class
+
+Supported starter classes:
+
+- `execution_adapter`
+- `payment_rail_adapter`
+- `settlement_adapter`
+- `agent_protocol_adapter`
+- `identity_registry_adapter`
+
+Pick the class that matches the boundary you are integrating.
+
+## 2. Start from the manifest schema
+
+Use:
+
+- [adapter-manifest.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/adapter-manifest.schema.json)
+- [integration-registration-record.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-registration-record.schema.json)
+- [integration-certification-pack.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-certification-pack.schema.json)
+- [integration-submission-bundle.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-submission-bundle.schema.json)
+- [integration-submission-bundle-set.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-submission-bundle-set.schema.json)
+
+Every adapter must publish a manifest that defines:
+
+- adapter identity
+- adapter class
+- interface version
+- registration contract
+- certification contract
+- compatibility
+- health contract
+- idempotency contract
+- failure contract
+- proof contract
+
+## 3. Implement the interface contract
+
+Use:
+
+- [interfaces.js](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/interfaces.js)
+
+All adapters must provide:
+
+- `manifest`
+- `getHealth()`
+- `describeCapabilities()`
+
+Execution adapters should also provide:
+
+- `preview()`
+- `execute()`
+
+Settlement adapters should also provide:
+
+- `settle()`
+- `getFinality()`
+
+## 4. Start from an example
+
+Current examples:
+
+- [example-execution-adapter.manifest.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-execution-adapter.manifest.json)
+- [example-execution-adapter.js](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-execution-adapter.js)
+- [example-settlement-adapter.manifest.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-settlement-adapter.manifest.json)
+- [example-settlement-adapter.js](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-settlement-adapter.js)
+- [example-third-party-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-registration.submission-bundle.json)
+- [example-third-party-acp-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-acp-registration.submission-bundle.json)
+- [example-third-party-identity-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-identity-registration.submission-bundle.json)
+- [example-third-party-erc8004-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-erc8004-registration.submission-bundle.json)
+- [example-third-party-langchain-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-langchain-registration.submission-bundle.json)
+- [example-third-party-mpp-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-mpp-registration.submission-bundle.json)
+- [example-third-party-settlement-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-settlement-registration.submission-bundle.json)
+
+If you want the shortest reviewable end-to-end path, use:
+
+- [THIRD_PARTY_SUBMISSION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/THIRD_PARTY_SUBMISSION_PROCESS.md)
+
+## 5. Run certification
+
+Run:
+
+```bash
+npm run verify:adapters
+```
+
+That currently validates:
+
+- manifest shape
+- interface version
+- manifest/implementation agreement
+- representative health/capability behavior
+- representative method behavior for example adapters
+
+## 6. Declare registration posture
+
+Each manifest should also declare how the integration is intended to enter runtime selection:
+
+- `registration_contract.integration_id`
+- `registration_contract.integration_maturity`
+- `registration_contract.bundled`
+- `registration_contract.default_selection_enabled`
+- optional selection controls such as priority and explicit-selection posture
+
+This keeps registration explicit and makes future third-party promotion predictable.
+
+## 7. Declare certification posture
+
+Each manifest should say what level of trust it is claiming:
+
+- `reference_example`
+- `self_attested`
+- `certified`
+
+and which checks that claim is based on through:
+
+- `certification_contract.certification_scope`
+- `certification_contract.verified_with`
+- `certification_contract.last_verified_contract_version`
+
+This lets discovery and promotion make trust visible instead of hidden.
+
+## 8. Prepare a registration record
+
+Before an adapter is promoted into staging or production, create a registration record that captures:
+
+- registration state
+- maturity
+- certification state
+- bundled vs third-party posture
+- default-selection posture
+- who registered it and when
+
+Use:
+
+- [integration-registration-record.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-registration-record.schema.json)
+- [example-third-party-registration.record.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-registration.record.json)
+- [example-third-party-settlement-registration.record.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-settlement-registration.record.json)
+
+This keeps promotion explicit and gives future registry services a stable data shape to adopt.
+
+Toolkit helpers are also available in the package surface for registry-side tooling:
+
+- `validateIntegrationRegistration(...)`
+- `validateIntegrationCertificationPack(...)`
+- `validateIntegrationSubmission(...)`
+- `importRegisteredIntegration(...)`
+- `createIntegrationRegistrySnapshot(...)`
+- `exportIntegrationRegistrySnapshot(...)`
+- `validateIntegrationSubmissionBundle(...)`
+- `createIntegrationSubmissionBundle(...)`
+- `importIntegrationSubmissionBundle(...)`
+- `exportIntegrationSubmissionBundles(...)`
+- `createIntegrationRegistrySnapshotFromBundles(...)`
+- `createIntegrationSubmissionBundleSet(...)`
+- `validateIntegrationSubmissionBundleSet(...)`
+- `exportIntegrationSubmissionBundleSet(...)`
+
+That means future registry automation can validate and normalize a manifest + registration-record pair without reimplementing the rules.
+
+## 9. Prepare a certification pack
+
+Before a staged or production registration is trusted, assemble a certification pack that records:
+
+- claimed certification state
+- certification scope
+- verification evidence and reports
+- submission timestamp and operator
+
+Use:
+
+- [integration-certification-pack.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-certification-pack.schema.json)
+- [example-third-party-registration.certification-pack.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-registration.certification-pack.json)
+- [example-third-party-settlement-registration.certification-pack.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-settlement-registration.certification-pack.json)
+
+This keeps certification evidence explicit instead of leaving it as an undocumented side channel.
+
+## 10. Assemble a submission bundle
+
+When you want one reusable handoff artifact for staging or review, combine:
+
+- manifest
+- registration record
+- certification pack
+- optional normalized snapshot entry
+
+Use:
+
+- [integration-submission-bundle.schema.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/integration-submission-bundle.schema.json)
+- [example-third-party-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-registration.submission-bundle.json)
+- [example-third-party-settlement-registration.submission-bundle.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xytara/adapters/examples/example-third-party-settlement-registration.submission-bundle.json)
+
+This gives future integrations one predictable artifact for authoring review, staging review, or registry import.
+
+Public posture rule:
+
+- native support means `xytara` ships a bundled first-party integration in the registry
+- adapter support means the public contract and authoring path are available for that class or lane
+- third-party plugin posture means the integration should normally enter through explicit submission bundles and staged registration before default rollout
+
+Bundle-driven staging/export is also supported, so a set of reviewed third-party integrations can be turned into a normalized registry snapshot without custom glue code.
+
+If you need to hand off multiple reviewed integrations together, package them as a bundle set rather than inventing a one-off folder convention each time.
+
+Practical rule:
+
+- staged third-party integrations can be visible in discovery
+- staged third-party integrations should normally require explicit selection
+- becoming visible is not the same thing as becoming a default
+
+That keeps reviewable integrations easy to inspect without letting them quietly replace bundled defaults.
+
+## 11. Bundle-set review flow
+
+For a small multi-integration review pass, the clean sequence is:
+
+1. validate each submission bundle
+2. export a submission bundle set
+3. derive a registry snapshot from that reviewed set
+4. only then consider staging or production registration
+
+The repo-local CLI supports that review loop directly when working from a cloned `xytara` repository:
+
+```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 export-bundle-set --notes "review batch"
+node scripts/registry_cli.js export-snapshot
+```
+
+## 12. Keep the boundary clean
+
+Adapters should integrate external systems without redefining:
+
+- proof semantics
+- quote semantics
+- core commerce lifecycle semantics
+
+They translate external systems into the stack contract. They do not replace the stack contract.
 

package/adapters/ONBOARDING_POSTURE.md

@@ -1,61 +1,61 @@
-# Adapter Onboarding Posture
-
-This note captures the current intended onboarding flow for third-party adapters.
-
-## Current onboarding path
-
-1. implement adapter against the public interface version
-2. publish a manifest that satisfies the schema
-3. validate implementation behavior with the adapter verifier
-4. confirm compatibility with the current commerce and proof contracts
-5. declare registration and certification posture in the manifest
-6. add the adapter into catalog/runtime registration only after certification passes
-
-## Current registration stance
-
-This repo does not yet provide a full public adapter registry service.
-
-The current posture is:
-
-- adapter manifests and implementations can be authored against the public contract
-- certification begins locally with `npm run verify:adapters`
-- registration posture should be declared explicitly through manifest metadata
-- promotion should also create a normalized registration record
-- runtime registration remains an explicit product step, not an implicit side effect of dropping files into the repo
-
-## Promotion model
-
-Recommended promotion flow:
-
-1. local development
-2. local certification
-3. self-attested or certified manifest posture
-4. registration record creation
-5. staging/runtime integration
-6. production registration
-
-## Review checkpoints
-
-Before a third-party integration is treated as operationally serious, we should be able to answer:
-
-- is it review-ready?
-- is it default-eligible?
-- is it production-default-ready?
-- what blockers are still present?
-
-Those answers should come from the artifact model and review helpers, not from private judgment calls.
-
-Use:
-
-- [THIRD_PARTY_SUBMISSION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xytara/adapters/THIRD_PARTY_SUBMISSION_PROCESS.md)
-
-to keep that process repeatable for external builders and internal reviewers.
-
-## Why this matters
-
-This keeps adapter support:
-
-- flexible
-- testable
-- explicit
-- less likely to drift into hidden private assumptions
+# Adapter Onboarding Posture
+
+This note captures the current intended onboarding flow for third-party adapters.
+
+## Current onboarding path
+
+1. implement adapter against the public interface version
+2. publish a manifest that satisfies the schema
+3. validate implementation behavior with the adapter verifier
+4. confirm compatibility with the current commerce and proof contracts
+5. declare registration and certification posture in the manifest
+6. add the adapter into catalog/runtime registration only after certification passes
+
+## Current registration stance
+
+This repo does not yet provide a full public adapter registry service.
+
+The current posture is:
+
+- adapter manifests and implementations can be authored against the public contract
+- certification begins locally with `npm run verify:adapters`
+- registration posture should be declared explicitly through manifest metadata
+- promotion should also create a normalized registration record
+- runtime registration remains an explicit product step, not an implicit side effect of dropping files into the repo
+
+## Promotion model
+
+Recommended promotion flow:
+
+1. local development
+2. local certification
+3. self-attested or certified manifest posture
+4. registration record creation
+5. staging/runtime integration
+6. production registration
+
+## Review checkpoints
+
+Before a third-party integration is treated as operationally serious, we should be able to answer:
+
+- is it review-ready?
+- is it default-eligible?
+- is it production-default-ready?
+- what blockers are still present?
+
+Those answers should come from the artifact model and review helpers, not from private judgment calls.
+
+Use:
+
+- [THIRD_PARTY_SUBMISSION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xytara/adapters/THIRD_PARTY_SUBMISSION_PROCESS.md)
+
+to keep that process repeatable for external builders and internal reviewers.
+
+## Why this matters
+
+This keeps adapter support:
+
+- flexible
+- testable
+- explicit
+- less likely to drift into hidden private assumptions