1. Background Context
Source: git-warp #516. Audited against main 94b40dac64034cd8caab9bb05efe14a0c22bd735. Template: feature; work type: type:feature.
Current scope and disposition: Public ORSet boundary first, then kernel extraction. Pipeline dependency is inherited; never merge a root import of an unpublished shell.
2. Problem Description
Public ORSet boundary first, then kernel extraction. Pipeline dependency is inherited; never merge a root import of an unpublished shell.
Historical source report; the current disposition above supersedes obsolete claims:
packages/warp-kernel/ exists, but it is still a private workspace shell.
Root source cannot safely import @git-stunts/warp-kernel until the package is
published in lock step with root and its lower-level dependencies are real.
Cycle 0047 already found the bad version of this work: a private package shell
or relative imports into packages/warp-kernel/ would make the boundary a
costume instead of an extraction.
2b. Proposed Solution
Public ORSet boundary first, then kernel extraction. Pipeline dependency is inherited; never merge a root import of an unpublished shell.
Historical approach to reconcile:
Current architecture rules take precedence: parsing/encoding stays at adapters, domain concepts are runtime-backed, no trust casts are introduced, and tests run in Docker.
After the multi-package publish pipeline exists and warp-orset is a real
published dependency, move kernel-owned services, controllers, state
management, and ports into packages/warp-kernel/src/, flip the package
public, and make root consume it through a publish-safe dependency boundary.
2c. Alternatives considered and rejected
No additional alternatives are recorded as decided. Reject duplicate ownership, private-import escape hatches and a broken intermediate mainline; retain original alternatives below when present.
2d. Acceptance Criteria
packages/warp-kernel/package.json is public and participates in the
lock-step release pipeline.- Root code imports kernel-owned modules through the published package
boundary.
- No shipped root code reaches into
packages/warp-kernel/ by relative path.
- Adapter code remains out of
warp-kernel.
- The package boundary is covered by build, typecheck, package dry-run, and
consumer-type checks.
2e. Test Plan
Golden: Validate a packed artifact and the declared release/publication outcome.
Edges: Missing workspace manifest, stale metadata, rerun and runtime/platform differences.
Known failure modes: Deterministic validation failure is not retried as a transport error or reported as publication success.
Fuzz and stress: Repeated clean Docker builds/dry-runs; registry publishing requires the separate release workflow.
All tests and benchmarks execute in COPY-based Docker containers without host repository or Git-directory mounts. This planning audit does not claim those checks were run.
3. Prerequisites
Completion prerequisites; preparatory work may start earlier.
4. Scope
In: Public ORSet boundary first, then kernel extraction. Pipeline dependency is inherited; never merge a root import of an unpublished shell.
Out: unrelated domain work and any expansion beyond the issue’s stated observable outcome.
Safe intermediate state: the PR builds and passes relevant checks after its listed prerequisites; existing supported behavior remains usable. Any preparatory step must be independently mergeable.
5. Why now
Maintainer ordering: memory correctness first, supported attachments next, then land eligible PRs. Preserve this card’s existing priority unless a separately recorded scope decision changes it.
6. Risks
Main risk: implementing the historical description instead of the current runtime contract. Preserve compatibility, causal/ownership invariants and bounded behavior relevant to release.
7. Definition of Done
The issue-specific acceptance checks pass, relevant validation evidence is attached, and the issue links the coherent PR and resulting mainline integration commit. No open item is hidden in a later repair PR.
8. Stakeholders
James Ross: maintainer, assignee and acceptance owner. Package consumers and release maintainers rely on reproducible published artifacts.
9. Related Issues
- Blocks completion of #515: Adapter extraction requires a real public kernel boundary and publish-safe dependency wiring.
Source (source record):
Rehomed from archived v17 residual note
INFRA_extract-warp-kernel-package-post-publish.
Historical paths, counts, release names and shell examples in source material are evidence to reconcile, not authority to restore retired documentation or run host tests.
1. Background Context
Source: git-warp #516. Audited against main
94b40dac64034cd8caab9bb05efe14a0c22bd735. Template:feature; work type:type:feature.Current scope and disposition: Public ORSet boundary first, then kernel extraction. Pipeline dependency is inherited; never merge a root import of an unpublished shell.
2. Problem Description
Public ORSet boundary first, then kernel extraction. Pipeline dependency is inherited; never merge a root import of an unpublished shell.
Historical source report; the current disposition above supersedes obsolete claims:
packages/warp-kernel/exists, but it is still a private workspace shell.Root source cannot safely import
@git-stunts/warp-kerneluntil the package ispublished in lock step with root and its lower-level dependencies are real.
Cycle 0047 already found the bad version of this work: a private package shell
or relative imports into
packages/warp-kernel/would make the boundary acostume instead of an extraction.
2b. Proposed Solution
Public ORSet boundary first, then kernel extraction. Pipeline dependency is inherited; never merge a root import of an unpublished shell.
Historical approach to reconcile:
Current architecture rules take precedence: parsing/encoding stays at adapters, domain concepts are runtime-backed, no trust casts are introduced, and tests run in Docker.
After the multi-package publish pipeline exists and
warp-orsetis a realpublished dependency, move kernel-owned services, controllers, state
management, and ports into
packages/warp-kernel/src/, flip the packagepublic, and make root consume it through a publish-safe dependency boundary.
2c. Alternatives considered and rejected
No additional alternatives are recorded as decided. Reject duplicate ownership, private-import escape hatches and a broken intermediate mainline; retain original alternatives below when present.
2d. Acceptance Criteria
packages/warp-kernel/package.jsonis public and participates in thelock-step release pipeline.
boundary.
packages/warp-kernel/by relative path.warp-kernel.consumer-type checks.
2e. Test Plan
Golden: Validate a packed artifact and the declared release/publication outcome.
Edges: Missing workspace manifest, stale metadata, rerun and runtime/platform differences.
Known failure modes: Deterministic validation failure is not retried as a transport error or reported as publication success.
Fuzz and stress: Repeated clean Docker builds/dry-runs; registry publishing requires the separate release workflow.
All tests and benchmarks execute in COPY-based Docker containers without host repository or Git-directory mounts. This planning audit does not claim those checks were run.
3. Prerequisites
Completion prerequisites; preparatory work may start earlier.
4. Scope
In: Public ORSet boundary first, then kernel extraction. Pipeline dependency is inherited; never merge a root import of an unpublished shell.
Out: unrelated domain work and any expansion beyond the issue’s stated observable outcome.
Safe intermediate state: the PR builds and passes relevant checks after its listed prerequisites; existing supported behavior remains usable. Any preparatory step must be independently mergeable.
5. Why now
Maintainer ordering: memory correctness first, supported attachments next, then land eligible PRs. Preserve this card’s existing priority unless a separately recorded scope decision changes it.
6. Risks
Main risk: implementing the historical description instead of the current runtime contract. Preserve compatibility, causal/ownership invariants and bounded behavior relevant to release.
7. Definition of Done
The issue-specific acceptance checks pass, relevant validation evidence is attached, and the issue links the coherent PR and resulting mainline integration commit. No open item is hidden in a later repair PR.
8. Stakeholders
James Ross: maintainer, assignee and acceptance owner. Package consumers and release maintainers rely on reproducible published artifacts.
9. Related Issues
Source (source record):
Rehomed from archived v17 residual note
INFRA_extract-warp-kernel-package-post-publish.Historical paths, counts, release names and shell examples in source material are evidence to reconcile, not authority to restore retired documentation or run host tests.