Expose atomic Marten, Wolverine, and integration adapters

[woksin]

Learning

CritterStackScreenplayAdapter currently interprets Marten and Wolverine under one adapter identity, while its generator facade also composes Vogen. This obscures per-framework admission/version/provenance and pressures future stack combinations into facade ownership.

Desired migration

Add atomic classes in the existing package first:

• Marten adapter;
• Wolverine adapter;
• narrow Wolverine–Marten integration adapter for semantics genuinely expressed by integration APIs;
• retain CritterStackScreenplayAdapter and existing generator constructors as compatibility wrappers.

Cross-cutting Vogen/validation/value-object adapters remain independent. Atomic adapters never consume one another; neutral Generation derivation performs source-independent joins.

Acceptance criteria

• Stable distinct adapter identities and implementation versions.
• Each adapter has independent applicability/admission evidence and contribution provenance.
• Marten-only execution cannot run Wolverine interpretation; Wolverine-only execution cannot invent Marten persistence.
• Split-project applications are recognized across the selected application scope.
• Integration adapter covers only exact coupled APIs and has explicit required capabilities.
• Compatibility wrapper produces byte-identical current canonical output/diagnostics.
• Reversed atomic adapter order is byte-identical.
• Duplicate execution/IDs fail before analysis.
• Existing public facade/package API remains source/binary compatible.
• CLI can instantiate the atomic roster exactly once after its profile migration.

Related: Cratis/Screenplay.Generation#17, #29, #3, #4, Cratis/cli#87.

[woksin]

Prepared the atomic split against the current implementation without changing source:

• CritterStackScreenplayAdapter is the only current adapter identity and sequentially runs MartenFacts, MartenDocumentFacts, and WolverineFacts for every project.
• The natural Marten adapter boundary is MartenFacts.Discover() plus MartenDocumentFacts.Discover(); applicability is the existing StoreOptions/IDocumentStore check.
• The natural Wolverine adapter boundary is WolverineFacts.Discover(); applicability is the existing WolverineOptions check.
• Wolverine–Marten coupling is currently embedded in WolverineFacts through the exact Wolverine.Marten/HTTP-Marten aggregate, stream, persistence, and legacy attribute APIs. Those checks must move only when they require capabilities from both frameworks; generic Wolverine handlers, validation, messaging, and HTTP behavior stay Wolverine-owned.
• CritterStackScreenplayGenerator currently defaults to Vogen plus the combined adapter. Its public constructors can remain compatibility facades while the default internal roster becomes Vogen + Marten + Wolverine + exact integration.
• GenerationResolver sorts contributions but does not reject duplicate adapter identities before analysis. The atomic roster needs a pre-analysis identity/instance validation seam rather than relying on downstream fact conflicts.

Implementation order after Generation #24–#26:

1. Add distinct versioned Marten and Wolverine adapters with isolated applicability specs.
2. Extract only exact coupled API discovery into the integration adapter and declare both capabilities as prerequisites.
3. Make the combined adapter delegate to the atomic roster while preserving its public identity/output as the compatibility surface.
4. Prove Marten-only, Wolverine-only, split-project, reversed-order, duplicate-roster rejection, and byte-identical compatibility vectors.
5. Switch CLI construction to the reviewed atomic source roster exactly once; Vogen remains independent and source-only.

[cratis-stagehand]

Thanks for opening this - it has been received and will be looked at.

---

Posted by Stagehand (AI) - an autonomous agent, not a person. Review accordingly.

[woksin]

Dependency update: Generation #23 is complete in 0.16.0 and supplies descriptors, structured probes, duplicate rejection, atomic admission, frozen runs, and dispositions. Atomic Marten/Wolverine/integration adapters should follow Generation #19 for source-independent type-use joins. Generation #24 is a sibling report consumer, not a prerequisite. The compatibility facade and generator constructors remain byte/source/binary parity gates.

[woksin]

Architecture/parity reconciliation

The atomic boundary is now frozen against public main 943f2bb... and the 1,022-spec/zero-warning baseline.

Accepted identities: marten@1.0.0 (EventStore), wolverine@1.0.0 (ApplicationFramework), and wolverine-marten@1.0.0 (Integration), all dual modern/legacy contracts with authored-source/stable-location/semantic-analysis requirements and Generation minimum 0.17. Marten/Wolverine emit granular member/type-use/role facts; no adapter emits TypeUseBinding. Integration applicability requires exact authored allowlisted coupled APIs plus both capability sets across the selected scope.

Ownership is explicit: ordinary Marten declarations/operations/compiled queries remain Marten-owned even inside Wolverine handlers; generic Wolverine/HTTP/messaging/validation/saga/current JasperFx event-stream/DCB behavior remains Wolverine-owned without Marten; only exact Wolverine.Marten.*, Wolverine.Http.Marten.* and legacy Marten handler-binding wrappers are integration-owned. No adapter invokes another.

Compatibility decision: keep the existing parameterless generator and all existing constructors on vogen + cratis.critter-stack so public graph evidence/provenance and compilation-only compatibility remain unchanged. Add an explicit atomic roster path; CLI #95 adopts it after public release. Do not put the compatibility wrapper and atomics in one roster.

Implementation waves: Generation 0.17 lockstep adoption -> replace active local concept binder with unbound aggregate facts + central derivation -> atomic descriptors/probes -> exact integration extraction -> runner-backed roster/duplicate and order gates -> compatibility/canonical/package release. Seven existing source hashes, full diagnostic signatures, public constructors and legacy binary consumer are immutable parity gates.

Two generic Generation gaps are now tracked upstream rather than hidden in CritterStack: inherited member type-use emission in Generation #48 and exact independent entry-point usage joins in Generation #49. Both are stop conditions for claiming full parity; no adapter-order join or local aggregate rewrite is allowed.