Destination spec for a multi-session effort. Sub-issues are the journey; this container is the destination, passed to each working session by reference, reviewed against at close-out, and closed (not deleted) when shipped — archival by closure. Source: topic pocock-shipping-breakdown (interview 2026-08-17; carrying PR backfilled as a comment when opened).
TLDR
Absorb the durable ideas from Matt Pocock's 11-video "Shipping" course section (spec → tickets → implement → review across multiple context windows) into this marketplace as separate, vetted work items — closing the one confirmed structural gap (no durable, tracker-published destination artifact for multi-session work) and hardening the surrounding machinery found by adversarial scrutiny — while converting hard-coded plugin conventions into consumer-configurable seams.
Goal
Work too large for one context window needs a destination artifact (spec) durable across sessions, branches, machines, and agents, plus a journey decomposition sized to context windows. Our contract artifacts (PLAN.md/PRD in topic-docs) are branch-tracked and pruned at merge, so multi-PR multi-machine efforts have no durable team-visible destination. Secondarily: everything shipped to close that gap must carry good defaults yet be consumer-configurable (locations, formats, providers, labels, flows) — never hard-coded plugin opinions.
Constraints
- Consumer-configurability doctrine: good defaults, everything overridable; no new fixed filenames/locations/labels without a remap seam or a recorded deferral.
- The 23 upstream bring-over candidates (C1–C23, evidence: topic memory slice
upstream-bringover-audit.md) are adjudicated per-lane during lane implementation; the "worse-than-us" list is excluded by default — notably: no approval-gate-free spec publish, no tracker reads without the item-content-trust boundary, no folklore token figures.
- Hybrid adapter model gated on the contract-version handshake and a normalization-fidelity conformance check; deterministic parts scripted, reasoning outside scripts.
- "Work item" stays canonical; "ticket"/"issue" are documented first-class synonyms.
- Course-derived verdicts recorded in
docs/upstream/aihero-shipping-course.md; per-candidate verdicts update the mattpocock-skills SSOT as lanes close.
Acceptance criteria
Execution contract
One sub-issue at a time per session/worktree (apply → verify → close). PR granularity is per-item by default; sequential checkpoint-style single-PR flow is legitimate within a lane. Blocking edges are recorded in each sub-issue body ("Blocked by"); native dependency edges to be backfilled from a gh ≥ 2.94 session (this cloud session has no gh — a finding recorded on the contract-hygiene sub-issue).
Execution shape: per-item PRs
Recorded 2026-08-21, backfilled rather than chosen late: this container has always shipped per-item PRs, and every close-out over it had to re-derive that from the absent-line default. It ships the serial variant — one long-lived branch carrying sequential per-item PRs rather than a fresh branch per item — which work-items/reference/execution-shape.md documents as a provisioning note under per-item PRs, not a separate shape value. The value above is therefore exact; the variant note is here so a reader is not surprised by eleven PRs sharing one head ref.
Out of scope
Implementing lanes inside this topic beyond publishing the items; the owner's day-job tracker setup; renaming the work-items plugin or seam; re-litigating SSOT-rejected upstream items (setup-by-interview, ask-matt router, research/<name> branches, .out-of-scope/ KB, ~150k smart-zone figure).
Destination spec for a multi-session effort. Sub-issues are the journey; this container is the destination, passed to each working session by reference, reviewed against at close-out, and closed (not deleted) when shipped — archival by closure. Source: topic
pocock-shipping-breakdown(interview 2026-08-17; carrying PR backfilled as a comment when opened).TLDR
Absorb the durable ideas from Matt Pocock's 11-video "Shipping" course section (spec → tickets → implement → review across multiple context windows) into this marketplace as separate, vetted work items — closing the one confirmed structural gap (no durable, tracker-published destination artifact for multi-session work) and hardening the surrounding machinery found by adversarial scrutiny — while converting hard-coded plugin conventions into consumer-configurable seams.
Goal
Work too large for one context window needs a destination artifact (spec) durable across sessions, branches, machines, and agents, plus a journey decomposition sized to context windows. Our contract artifacts (PLAN.md/PRD in topic-docs) are branch-tracked and pruned at merge, so multi-PR multi-machine efforts have no durable team-visible destination. Secondarily: everything shipped to close that gap must carry good defaults yet be consumer-configurable (locations, formats, providers, labels, flows) — never hard-coded plugin opinions.
Constraints
upstream-bringover-audit.md) are adjudicated per-lane during lane implementation; the "worse-than-us" list is excluded by default — notably: no approval-gate-free spec publish, no tracker reads without the item-content-trust boundary, no folklore token figures.docs/upstream/aihero-shipping-course.md; per-candidate verdicts update the mattpocock-skills SSOT as lanes close.Acceptance criteria
Execution contract
One sub-issue at a time per session/worktree (apply → verify → close). PR granularity is per-item by default; sequential checkpoint-style single-PR flow is legitimate within a lane. Blocking edges are recorded in each sub-issue body ("Blocked by"); native dependency edges to be backfilled from a
gh ≥ 2.94session (this cloud session has nogh— a finding recorded on the contract-hygiene sub-issue).Execution shape: per-item PRs
Recorded 2026-08-21, backfilled rather than chosen late: this container has always shipped per-item PRs, and every close-out over it had to re-derive that from the absent-line default. It ships the serial variant — one long-lived branch carrying sequential per-item PRs rather than a fresh branch per item — which
work-items/reference/execution-shape.mddocuments as a provisioning note underper-item PRs, not a separate shape value. The value above is therefore exact; the variant note is here so a reader is not surprised by eleven PRs sharing one head ref.Out of scope
Implementing lanes inside this topic beyond publishing the items; the owner's day-job tracker setup; renaming the
work-itemsplugin or seam; re-litigating SSOT-rejected upstream items (setup-by-interview, ask-matt router, research/<name> branches,.out-of-scope/KB, ~150k smart-zone figure).