Skip to content

Demonstrate shared-capability upgrade and deprecation outcomes for two app consumers #283

Description

@enricopiovesan

Ticket ID

two-app-reuse-lifecycle

Spec

  • docs/two-app-reuse-contract.md / ADR 0006 — shared pin meeting-notes.process 1.3.2 for meeting-notes + loop
  • docs/decision-log.md — 2026-09-05 Blocked tickets ownership walk (fixture-only lifecycle DoD)
  • Upstream context: Traverse #1168 (reuse proof). This ticket does not require BundleEmbedder / two-app-reuse-host-execute
  • No private Traverse internals; no UI business fields; App-Refs does not author WASM

Summary

Prove compatible-upgrade and deprecation consumer outcomes for the two-app shared pin using fixture-level pin flip + documented deprecation handling. Explicit non-claim: this is not a production registry release-train proof and not a public BundleEmbedder host proof.

Why

Execute/evidence tickets (#286/#287) already show both apps on immutable 1.3.2. Lifecycle still needs a checkable App-Refs story for “what happens when the pin must move or the release is deprecated,” without waiting on a new published meeting-notes.process or on Traverse #1240.

Depends on

  • two-app-reuse-contract / two-app-reuse-execute / two-app-reuse-execute-ci (Done)

Blocked by

  • None (Ready). Intentionally not blocked on two-app-reuse-host-execute / Traverse #1240.

Definition of Done

  • Documented fixture procedure: both apps start on shared pin meeting-notes.process 1.3.2 (digest in docs/two-app-reuse-contract.md), then perform a fixture-only pin flip to a second digest-pinned fixture release (or documented stand-in path) and record per-app choice: advance vs remain pinned, with compatibility rationale
  • Documented deprecation handling: when the original pin is marked deprecated in the fixture/docs path, each app records the supported consumer response (migrate / continue pinning / fail closed) — no invented registry policy
  • Automated check (script under scripts/ci/ or extension of existing two-app reuse evidence) exits 0 on the happy fixture path and non-zero on an unsupported/deprecated-only resolution case
  • Evidence artifact checked in (or CI-produced) listing app ids, before/after pin versions + digests, and each app’s upgrade/deprecation decision
  • Docs (docs/two-app-reuse-contract.md, AGENTS.md row) state clearly: fixture-only; not production release-train proof; not BundleEmbedder host proof
  • bash scripts/ci/repository_checks.sh green

Validation

# Exact command(s) added by the implementing PR — must be documented in this ticket’s PR body
bash scripts/ci/repository_checks.sh

Non-goals

  • Waiting for a new public registry publish of meeting-notes.process
  • Requiring BundleEmbedder / meeting-notes-cli / loop-cli success (that remains two-app-reuse-host-execute)
  • Changing registry deprecation policy in Traverse/registry
  • Claiming Traverse #1168 fully closed solely by this fixture proof

Outcome

Claimable Ready work that completes an honest App-Refs lifecycle slice for the two-app pin without overclaiming host or release-train proof.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationqualityCode quality, coverage, or CI gate work

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions