-
Notifications
You must be signed in to change notification settings - Fork 296
[EPIC] Replace vendor-to-vendor translation with OpenAPM semantic models #2112
Copy link
Copy link
Open
0 / 70 of 7 issues completedOpen
0 / 70 of 7 issues completed
Copy link
Labels
area/multi-targetMulti-target deploy spec, target directory creation, agent surface routing.Multi-target deploy spec, target directory creation, agent surface routing.priority/highShips in current or next milestoneShips in current or next milestonestatus/acceptedDirection approved, safe to start work.Direction approved, safe to start work.status/triagedInitial agentic triage complete; pending maintainer ratification (silence = approval).Initial agentic triage complete; pending maintainer ratification (silence = approval).theme/governanceGoverned by policy. apm-policy, audit, enforcement, enterprise rollout.Governed by policy. apm-policy, audit, enforcement, enterprise rollout.theme/portabilityOne manifest, every target. Multi-target deploy, marketplace, packaging, install.One manifest, every target. Multi-target deploy, marketplace, packaging, install.type/architectureDesign-impacting change (new module, pattern, contract).Design-impacting change (new module, pattern, contract).
Description
Metadata
Metadata
Assignees
Labels
area/multi-targetMulti-target deploy spec, target directory creation, agent surface routing.Multi-target deploy spec, target directory creation, agent surface routing.priority/highShips in current or next milestoneShips in current or next milestonestatus/acceptedDirection approved, safe to start work.Direction approved, safe to start work.status/triagedInitial agentic triage complete; pending maintainer ratification (silence = approval).Initial agentic triage complete; pending maintainer ratification (silence = approval).theme/governanceGoverned by policy. apm-policy, audit, enforcement, enterprise rollout.Governed by policy. apm-policy, audit, enforcement, enterprise rollout.theme/portabilityOne manifest, every target. Multi-target deploy, marketplace, packaging, install.One manifest, every target. Multi-target deploy, marketplace, packaging, install.type/architectureDesign-impacting change (new module, pattern, contract).Design-impacting change (new module, pattern, contract).
Type
Fields
No fields configured for issues without a type.
Projects
StatusShow more project fields
Todo
Is your feature request related to a problem? Please describe.
APM currently mixes target routing, schema normalization, default injection, and loss inside individual integrators. Some paths use one vendor's shape as the pivot for another vendor. This can make APM a permanent inter-vendor translation layer, hide semantic loss from operators, increase maintenance cost, and encourage vendor-specific schemas to become de facto standards.
Describe the solution you'd like
Adopt the approved standards-first architecture in
docs/superpowers/specs/2026-07-10-openapm-standards-first-translation-design.md(design commit12a384227).APM will keep vendor-native import compatibility but normalize imports into small, immutable, versioned semantic models owned by OpenAPM. Each target renderer will consume only the primitive model, validate target capabilities, preserve the existing deny-wins executable trust gate, and return machine-readable transformation accounting. Unsupported required semantics fail clearly; vendor-only behavior remains available through explicit target-native declarations and is never cross-translated.
flowchart LR OA[OpenAPM declaration] --> IR[Per-primitive semantic model] VI[Vendor-native import] --> IA[Named import adapter] IA --> IR IR --> CV[Capability validation] CV --> TG[Executable trust gate] TG --> TR[Independent target renderer] TR --> VF[Canonical vendor file] TR --> RR[RenderResult] RR --> DC[DiagnosticCollector and CommandLogger]There are deliberately no vendor-to-vendor edges:
flowchart TD F[Shared transformation and loss-report foundation] --> H[Hooks proving slice] F --> C[Commands] F --> M[MCP and environment semantics] F --> I[Instructions and rules] F --> A[Agents] F --> P[Plugin import and export] H --> P2097[Rework PR 2097] H --> P2095[Rework PR 2095]One-release-cycle timeline
RenderResult, capability registry, diagnostics, characterization fixturesIf the foundation slips past the release-cycle boundary, PR #2097 and PR #2095 may land only as minimal, named compatibility bridges. Their migration to HookIR is then mandatory in the following minor release.
Work items
Live PR dispositions
matcher: "*"as an explicit semantics-preserving transformation; retain hermetic E2E and mutation-break proof; finish with visibleship_nowand exact-final-SHA green CI._kiro_*side channels; move Kiro-native import to a separate follow-up; retain hermetic E2E and mutation-break proof; finish with visibleship_nowand exact-final-SHA green CI.Describe alternatives you've considered
Additional context
The hooks slice is the proving surface. Commands, MCP, instructions/rules, agents, and plugin import/export each require their own design review before implementation. Existing OpenAPM requirements manifests and
tests/spec_conformanceremain the conformance authority. Lossless rendering remains quiet by default; transformation details appear under verbose or JSON output. Diagnostics report field paths, never secret values.