instar 1.3.847 → 1.3.849

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (40) hide show
  1. package/dist/commands/server.d.ts.map +1 -1
  2. package/dist/commands/server.js +11 -2
  3. package/dist/commands/server.js.map +1 -1
  4. package/dist/core/ApprenticeshipProgram.d.ts +14 -0
  5. package/dist/core/ApprenticeshipProgram.d.ts.map +1 -1
  6. package/dist/core/ApprenticeshipProgram.js +78 -1
  7. package/dist/core/ApprenticeshipProgram.js.map +1 -1
  8. package/dist/core/PostUpdateMigrator.d.ts.map +1 -1
  9. package/dist/core/PostUpdateMigrator.js +14 -0
  10. package/dist/core/PostUpdateMigrator.js.map +1 -1
  11. package/dist/core/SessionManager.d.ts.map +1 -1
  12. package/dist/core/SessionManager.js +4 -2
  13. package/dist/core/SessionManager.js.map +1 -1
  14. package/dist/core/TopicProfileOrchestrator.d.ts +2 -0
  15. package/dist/core/TopicProfileOrchestrator.d.ts.map +1 -1
  16. package/dist/core/TopicProfileOrchestrator.js +24 -3
  17. package/dist/core/TopicProfileOrchestrator.js.map +1 -1
  18. package/dist/core/WriteDomainRegistry.d.ts.map +1 -1
  19. package/dist/core/WriteDomainRegistry.js +10 -0
  20. package/dist/core/WriteDomainRegistry.js.map +1 -1
  21. package/dist/core/frameworkSessionLaunch.d.ts +6 -0
  22. package/dist/core/frameworkSessionLaunch.d.ts.map +1 -1
  23. package/dist/core/frameworkSessionLaunch.js +18 -4
  24. package/dist/core/frameworkSessionLaunch.js.map +1 -1
  25. package/dist/scaffold/templates.d.ts.map +1 -1
  26. package/dist/scaffold/templates.js +1 -0
  27. package/dist/scaffold/templates.js.map +1 -1
  28. package/dist/server/CapabilityIndex.d.ts.map +1 -1
  29. package/dist/server/CapabilityIndex.js +2 -1
  30. package/dist/server/CapabilityIndex.js.map +1 -1
  31. package/dist/server/routes.d.ts.map +1 -1
  32. package/dist/server/routes.js +13 -0
  33. package/dist/server/routes.js.map +1 -1
  34. package/package.json +1 -1
  35. package/src/data/builtin-manifest.json +64 -64
  36. package/src/scaffold/templates.ts +1 -0
  37. package/upgrades/1.3.848.md +26 -0
  38. package/upgrades/1.3.849.md +19 -0
  39. package/upgrades/side-effects/apprenticeship-ladder-registry.md +81 -0
  40. package/upgrades/side-effects/topic-profile.md +15 -0
@@ -0,0 +1,81 @@
1
+ # Side-Effects Review — Apprenticeship independence ladder registry
2
+
3
+ **Version / slug:** `apprenticeship-ladder-registry`
4
+ **Date:** 2026-07-16
5
+ **Author:** Instar-codey
6
+ **Second-pass reviewer:** not required
7
+
8
+ ## Summary of the change
9
+
10
+ Implements `docs/specs/apprenticeship-independence-ladder.md` §5.1: every apprenticeship instance stores `ladderRung` (R0–R5) and append-only `rungHistory`; the registry and authenticated route permit evidence-backed adjacent promotion or demotion. Legacy records with both fields absent migrate durably to R0, while partial or malformed ladder state fails closed. Capability discovery, docs, fresh scaffolding, and existing-agent migration carry the same contract.
11
+
12
+ ## Decision-point inventory
13
+
14
+ - `ApprenticeshipProgram.transitionRung` — add — deterministic registry authority for an explicitly requested adjacent rung mutation.
15
+ - `POST /apprenticeship/instances/:id/rung-transition` — add — authenticated API boundary translating registry verdicts to HTTP status.
16
+ - `ApprenticeshipProgram.loadStore` — modify — structural validation distinguishes legacy absence from malformed persisted state.
17
+
18
+ ## 1. Over-block
19
+
20
+ The registry intentionally refuses same-rung writes and multi-rung jumps even when evidence exists. A caller wanting R0→R2 must record R0→R1 and R1→R2 separately, preserving each decision. It also refuses a legacy row where only one new field exists; this is intentional because partial state has ambiguous provenance and cannot be safely reconstructed.
21
+
22
+ ## 2. Under-block
23
+
24
+ The registry validates that evidence is present, bounded, and attributable as text; it does not judge whether a cited cycle or PR actually satisfies the rung criteria. The spec assigns that quality judgment to the overseer. The mechanism guarantees auditable evidence references, adjacency, and history integrity—not automatic graduation.
25
+
26
+ ## 3. Level-of-abstraction fit
27
+
28
+ This belongs in the existing apprenticeship registry: it already owns per-instance durable state, optimistic persistence, and audit records. Route-level validation delegates the mutation decision to that single registry authority rather than reimplementing policy in HTTP handlers. No higher-level conversational gate is bypassed because the caller/overseer remains the graduation mind.
29
+
30
+ ## 4. Signal vs authority compliance
31
+
32
+ **Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
33
+
34
+ - [x] No — this is hard-invariant validation over an enumerable state machine, one of the principle's explicit exceptions.
35
+
36
+ The blocking checks cover structural invariants only: integer R0–R5, adjacent transition, non-empty bounded evidence, coherent append-only history. They do not infer intent or evidence quality. The explicit overseer decision remains the context-rich authority; the registry makes that decision durable and refuses mechanically invalid representations.
37
+
38
+ ## 4b. Judgment-point check (Judgment Within Floors standard)
39
+
40
+ No static heuristic is added at a competing-signals decision point. Whether evidence merits promotion is deliberately outside this method. The only static choices are enumerable storage/state-machine invariants defined by the approved spec.
41
+
42
+ ## 5. Interactions
43
+
44
+ - **Shadowing:** rung transitions are independent of status lifecycle gates; neither runs before or suppresses the other.
45
+ - **Double-fire:** one request produces one CAS-backed instance update and one decision-log entry. Retry without recalculating the next adjacent rung becomes a same-rung refusal rather than a duplicate history append.
46
+ - **Races:** updates reuse the registry's optimistic-version persistence path, so concurrent writers cannot silently overwrite each other.
47
+ - **Cross-machine writes:** apprenticeship instance subroutes are classified `cluster-shared`, preserving a single-writer authority for rung and lifecycle history; the write-admission feature is still dry-run, so this classification changes no fleet behavior today.
48
+ - **Feedback loops:** no monitor, timer, or self-triggered controller consumes rung state in this arm.
49
+
50
+ ## 6. External surfaces
51
+
52
+ The authenticated API adds one route and instance responses add two fields. Persistent `instances.json` state is normalized once for legacy rows. Other agents learn the route through fresh scaffolding and idempotent post-update migration. No Telegram, Slack, GitHub, Cloudflare, timing-dependent, or external-service behavior changes. No operator-only action is introduced: the agent remains the conversational interface and can execute the route for the operator.
53
+
54
+ ## 6b. Operator-surface quality (Operator-Surface Quality standard)
55
+
56
+ No dashboard, approval page, grant/revoke form, secret form, or other operator-rendered surface is changed. Not applicable.
57
+
58
+ ## 7. Multi-machine posture (Cross-Machine Coherence)
59
+
60
+ **Machine-local by design:** apprenticeship instances are program state for the agent installation and use the existing instance registry's storage posture; this arm does not create a new cross-machine ownership or replication model. It emits no user-facing notices, generates no URLs, and does not actuate from topic ownership. Topic transfer therefore neither duplicates an action nor strands a pending notification. A pool-wide apprenticeship registry would require a separate approved replication design rather than silently inventing one inside this schema arm.
61
+
62
+ ## 8. Rollback cost
63
+
64
+ A hot-fix can remove the route and transition method while leaving the additive fields ignored. Existing rung history should remain on disk as compatibility/evidence data; destructive reverse migration is unnecessary and undesirable. Legacy normalization writes cannot be undone automatically, but R0 plus explicit migration provenance is harmless to older code that ignores unknown fields. No agent reset or downtime is required.
65
+
66
+ ## Conclusion
67
+
68
+ The review tightened load behavior so only complete absence qualifies for legacy migration; malformed or partial ladder state now fails closed. It also added current/fresh agent-awareness parity and strict final-history/current-rung coherence. The change is bounded to the approved registry arm and is clear to ship.
69
+
70
+ ## Second-pass review (if required)
71
+
72
+ Not required: this change does not touch messaging, session lifecycle, dispatch, compaction, trust, sentinel/guard/watchdog behavior, or a judgment gate.
73
+
74
+ ## Evidence pointers
75
+
76
+ - 78 focused unit, integration, migration, and E2E tests pass.
77
+ - `npx tsc --noEmit`, `npm run lint`, and `npm run build` pass.
78
+
79
+ ## Class-Closure Declaration (display-only mirror)
80
+
81
+ No agent-authored-artifact defect and no self-triggered controller — not applicable.
@@ -140,3 +140,18 @@ Both follow-ups are documentation precision, not behavior defects. No protection
140
140
  - Wiring integrity: `tests/unit/topic-profile-server-wiring.test.ts` (20 assertions over the composition root — construction, object-identity late-bind, real-deps-not-noops, lifecycle hooks, carrier mesh verb, the §11 conservative-canary flags, the obligation-7 bridge).
141
141
  - Canary both arms: `tests/unit/classifyProfileChange.test.ts` (canary-passed→in-flight, canary-off→resume, idle-unconfirmed→never-in-flight, cross-model/level/off↔on/codex-rollout rows).
142
142
  - Recovery ledger: `docs/specs/reports/topic-profile-BUILD-PROGRESS.local.md`.
143
+
144
+ ## 2026-07-16 addendum — resolved door/model confirmation
145
+
146
+ Post-swap disclosure now consumes the newly spawned session's applied profile. The interactive
147
+ launch default resolver is shared with the Codex and Gemini argv builders, so an unpinned/defaulted
148
+ model is reported from the same decision that launched it. Successful framework, model, and tier
149
+ respawns all emit `Now driving this topic: <Door> door, <concrete model> model.` The fallback text
150
+ `account-default` remains only for doors whose CLI owns an opaque account default (Claude/Pi), where
151
+ inventing a concrete identifier would be dishonest.
152
+
153
+ Interaction review: the spawn port's optional `applied` result is backward-compatible with existing
154
+ ports and tests; when absent, the orchestrator retains its prior resolved-profile behavior. The
155
+ terminal disclosure still uses the existing audited, duplicate-bypass send path, and no new timer,
156
+ write authority, kill decision, persistent schema, or external endpoint is introduced. Rollback is
157
+ a code-only revert with no data repair.