# Synchronize SD qualification lifecycle across firmware and qualifier Workpackage

Status: complete
Type: workpackage
Updated: 2026-07-26
Next Action: none

Project Map: work/maps/map-smi-firmware-stabilization-and-qualification.md

## Current Context

The accepted lifecycle ADR in
`jong@srv-rpi00.local:~/dev/sd_qualification/work/adr/adr-card-model-qualification-lifecycle-and-history.md`
defines immutable qualification campaigns, a minimum of two passing fresh
specimens, justified adaptive additions, explicit failure attribution,
append-only history, and reviewed family disposition.

This firmware workspace still carries an earlier fixed three-sample rule in
`work/decisions/decision-remaining-qualification-authorization.md`, the active
media-qualification workpackage, candidate inventory, checklist, map, and ECR
procedure. The fixed rule blocks a two-card retail family even when two
complete passes would satisfy the accepted engineering-compatibility claim.

The remote fixture application implements the basic campaign/sample entities
and minimum pass count, but its approval service does not yet enforce every
accepted condition. In particular, a non-media systemic failure can be
excluded with prose and fail to block approval. The application also needs
bounded maximum-population enforcement and direct tests of negative approval
cases.

The local workspace has substantial unrelated source and generated-binary
changes. Preserve them. This workpackage authorizes only qualification-policy,
planning, targeted check, and remote fixture-policy changes. It does not
authorize physical-media operations, controller programming, formatting,
power interruption, or qualification execution.

## Recommendation

Use the accepted remote ADR as the lifecycle baseline and retain the stronger
firmware-specific coverage requirement:

- start each family campaign with two fresh expendable specimens;
- assign the initial population across Controller A and Controller B so both
  hardware variants are covered;
- require the versioned campaign profile to contain all A/B functional,
  endurance, interruption, and post-check coverage assigned for that release;
- add a third or later specimen only for a recorded replacement,
  investigation, inconclusive, infrastructure-damaged, or additional-coverage
  reason;
- never let later passing specimens erase a confirmed family failure;
- block approval for unresolved firmware, controller, method, automation,
  safety, evidence, or infrastructure failures;
- create a new immutable campaign for every requalification or release-scope
  change.

Do not weaken CID, full-address scrub, three-wrap, controller-safety,
evidence, reviewer, or powered-removal rules. Do not treat deployment of the
fixture application as authorization for physical qualification.

## Current State

Completed:

- Remote lifecycle ADR is accepted and promoted into its canonical workflow
  documents.
- Local Controller A/B identities, CID reporting, full-address scrub,
  endurance minimum, fault methods, and safety boundaries are established.
- Remote fixture application is deployed and reports healthy in fixture-only
  mode.

Incomplete:

- Local fixed three-sample policy conflicts with the accepted adaptive policy.
- Local ECR procedure initializes media before its listed full-address scrub.
- Cross-controller coverage is not explicit in the remote two-sample policy.
- Remote approval enforcement and negative tests do not cover the complete ADR
  formula.
- Remote planning text contains stale pre-implementation statements.
- Both Tool Shed indexes and work-state reports need reconciliation after the
  changes.

## Goal

Make the firmware workspace and remote qualifier express and enforce one
qualification lifecycle: two initial fresh samples spanning A/B, adaptive
justified additions, immutable requalification campaigns, full pre-destructive
baseline gates, complete evidence, and fail-closed reviewed approval.

## Why It Matters

Conflicting sample counts and approval rules can waste procurement and six-day
bench capacity, or worse, allow the UI and firmware release plan to reach
different conclusions from the same evidence. One explicit policy is required
before candidate cards are destructively initialized.

## Major Outcomes

- Canonical local ECR and qualification documentation match the accepted
  lifecycle.
- The initial two samples explicitly span A and B; adaptive additions preserve
  the local systemic-risk discrimination objective.
- Candidate procurement and duration estimates reflect two initial samples
  without discarding already purchased cards.
- The qualifier rejects approval for incomplete coverage, missing evidence,
  unresolved non-media failures, missing dispositions, insufficient passes, or
  creator self-review.
- Local and remote Tool Shed artifacts describe actual current state.

## Delivery Stages

Use stages when sequencing, parity gates, or handoff cost matter.

| Stage | Outcome | Entry Evidence | Exit Evidence |
| --- | --- | --- | --- |
| 1 | Policy reconciliation | Accepted remote ADR and local three-sample decision | Local canonical procedure and decision use the adaptive rule with A/B coverage |
| 2 | Planning reconciliation | Updated policy | Inventory, checklist, estimates, workpackage, and map agree |
| 3 | Enforcement reconciliation | Accepted approval formula | Remote service and tests fail closed for every material negative case |
| 4 | Closeout | Targeted checks pass | Indexes, stale paths, work-state reviews, and a cross-workspace audit pass |

## Related Artifacts

- Tickets:
- Checklists:
  - `work/checklists/checklist-hpt-media-2-autonomous-retail-card-qualification.md`
- Spikes:
- ADRs:
  - `jong@srv-rpi00.local:~/dev/sd_qualification/work/adr/adr-card-model-qualification-lifecycle-and-history.md`
- Runbooks:
  - `work/runbooks/runbook-autonomous-hpt-sd-qualification.md`
- Inventories:
  - `work/inventories/inventory-sd-card-qualification-candidates.md`
- Decision matrices:
  - `work/decisions/decision-remaining-qualification-authorization.md`

## Rough Sequence

1. Record the accepted adaptive population and mandatory A/B release profile.
2. Move the full-address scrub ahead of destructive initialization.
3. Update the decision matrix, media workpackage, inventory, checklist, map,
   and execution estimates.
4. Harden qualifier sample-addition and approval services.
5. Add negative and positive policy tests and run the remote application suite.
6. Remove stale remote planning claims and reconcile both work indexes.
7. Run targeted local checks and a cross-workspace terminology/policy scan.

## Milestones

### Milestone 1: Policy is canonical

Completion criteria:

- [x] Local and remote documents require at least two initial fresh specimens.
- [x] The initial pair is assigned across A and B for the current release
  profile.
- [x] Third and later specimens require a reviewed reason and do not outvote a
  media-family failure.
- [x] The pre-destructive full-address scrub precedes initialization.

### Milestone 2: Qualifier enforcement matches policy

Completion criteria:

- [x] Approval requires minimum passes and complete required coverage.
- [x] Every nonpassing/excluded/inconclusive specimen has a reviewed
  disposition.
- [x] Any unresolved family or systemic failure blocks approval.
- [x] Maximum sample count is enforced when configured.
- [x] Tests prove the positive and negative rules.

### Milestone 3: Both workspaces are reconciled

Completion criteria:

- [x] Remote fixture suite passes.
- [x] Local policy/static checks pass.
- [x] Tool Shed indexes, stale paths, and work-state reviews pass or only
  report pre-existing unrelated findings.
- [x] Cross-workspace scans find no active fixed-three-sample release rule or
  stale pre-implementation qualifier claim.

## Open Questions

- None blocking. The accepted policy is two-or-more adaptive specimens; this
  synchronization retains mandatory A/B coverage as part of the frozen
  release profile.

## Completion Standard

This workpackage is complete when both repositories state the same sample,
coverage, evidence, failure, history, and approval policy; the remote fixture
enforces that policy through tested server-side rules; all planning surfaces
and estimates are reconciled; and no physical operation has been performed.

## Closeout Routing

- Current truth promoted to:
  `docs/ecr-sd-card-supply-change-resolution.md`,
  `docs/web-ui-workflow/` in the remote qualifier, and the active local
  qualification decision.
- Historical context remains in: Git history and prior qualification evidence.
- Runtime/status evidence: targeted local check output and remote Django tests.
- Cleanup deferred to: physical candidate execution and live controller-adapter
  integration under separate authorization.
