release: v1.13.1 — pi-extensions 7cb808e (aws-sso ignores a Bedrock tier with a non-Bedrock task fallback)

CHANGELOG.md

@@ -11,6 +11,33 @@ Pre-v1.0.0 tags followed the pi npm version (`v{pi_version}[letter]`).
 
 ---
 
+## v1.13.1 — 2026-10-25
+
+Patch release with one change since v1.13.0, the pi-extensions AWS SSO keeper
+fix below. Nothing else moved: pi-extensions `f032195` → **`7cb808e`** is the
+only component the build bakes differently. The base image is not rebuilt
+(no base input changed), so the base tools are byte-identical to v1.13.0.
+
+> **Note:** v1.13.1 exists because v1.13.0 was built minutes before
+> pi-extensions `7cb808e` landed. CI resolves pi-extensions `main` when a build
+> starts, so v1.13.0 shipped `f032195`, whose keeper still counts a Bedrock
+> `deep` fork profile. With `deep` on Bedrock, an ERDC session on v1.13.0 can
+> still ask for an AWS login. Prefer v1.13.1 over v1.13.0.
+
+### Fixed
+
+- **The AWS SSO keeper ignores a Bedrock fork tier that has a non-Bedrock
+  fallback** (pi-extensions `7cb808e`). If `pi-task.fallbackProfiles.<tier>`
+  names a non-Bedrock model, that tier no longer makes the keeper log in. Then a
+  setup like `deep` = Bedrock Opus, falling back to `erdc/glm-5.3`, never asks
+  for an AWS login in an ERDC session. While the login is valid, `deep` tasks
+  run on Opus. Once it has expired, the `task` tool retries once on the
+  fallback (only after an auth error before any tool call), and its report says
+  `[FALLBACK]`. Measured 2026-10-25 on tor-ms22 with a deliberately invalid AWS
+  key: Bedrock answered `UnrecognizedClientException`, and the task finished on
+  glm-5.3. The `fork` tool has no fallback: a `deep` fork still fails until you
+  log in (`/aws-sso now`).
+
 ## v1.13.0 — 2026-10-25
 
 Minor release. Headline: the **`pi-devbox-firstboot` skill** (first-boot