instar 1.3.332 → 1.3.333

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "instar",
-  "version": "1.3.332",
+  "version": "1.3.333",
   "description": "Coherence infrastructure for self-evolving AI agents — on the Claude Code or Codex subscription you already have.",
   "type": "module",
   "main": "dist/index.js",

package/src/data/builtin-manifest.json

@@ -1,8 +1,8 @@
 {
   "$schema": "./builtin-manifest.schema.json",
   "schemaVersion": 1,
-  "generatedAt": "2026-06-06T03:31:31.289Z",
-  "instarVersion": "1.3.332",
+  "generatedAt": "2026-06-06T03:35:43.361Z",
+  "instarVersion": "1.3.333",
   "entryCount": 199,
   "entries": {
     "hook:session-start": {

package/upgrades/{1.3.332.md → 1.3.333.md}

@@ -15,6 +15,14 @@ housekeeping channel — the reporter's per-feature 1h cooldown bounds even an
 all-topics-stale storm to a single alert). Success clears the episode. The
 `reportStaleStandby` dep is optional — omitted, behavior is byte-identical.
 
+Made the three `telegram-reply.sh` test harnesses hermetic against a live
+agent session's environment: each script-spawn now blanks
+`INSTAR_AUTH_TOKEN` so the script exercises the config-file auth fallback
+the tests intend, instead of inheriting the runner's real session token
+(which the test servers' auth middleware correctly rejects, failing the
+tests only when run inside an agent session). Same hermeticity class as
+the #862 unit-suite fix, applied to the reply-script family.
+
 ## What to Tell Your User
 
 Only relevant if I run on more than one machine: when the standby machine's
@@ -40,3 +48,8 @@ removed. Focused adversarial second-pass: CONCUR (episode timing, firing bound
 DegradationReporter flood analysis). Tests: 21 green in LiveTailSource.test.ts
 incl. the P19 sustained-failure bound (~100 failing windows → exactly 1
 signal) and the server.ts wiring pin; tsc clean.
+
+- Bisected: `tests/integration/telegram-reply-end-to-end.test.ts` fails
+  with `INSTAR_AUTH_TOKEN` exported, passes without; single-var culprit.
+- Post-fix: all 4 reply-script test files (32 tests) green BOTH under a
+  live agent env and a stripped env.

package/upgrades/side-effects/test-env-hermetic-reply-scripts.md

@@ -0,0 +1,67 @@
+# Side-Effects Review — Hermetic env for telegram-reply script tests
+
+**Version / slug:** `test-env-hermetic-reply-scripts`
+**Date:** `2026-06-05`
+**Author:** `echo`
+**Second-pass reviewer:** `not required (test-only change, no runtime surface)`
+
+## Summary of the change
+
+Three tests that spawn `telegram-reply.sh` (`tests/integration/telegram-reply-end-to-end.test.ts`, `tests/unit/telegram-reply-recoverable-classification.test.ts`, `tests/unit/reply-scripts.test.ts`) inherited the full process env via `{ ...process.env }`. Inside a live agent session, `INSTAR_AUTH_TOKEN` is exported (SessionManager injects it), the script's documented env-first auth resolution picks it up, and the test server's auth middleware rejects the mismatched Bearer before the route handler records the hit — failing the test only when run inside an agent session. Each spawn site now sets `INSTAR_AUTH_TOKEN: ''` so the script exercises the config-file fallback the tests intend. No runtime files changed.
+
+## Decision-point inventory
+
+No decision-point surface — test-only. The script's env-first auth precedence is intentionally UNCHANGED (it is documented, load-bearing behavior); only the tests' spawn environments changed.
+
+---
+
+## 1. Over-block
+
+No block/allow surface — not applicable.
+
+## 2. Under-block
+
+No block/allow surface — not applicable.
+
+## 3. Level-of-abstraction fit
+
+Right layer: the fix is at the test spawn sites, not the script. Weakening the script's env-first precedence to make tests pass would invert the actual contract. The sibling `telegram-reply-port-resolution.test.ts` already constructs a minimal env (`{ PATH }`) — the targeted blank keeps each test's existing env needs intact while removing the one leaking variable.
+
+## 4. Signal vs authority compliance
+
+**Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
+
+- [x] No — this change has no block/allow surface.
+
+## 5. Interactions
+
+- Shadowing/double-fire/races/feedback loops: none — test-only env construction.
+- Verified the three tests + the already-hermetic sibling all pass together under a live agent env AND under a stripped env (both run locally).
+
+## 6. External surfaces
+
+None. No runtime change; CI behavior identical (CI never had the variable set — that's why CI was green while local was red).
+
+## 7. Rollback cost
+
+Trivial revert of three test lines. No persistent state.
+
+---
+
+## Conclusion
+
+Closes a hermeticity gap in the reply-script test family (the same class PR #862 closed for the unit suite's config leakage): tests must not change verdict based on the runner's live agent environment. Found via Zero-Failure triage of a local full-suite run. Clear to ship.
+
+---
+
+## Second-pass review (if required)
+
+**Reviewer:** not required
+**Independent read of the artifact:** not required — test-only.
+
+---
+
+## Evidence pointers
+
+- Repro: `npx vitest run tests/integration/telegram-reply-end-to-end.test.ts` fails with `INSTAR_AUTH_TOKEN` exported, passes with it unset (bisected: that single var).
+- Post-fix: all 4 reply-script test files green under the live agent env (32 tests).

package/upgrades/test-env-hermetic-reply-scripts.eli16.md

@@ -0,0 +1,9 @@
+# Tests stop failing just because a real agent is running them
+
+Three of our tests check the little script that delivers my chat replies. Each test builds a fake miniature server, points the script at it, and watches what the script does. The problem: when those tests run inside a LIVE agent work session (instead of a clean CI machine), the session environment carries the agent's REAL access token in an environment variable — and the script is designed to prefer that variable when it exists. So the script walks up to the fake test server holding the real token, the fake server's door check rejects it (wrong token), and the test fails with a confusing "the script never called the server" error — even though nothing is actually broken.
+
+This bit us tonight: the full test suite went red on my machine for exactly this reason, while the same tests pass everywhere else. The "fix" each time would have been to shrug and re-run on CI — which trains everyone to distrust local test runs, the opposite of what a test suite is for.
+
+The change is three one-line edits: each test now explicitly blanks that environment variable when launching the script, so the script falls back to reading the token from the test's own config file — the path the tests were always meant to exercise. A fourth sibling test already did this correctly (it builds a minimal clean environment from scratch), which is how we knew the pattern. Comments at each site explain why, so the next person who writes a test like this copies the safe pattern.
+
+Nothing about the real script changes. Production behavior is untouched — this only makes the tests honest about what environment they run in. Tests now pass identically on a clean CI box and inside a live agent session.