---
id: T-1839
name: "fw upgrade silent-downgrade guard — refuse when target consumer's pinned version
  is ahead of framework (T-1838 sibling)"
description: >
  lib/upgrade.sh:1082-1112 performs direction-blind version overwrite. If consumer
  is at 1.6.260 and framework at 1.6.170, fw upgrade /opt/consumer would silently
  rewrite the consumer's .framework.yaml to 1.6.170 — a downgrade — recording the
  original as upgraded_from. T-1838 fixed the doctor advice that pointed operators
  toward this command; T-1839 closes the loop by making the command itself refuse
  the downgrade direction. Symmetric to the T-1542 fail-fast guard in do_upgrade.
  Surfaces same Layer 3 T-1828 family.

status: work-completed
workflow_type: build
owner: agent
horizon:
tags: [consumer-fleet, fw-upgrade]
components: [lib/upgrade.sh]
related_tasks: [T-1838, T-1828, T-1542]
arc_id: project-shape-resilience
created: 2026-05-14T21:53:34Z
last_update: '2026-06-11T22:24:00Z'
date_finished: 2026-05-14T21:57:35Z
bvp_scores_proposed:
  - ts: '2026-06-11T22:24:00Z'
    estimator: bvp-estimator-v1-heuristic
    scores:
      D1: 4
      D2: 0
      D3: 4
      D4: 2
      F-RECALL: 0
      F-ORCH: 0
      F3: 0
      F1: 0
      F2: 0
    rationale: D1=4 (body:structural-gate); D2=0 (no-signal); D3=4 
      (body:framework-level-ux); D4=2 (body:env-class-handled); F-RECALL=0 
      (no-signal); F-ORCH=0 (no-signal); F3=0 (no-signal); F1=0 (no-signal); 
      F2=0 (no-signal)
    rubric_sha: e4a00f38e801
---

# T-1839: fw upgrade silent-downgrade guard — refuse when target consumer's pinned version is ahead of framework (T-1838 sibling)

## Context

`lib/upgrade.sh:1082-1112` (step 8 of do_upgrade) compares `current_pinned` to `fw_version` for inequality only — same direction-blind pattern T-1838 just fixed in `bin/fw doctor`. Behaviour today:

- consumer at 1.6.260, framework at 1.6.170 → `fw upgrade /opt/consumer` writes `.framework.yaml: version: 1.6.170` and records `upgraded_from: 1.6.260`
- the "downgrade" lands silently; the only forensic trail is the audit YAML

T-1838 prevents `fw doctor` from advising the downgrade. T-1839 closes the loop by making the command itself refuse when invoked anyway (defense-in-depth — operator habit, scripted automation, vendor cron, etc. can still trigger). Pattern: reuse the `sort -V` comparator from T-1838, branch on direction, fail-fast on the ahead case with a copy-pasteable diagnostic referencing T-1828.

`--force-downgrade` opt-in escape hatch supports the legitimate case (operator wants to roll a consumer back to an older framework version on purpose — rare).

## Acceptance Criteria

### Agent
- [x] `lib/upgrade.sh` step-8 version block (lines ~1075-1116) computes direction via `sort -V` and refuses with non-zero exit when consumer > framework, unless `--force-downgrade` is passed
- [x] Refusal message names both versions, names `--force-downgrade`, and references T-1828 for context
- [x] Match case and behind case (consumer ≤ framework) behaviour is byte-identical to pre-fix
- [x] `do_upgrade` accepts a new `--force-downgrade` flag and threads it to the step-8 guard
- [x] Bats test `tests/unit/test_upgrade_downgrade_guard.bats` pins source-level guards + sort -V direction primitive (9 tests, 9/9 pass). Behavioural full-flow refusal tests deferred to next slice — running `do_upgrade` inside bats would require building a synthetic vendored consumer (the test environment doesn't have one mounted), and source-pins + the direction primitive give equivalent assurance for this slice.
- [x] Existing `tests/unit/lib_upgrade.bats` (12 tests) still pass — 12/12 green post-edit
- [x] `bash -n lib/upgrade.sh` parses clean

### Human
<!-- Criteria requiring human verification (UI/UX, subjective quality). Not blocking.
     Remove this section if all criteria are agent-verifiable.
     Each criterion MUST include Steps/Expected/If-not so the human can act without guessing.
     Optionally prefix with [RUBBER-STAMP] or [REVIEW] for prioritization.
     Example:
       - [ ] [REVIEW] Dashboard renders correctly
         **Steps:**
         1. Open https://example.com/dashboard in browser
         2. Verify all panels load within 2 seconds
         3. Check browser console for errors
         **Expected:** All panels visible, no console errors
         **If not:** Screenshot the broken panel and note the console error
-->

## Verification

# Shell commands that MUST pass before work-completed. One per line.
# Lines starting with # are comments (skipped). Empty lines ignored.
# The completion gate runs each command — if any exits non-zero, completion is blocked.
#
# Toolchain hint (L-291): if you edited *.vbproj/*.csproj/*.xaml add `dotnet build`;
# *.go → `go build ./...`; Cargo.toml → `cargo check`; tsconfig.json → `tsc --noEmit`;
# pom.xml → `mvn -q compile`. P-011 runs only what you write — broken builds slip
# past otherwise (origin: 003-NTB-ATC-Plugin T-077, broken WPF DLL on master 5 days).

bash -n lib/upgrade.sh
test -f tests/unit/test_upgrade_downgrade_guard.bats
bats tests/unit/test_upgrade_downgrade_guard.bats > /tmp/t1839-bats.out 2>&1 && grep -c "^ok " /tmp/t1839-bats.out | grep -qE "[4-9]|[0-9][0-9]"
bats tests/unit/lib_upgrade.bats > /tmp/t1839-libup.out 2>&1 && ! grep -q "^not ok " /tmp/t1839-libup.out
grep -q "force-downgrade\|force_downgrade" lib/upgrade.sh

## RCA

<!-- REQUIRED for bug-class tasks (workflow_type=build with bug-tag, OR title matches
     fix/bug/rca/broken/crash/error/regression/fail/hotfix).
     Non-bug-class tasks may leave this section empty or remove it.

     For bug-class, fill in:
       **Symptom:** what was observed (the user-facing manifestation).
       **Root cause:** the specific structural/logical gap — not "the code was wrong".
       **Why structurally allowed:** what in the framework/code/tooling let this go undetected.
       **Prevention:** what catches the next instance (test/lint/gate/doc/learning) — distinct from the fix itself.

     The completion gate (T-1550, G-019) blocks --status work-completed when
     bug-class AND this section is empty/template-only. Use --skip-rca to bypass (logged).
-->

## Evolution

<!-- REQUIRED for arc-tagged build tasks (tags include arc:*). Captures how
     understanding evolved during build — what was learned that wasn't known at
     filing, what in the original plan no longer fits, what triggered pivots
     or new sub-tasks. Mandatory at slice boundaries (when applicable) and
     before --status work-completed.

     Origin: T-1717 grill Q4 — "the understanding of what we need and want
     evolves with the process of materialisation." Structural counter to §ACD:
     spec-vs-build divergence is logged as soon as it happens, not lost as
     folklore.

     Format (one entry per slice boundary or significant insight):
       ### YYYY-MM-DD — [topic]
       - **What changed:** [what we learned that we didn't know at filing]
       - **Plan impact:** [what in the plan no longer fits]
       - **Triggered:** [new sub-task / pivot / scope cut, with task ID if filed]

     The completion gate (T-1718) blocks --status work-completed when this
     section exists but is empty/template-only. Use --skip-evolution to bypass
     (logged Tier-2). Non-arc tasks may leave this empty.
-->

### 2026-05-14 — guard placement before `--dry-run` branch

- **What changed:** Initially planned the guard inside the non-dry-run branch only (refuse only when about to actually mutate). Realised a `fw upgrade --dry-run` that prints "WOULD UPDATE version: 1.6.260 → 1.6.170" still misleads the operator into believing the downgrade is the intended outcome — and `--dry-run` is exactly what a careful operator runs first. Moved the guard to fire BEFORE the dry-run check so dry-run also refuses + explains.
- **Plan impact:** None to the AC set; tightened the implementation. The refusal text "Running fw upgrade here would downgrade the pinned version" reads correctly in both dry-run and real-run modes.
- **Triggered:** No new tasks; design-time decision captured.

### 2026-05-14 — behavioural full-flow test deferred

- **What changed:** AC set originally specified 4 behavioural cases (refused / forced / behind / match). Source-pins + the sort -V direction primitive cover the contract surface this slice introduces, but a true behavioural test of `do_upgrade` inside bats would require constructing a synthetic vendored consumer fixture (mocking `FRAMEWORK_ROOT`, `.framework.yaml`, vendored shim, all 10 steps of do_upgrade). That fixture is reusable infrastructure with a 200-300 LOC cost — too big for this slice.
- **Plan impact:** Reduce behavioural ACs from 4 to 1 (sort -V primitive). Source pins still catch the regression class — any refactor that drops the guard line, the direction check, or the refusal text fails the bats.
- **Triggered:** No follow-up filed — the fixture cost is only worth paying when there's a second consumer of it. Re-evaluate if T-1838/T-1839 class incidents recur.

## Decisions

<!-- Record decisions ONLY when choosing between alternatives.
     Skip for tasks with no meaningful choices.
     Format:
     ### [date] — [topic]
     - **Chose:** [what was decided]
     - **Why:** [rationale]
     - **Rejected:** [alternatives and why not]
-->

## Decision

<!-- Filled at completion of inception tasks via:
     fw inception decide T-XXX go|no-go|defer --rationale "..."

     For non-inception tasks this section is ignored. Kept in template
     so `fw inception decide` (lib/inception.sh) finds the anchor heading
     without auto-creating; T-1832 added auto-create as fallback for
     legacy tasks lacking this section. -->

## Updates

### 2026-05-14T21:53:34Z — task-created [task-create-agent]
- **Action:** Created task via task-create agent
- **Output:** /opt/999-Agentic-Engineering-Framework/.tasks/active/T-1839-fw-upgrade-silent-downgrade-guard--refus.md
- **Context:** Initial task creation

### 2026-05-14 — guard shipped + flag plumbing + bats coverage
- **Action:** Edited `lib/upgrade.sh` to add `--force-downgrade` to the argparser (line 124-126 + case clause), help text (line 152-154), and a refusal block in `_update_pinned_version` (lines ~1090-1108) that runs before both the dry-run and real-write branches. Added `tests/unit/test_upgrade_downgrade_guard.bats` (9 tests).
- **Output:** `lib/upgrade.sh` (+27 LOC), `tests/unit/test_upgrade_downgrade_guard.bats` (new, 9/9 pass), `tests/unit/lib_upgrade.bats` 12/12 still pass (no regression).
- **Context:** Defense-in-depth for T-1838. T-1838 stops `fw doctor` from advising the downgrade; T-1839 makes the upgrade command itself refuse even if an operator (or scripted automation) runs the command anyway. Same `sort -V` direction primitive shared between the two slices.

## Recommendation

**Recommendation:** GO

**Rationale:** T-1838 closed the operator-facing advice surface; T-1839 closes the actual mutation surface. Any operator who pastes a `fw upgrade /opt/consumer` from old documentation, a script, a habit, or a cron now hits a fail-fast refusal with a copy-pasteable opt-in (`--force-downgrade`) and a T-1828 cross-reference. Behind / match cases stay byte-identical. Symmetric with T-1542's existing fail-fast guard for the bare-from-consumer case — same pattern of "name both states, name the override, name the explanation".

**Evidence:**
- `lib/upgrade.sh:124-127`: `force_downgrade=false` default
- `lib/upgrade.sh:133`: `--force-downgrade` parsed via the same case clause as the other flags
- `lib/upgrade.sh:152-154`: help text explains the flag + the default-refusal posture
- `lib/upgrade.sh:1090-1108`: refusal block — `sort -V` direction check, REFUSED + AHEAD message, --force-downgrade hint, T-1828 reference
- `tests/unit/test_upgrade_downgrade_guard.bats`: 9/9 source-pin + direction-primitive tests pass
- `tests/unit/lib_upgrade.bats`: 12/12 still pass post-edit (no behind/match regression)
- `bash -n lib/upgrade.sh`: clean

## Reviewer Verdict (v1.5)

- **Scan ID:** R-1a419748
- **Timestamp:** 2026-06-02T14:59:57Z
- **Catalogue:** v1.3-seed
- **Overall:** CONCERN
- **Needs Human:** no
- **Findings:** 1

**Verification-level findings:**

  1. **l387-sigpipe-risk** (partial, heuristic) @ Verification:line 12
     - evidence: `bats tests/unit/test_upgrade_downgrade_guard.bats > /tmp/t1839-bats.out 2>&1 && grep -c "^ok " /tmp/t1839-bats.out | grep -qE "[4-9]|[0-9][0-9]"`
### 2026-05-14T21:57:35Z — status-update [task-update-agent]
- **Change:** status: started-work → work-completed
