instar 0.28.25 → 0.28.26

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.
@@ -142,37 +142,25 @@ If they type something else → interpret conversationally and route.
142
142
 
143
143
  #### If gh_status="auth-needed"
144
144
 
145
- **MANDATORY DO THIS BEFORE ASKING FOR AN AGENT NAME.** The discovery scan ran without GitHub access. The user may already have agents backed up to GitHub from another machine. You MUST offer to sign them in BEFORE proceeding to fresh-install prompts. Skipping this step has caused users to create duplicate agents instead of restoring existing ones.
145
+ Walk the user through auth FIRST:
146
146
 
147
- Say:
148
- > Before we set up a new agent, let me check GitHub for any agents you've backed up from another machine. I need to sign you init takes about 30 seconds.
147
+ > Let me check if you have agents backed up on GitHub.
148
+ > I need to sign you into GitHub this opens your browser.
149
149
 
150
- Then follow the **GitHub Device-Code Auth Flow** below. After auth completes, re-run discovery (call `runDiscovery` via the setup CLI or re-invoke the wizard) and present the updated agent list. Only proceed to fresh-install if discovery still shows zero agents.
150
+ ```bash
151
+ gh auth login --web --git-protocol https
152
+ ```
153
+
154
+ After auth, re-scan and present results.
151
155
 
152
156
  #### If gh_status="unavailable"
153
157
 
154
- GitHub CLI isn't installed. With instar 0.28.18+ this should be rare — the prerequisite check auto-installs gh. If you somehow get here, ask:
155
- > Have you used Instar before on another machine? If so, I should install GitHub CLI so I can find your existing agents before we create a new one.
158
+ Ask:
159
+ > Have you used Instar before on another machine?
156
160
 
157
- If yes: Install gh (brew/apt), then follow the **GitHub Device-Code Auth Flow** below, then re-run discovery.
161
+ If yes: Show install guidance for the platform. After install auth scan.
158
162
  If no: Continue to fresh install.
159
163
 
160
- #### GitHub Device-Code Auth Flow (use this everywhere `gh auth login` is needed)
161
-
162
- **DO NOT run `gh auth login` synchronously in Bash** — it blocks waiting for the user to visit a URL and the Bash tool buffer hides the prompt. The user will see a frozen command and have no idea what to do.
163
-
164
- Instead:
165
-
166
- 1. Start `gh auth login --web --git-protocol https` with `run_in_background: true`.
167
- 2. Poll the background output every 2 seconds (BashOutput tool) until you see a line matching `! First copy your one-time code: XXXX-XXXX` and a line containing `https://github.com/login/device`.
168
- 3. Extract the code and URL, then present them to the user conversationally — NOT as raw Bash output:
169
- > To sign in, visit **https://github.com/login/device** and enter this code: **XXXX-XXXX**
170
- > I'll wait here until you're done.
171
- 4. Poll `gh auth status` every 5 seconds (foreground, fast). When it exits 0, the user has finished. Stop polling the background process and let it complete on its own.
172
- 5. Confirm: "You're signed in as <username>. Let me check for your agents now."
173
-
174
- If 5 minutes pass with no auth completion, ask the user if they want to keep waiting or skip GitHub for now.
175
-
176
164
  #### Normal fresh install options
177
165
 
178
166
  **If inside a git repo:**
@@ -1921,7 +1909,15 @@ Wait for user to install, then re-check.
1921
1909
  gh auth status 2>&1
1922
1910
  ```
1923
1911
 
1924
- If not authenticated, use the **GitHub Device-Code Auth Flow** described in Entry Point B (above). DO NOT run `gh auth login` synchronously — it blocks the Bash tool and the user will see a frozen command. Run in background, parse the device code and URL from output, present them conversationally, and poll `gh auth status` until success.
1912
+ If not authenticated, walk them through it:
1913
+
1914
+ > I need to connect to your GitHub account. This opens your browser for a secure sign-in.
1915
+
1916
+ ```bash
1917
+ gh auth login --web --git-protocol https
1918
+ ```
1919
+
1920
+ This is an interactive command that opens the browser — run it with `stdio: 'inherit'` so the user sees the auth flow. Wait for it to complete.
1925
1921
 
1926
1922
  **Step 3: Create private repo**
1927
1923
 
package/dist/cli.js CHANGED
File without changes
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "instar",
3
- "version": "0.28.25",
3
+ "version": "0.28.26",
4
4
  "description": "Persistent autonomy infrastructure for AI agents",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",
@@ -1,8 +1,8 @@
1
1
  {
2
2
  "$schema": "./builtin-manifest.schema.json",
3
3
  "schemaVersion": 1,
4
- "generatedAt": "2026-04-10T18:18:05.205Z",
5
- "instarVersion": "0.28.25",
4
+ "generatedAt": "2026-04-10T19:42:39.899Z",
5
+ "instarVersion": "0.28.26",
6
6
  "entryCount": 186,
7
7
  "entries": {
8
8
  "hook:session-start": {
@@ -343,7 +343,7 @@
343
343
  "id": "skill:autonomous",
344
344
  "type": "skill",
345
345
  "domain": "skills",
346
- "sourcePath": ".claude/skills/autonomous/skill.md",
346
+ "sourcePath": ".claude/skills/autonomous/SKILL.md",
347
347
  "contentHash": "9bc7dc9eddd4e345ed6564eff850898b66358ce309119c3047e6af275cf9070d",
348
348
  "since": "2025-01-01"
349
349
  },
@@ -351,7 +351,7 @@
351
351
  "id": "skill:build",
352
352
  "type": "skill",
353
353
  "domain": "skills",
354
- "sourcePath": ".claude/skills/build/skill.md",
354
+ "sourcePath": ".claude/skills/build/SKILL.md",
355
355
  "contentHash": "5b3557fa3662cf0c7b7bab85a252cc2e567b3fc64a04a92d430374ef1f264ca6",
356
356
  "since": "2025-01-01"
357
357
  },
@@ -359,7 +359,7 @@
359
359
  "id": "skill:secret-setup",
360
360
  "type": "skill",
361
361
  "domain": "skills",
362
- "sourcePath": ".claude/skills/secret-setup/skill.md",
362
+ "sourcePath": ".claude/skills/secret-setup/SKILL.md",
363
363
  "contentHash": "0f4365713d96c98576d19c818701abe96329f3652ed0d8d76ec4e4a1b46dac56",
364
364
  "since": "2025-01-01"
365
365
  },
@@ -367,8 +367,8 @@
367
367
  "id": "skill:setup-wizard",
368
368
  "type": "skill",
369
369
  "domain": "skills",
370
- "sourcePath": ".claude/skills/setup-wizard/skill.md",
371
- "contentHash": "102442b6026761329e5c3ef28341e079a79e49a107e3b81afda1efe7229d9888",
370
+ "sourcePath": ".claude/skills/setup-wizard/SKILL.md",
371
+ "contentHash": "813fd9164514fd11d1bdc67f4dbee02a74679b3ca46bf1b39893c62deb2e58cb",
372
372
  "since": "2025-01-01"
373
373
  },
374
374
  "route-group:health": {
@@ -1,4 +1,4 @@
1
- # Upgrade Guide — v0.28.25
1
+ # Upgrade Guide — vNEXT
2
2
 
3
3
  <!-- bump: patch -->
4
4
 
@@ -1,19 +0,0 @@
1
- # Upgrade Guide — v0.28.10
2
-
3
- <!-- bump: patch -->
4
-
5
- ## What Changed
6
-
7
- Job gate checks now retry up to 3 times with a 5-second delay between attempts before recording a skip. Previously, a single gate failure (e.g., health check returning non-zero during a brief server restart) would immediately skip the job. This caused guardian jobs scheduled at minute 0 to consistently miss their windows when the server restarts hourly at the same time.
8
-
9
- The existing `scheduleRetry` mechanism (1min, 5min, 15min escalating retries) remains as a second layer, but the in-gate retry handles the most common case: a health endpoint that's unavailable for a few seconds during restart.
10
-
11
- ## What to Tell Your User
12
-
13
- - **More reliable scheduled jobs**: "Jobs that depend on health checks are now more resilient to brief server restart windows. If you've noticed guardian or monitoring jobs being skipped, they should start running consistently now."
14
-
15
- ## Summary of New Capabilities
16
-
17
- | Capability | How to Use |
18
- |-----------|-----------|
19
- | Gate retry on transient failure | Automatic — no configuration needed |
@@ -1,19 +0,0 @@
1
- # Upgrade Guide — v0.28.11
2
-
3
- <!-- bump: patch -->
4
-
5
- ## What Changed
6
-
7
- The GET /context endpoint now includes the `contextDir` path in its response, making it possible for agents to verify that the server is looking in the same directory where their context files live. This helps diagnose the "0 bytes for all segments" issue that occurs when there's a path mismatch between the server's configured state directory and where hooks/sessions create context files.
8
-
9
- Response format changed from an array of segments to `{ contextDir: string, segments: [...] }`.
10
-
11
- ## What to Tell Your User
12
-
13
- - **Better context diagnostics**: "If your context segments ever show as empty despite files being on disk, the context endpoint now shows the exact directory path the server is checking. This makes it easy to spot path mismatches."
14
-
15
- ## Summary of New Capabilities
16
-
17
- | Capability | How to Use |
18
- |-----------|-----------|
19
- | Context directory path in response | GET /context now returns contextDir alongside segments |
@@ -1,11 +0,0 @@
1
- ## What Changed
2
-
3
- - **Prerequisites installer now auto-installs Homebrew on macOS.** Previously, on a fresh Mac without Homebrew, the installer would bail out and tell the user to install Homebrew manually. Now it offers to install Homebrew non-interactively using the official install script, then proceeds to install tmux via `brew install tmux`.
4
-
5
- ## What to Tell Your User
6
-
7
- Nothing — this is a seamless improvement to the setup experience. Users on fresh Macs will now be prompted to install Homebrew automatically instead of being told to do it themselves.
8
-
9
- ## Summary of New Capabilities
10
-
11
- - `npx instar` on a fresh macOS machine now handles the full dependency chain: Homebrew -> tmux -> Claude CLI, all with interactive prompts and no manual steps required.
@@ -1,11 +0,0 @@
1
- ## What Changed
2
-
3
- - **Fixed Homebrew installer failing on admin accounts.** The previous version used NONINTERACTIVE mode which prevented the sudo password prompt, causing installation to fail even on admin accounts with a misleading "needs to be an Administrator" error. Now stdio is inherited so the user can enter their password when prompted. Timeout also increased to 10 minutes to accommodate Xcode Command Line Tools installation.
4
-
5
- ## What to Tell Your User
6
-
7
- Nothing — this is a fix to the setup experience. Installing on a fresh Mac will now correctly prompt for the password instead of failing silently.
8
-
9
- ## Summary of New Capabilities
10
-
11
- No new capabilities — bug fix to Homebrew auto-install from 0.28.13.
@@ -1,12 +0,0 @@
1
- ## What Changed
2
-
3
- - **GitHub CLI is now a real prerequisite.** Previously the setup wizard only emitted a soft warning when gh was missing, then continued without it — silently disabling cloud-backed agent discovery, GitHub backup sync, CI status checks, and PR/issue management. GitHub CLI is now part of the prerequisites check alongside Node.js, tmux, and Claude CLI, with auto-install support via Homebrew on macOS and apt on Linux. If Homebrew is missing on macOS, the wizard offers to install Homebrew first (same flow as the existing tmux path).
4
-
5
- ## What to Tell Your User
6
-
7
- If you're on a fresh machine, the setup wizard will now offer to install GitHub CLI automatically. After install, I can help you sign in to GitHub so I can sync state across machines and discover any other agents you've set up. Without GitHub CLI, I still work locally but can't back things up to GitHub or find your other agents.
8
-
9
- ## Summary of New Capabilities
10
-
11
- - GitHub CLI added as a fourth prerequisite with auto-install on macOS (Homebrew) and Linux (apt)
12
- - Two-step install flow: if Homebrew is missing on macOS, wizard offers to install it before installing GitHub CLI
@@ -1,19 +0,0 @@
1
- # Upgrade Guide — vNEXT
2
-
3
- <!-- bump: patch -->
4
-
5
- ## What Changed
6
-
7
- - **Setup wizard now offers GitHub sign-in BEFORE asking for an agent name.** Previously, when GitHub CLI was installed but not authenticated (or when the discovery scan ran without GitHub access), the wizard silently moved on to "what should we call your agent?" — even if the user already had agents backed up to GitHub from another machine. Users were creating duplicates instead of restoring. The Entry Point B branches in `setup-wizard/SKILL.md` for `gh_status="auth-needed"` and `gh_status="unavailable"` are now MANDATORY blocking steps with imperative language.
8
- - **GitHub Device-Code Auth Flow documented.** Running `gh auth login --web --git-protocol https` synchronously inside Claude Code's Bash tool blocks on the device-code prompt and the user sees a frozen command with no instructions. The skill now instructs the agent to: run gh auth in the background, poll its output for the device code and URL, present them to the user conversationally, then poll `gh auth status` until the user completes the sign-in. Same flow is referenced from Phase 4 (cloud backup) so there's one canonical pattern.
9
-
10
- ## What to Tell Your User
11
-
12
- If you're setting up a fresh machine and you've used Instar before, the wizard will now offer to sign you in to GitHub first so I can find any agents you've backed up — instead of creating a duplicate. The sign-in itself is also smoother: I'll show you the code to enter at github.com/login/device right in our chat instead of leaving you staring at a stuck terminal.
13
-
14
- ## Summary of New Capabilities
15
-
16
- | Capability | How to Use |
17
- |-----------|-----------|
18
- | Mandatory pre-name GitHub auth offer | Automatic during setup wizard |
19
- | Background device-code auth flow | Automatic during setup wizard |
@@ -1,23 +0,0 @@
1
- # Upgrade Guide — v0.28.21
2
-
3
- <!-- bump: patch -->
4
-
5
- ## What Changed
6
-
7
- - **Threadline delivery honesty**: `/messages/relay-agent` now awaits `ThreadlineRouter` and returns the real outcome (`spawned`, `resumed`, `injected`, `queued`, `error`) instead of always saying `delivered:true`. The `threadline_send` MCP tool surfaces the actual status to callers.
8
- - **First-contact messages no longer dropped**: `ThreadlineRouter` mints a UUID threadId for messages without one, routing them through `spawnNewThread` instead of silently returning `{handled:false}`.
9
- - **Fingerprint-based identity**: Reply waiters rekeyed by threadId (prevents same-name agent collisions). Self-guard compares fingerprints. Ambiguous targets (multiple agents sharing a name) now fail loudly with a fingerprint-qualifier hint.
10
- - **Live-session injection**: `ThreadlineRouter` tries `MessageDelivery.deliverToSession` (tmux send-keys) before falling back to spawn/resume — messages can reach already-running sessions without spawning a new process.
11
-
12
- ## What to Tell Your User
13
-
14
- Agent-to-agent messaging (threadline) has been fixed. Messages between agents now actually reach the recipient's active session, first-contact messages work, and agents with the same name on different machines no longer collide.
15
-
16
- ## Summary of New Capabilities
17
-
18
- | Capability | How to Use |
19
- |-----------|-----------|
20
- | Honest delivery status | `threadline_send` now reports `spawned` / `resumed` / `injected` / `queued` instead of always `delivered` |
21
- | First-contact messaging | Just send — no threadId needed on first message, one is minted automatically |
22
- | Same-name agent disambiguation | Use `name:fpPrefix` format (e.g., `luna:ab12cd34`) when multiple agents share a name |
23
- | Live-session injection | Automatic — messages try injection into running sessions before spawning new ones |
@@ -1,23 +0,0 @@
1
- # Upgrade Guide — v0.28.22
2
-
3
- <!-- bump: patch -->
4
- <!-- Valid values: patch, minor, major -->
5
- <!-- patch = bug fixes, refactors, test additions, doc updates -->
6
- <!-- minor = new features, new APIs, new capabilities (backwards-compatible) -->
7
- <!-- major = breaking changes to existing APIs or behavior -->
8
-
9
- ## What Changed
10
-
11
- - Replaced all `execSync` calls in server startup (better-sqlite3 auto-rebuild) with shell-free `execFileSync` using npm's CLI JS directly. Fixes "spawnSync /bin/sh ENOENT" failures in minimal/containerized environments.
12
- - Added `findNpmCli()` helper that locates npm's entry point without requiring a shell.
13
- - Affects `ensureSqliteBindings()` preflight and TopicMemory auto-rebuild fallback.
14
-
15
- ## What to Tell Your User
16
-
17
- - **Better startup reliability**: "Agents running in Docker or minimal Linux environments should no longer see SemanticMemory or TopicMemory degradation at startup. The native module rebuild now works without requiring a system shell."
18
-
19
- ## Summary of New Capabilities
20
-
21
- | Capability | How to Use |
22
- |-----------|-----------|
23
- | Shell-free native module rebuild | Automatic — no user action needed |
@@ -1,19 +0,0 @@
1
- # Upgrade Guide — v0.28.23
2
-
3
- <!-- bump: patch -->
4
-
5
- ## What Changed
6
-
7
- - Replaced all shell-dependent npm calls in server startup (better-sqlite3 auto-rebuild) with shell-free alternatives using npm's CLI JS directly via Node.js. Fixes "spawnSync /bin/sh ENOENT" failures in minimal/containerized environments.
8
- - Added findNpmCli helper that locates npm's entry point without requiring a shell.
9
- - Affects ensureSqliteBindings preflight and TopicMemory auto-rebuild fallback.
10
-
11
- ## What to Tell Your User
12
-
13
- - **Better startup reliability**: "Agents running in Docker or minimal Linux environments should no longer see memory system degradation at startup. The native module rebuild now works without requiring a system shell."
14
-
15
- ## Summary of New Capabilities
16
-
17
- | Capability | How to Use |
18
- |-----------|-----------|
19
- | Shell-free native module rebuild | Automatic — no user action needed |
@@ -1,18 +0,0 @@
1
- # Upgrade Guide — v0.28.24
2
-
3
- <!-- bump: patch -->
4
-
5
- ## What Changed
6
-
7
- - The /semantic/export-memory endpoint no longer overwrites MEMORY.md when SemanticMemory has 0 entities. Previously, an empty export would destroy manually-curated memory content. Now skips the write and returns existing file metadata with a skipped flag.
8
- - MemoryExporter.write() guards against empty-entity overwrites at the class level.
9
-
10
- ## What to Tell Your User
11
-
12
- - **Memory file protection**: "Your MEMORY.md is now safe from accidental overwrites. If the knowledge graph hasn't been populated yet, the export will leave your existing memory file untouched instead of replacing it with an empty template."
13
-
14
- ## Summary of New Capabilities
15
-
16
- | Capability | How to Use |
17
- |-----------|-----------|
18
- | Empty-export guard | Automatic — no user action needed |
@@ -1,17 +0,0 @@
1
- # Upgrade Guide — v0.28.5
2
-
3
- <!-- bump: patch -->
4
-
5
- ## What Changed
6
-
7
- - **Topic cleanup no longer closes explicitly-configured topics**: The startup topic cleanup was closing forum topics for on-alert and silent jobs even when those topics were explicitly configured in jobs.json or shared with other active jobs. Now only dynamically-created topic mappings are cleaned up, and only if no other job references the same topic.
8
-
9
- ## What to Tell Your User
10
-
11
- - **"Your Telegram forum topics should stay open now"**: If your user noticed that certain Telegram topics kept getting closed after server restarts, that should be resolved. The system was incorrectly treating explicitly-configured topics as stale.
12
-
13
- ## Summary of New Capabilities
14
-
15
- | Capability | How to Use |
16
- |-----------|-----------|
17
- | Safe topic cleanup | Automatic — explicitly-configured topics are preserved on restart |
@@ -1,24 +0,0 @@
1
- # Upgrade Guide — v0.28.7
2
-
3
- <!-- bump: patch -->
4
- <!-- Valid values: patch, minor, major -->
5
- <!-- patch = bug fixes, refactors, test additions, doc updates -->
6
- <!-- minor = new features, new APIs, new capabilities (backwards-compatible) -->
7
- <!-- major = breaking changes to existing APIs or behavior -->
8
-
9
- ## What Changed
10
-
11
- Added `PATCH /config` endpoint that all FeatureDefinition enable/disable actions reference. Previously, toggling features from the dashboard (evolution, threadline, publishing, tunnel, etc.) returned 404 because the endpoint didn't exist. The new endpoint deep-merges the request body into config.json with an allowlist of safe config keys, and updates runtime config.
12
-
13
- Also includes CI test fixes from previous commits (trust wiring, quota tracking, config validation, job scheduler edge cases).
14
-
15
- ## What to Tell Your User
16
-
17
- - **Dashboard feature toggles now work**: "You can now enable/disable features from the dashboard — the toggle buttons actually persist your choice."
18
-
19
- ## Summary of New Capabilities
20
-
21
- | Capability | How to Use |
22
- |-----------|-----------|
23
- | Config patch API | `PATCH /config` with JSON body — dashboard uses this automatically |
24
- | Feature toggle persistence | Toggle features on/off from dashboard, changes persist to config.json |
@@ -1,21 +0,0 @@
1
- # Upgrade Guide — v0.28.8
2
-
3
- <!-- bump: patch -->
4
-
5
- ## What Changed
6
-
7
- Fixed a bug where `loadConfig()` silently dropped many optional config fields — including `safety`, `evolution`, `agentAutonomy`, `externalOperations`, `autonomyProfile`, `notifications`, `responseReview`, `inputGuard`, `dashboard`, and `moltbridge`. These fields were defined in `InstarConfig` and written to `config.json` by subsystems like `AutonomyProfileManager.applyProfileToConfig()`, but were never read back because `loadConfig()` constructed its return object with only explicitly listed properties.
8
-
9
- The fix spreads `fileConfig` as the base object before applying explicit overrides, so all config fields pass through while preserving existing defaults and transformations.
10
-
11
- **Impact**: If you had manually set `safety.level` in your config or changed autonomy profile settings, those overrides were being silently ignored — the system always fell back to profile defaults. After this update, your config file settings will be respected.
12
-
13
- ## What to Tell Your User
14
-
15
- - **Config settings now fully respected**: "If you've customized safety levels, autonomy settings, or other advanced configuration, those settings are now properly loaded. Previously they could be silently ignored — that's fixed now."
16
-
17
- ## Summary of New Capabilities
18
-
19
- | Capability | How to Use |
20
- |-----------|-----------|
21
- | Config passthrough fix | Automatic — all config.json fields now properly loaded |
package/upgrades/NEXT.md DELETED
@@ -1,35 +0,0 @@
1
- # Upgrade Guide — vNEXT
2
-
3
- <!-- bump: patch -->
4
- <!-- Valid values: patch, minor, major -->
5
- <!-- patch = bug fixes, refactors, test additions, doc updates -->
6
- <!-- minor = new features, new APIs, new capabilities (backwards-compatible) -->
7
- <!-- major = breaking changes to existing APIs or behavior -->
8
-
9
- ## What Changed
10
-
11
- <!-- Describe what changed technically. What new features, APIs, behavioral changes? -->
12
- <!-- Write this for the AGENT — they need to understand the system deeply. -->
13
-
14
- ## What to Tell Your User
15
-
16
- <!-- Write talking points the agent should relay to their user. -->
17
- <!-- This should be warm, conversational, user-facing — not a changelog. -->
18
- <!-- Focus on what THEY can now do, not internal plumbing. -->
19
- <!-- -->
20
- <!-- PROHIBITED in this section (will fail validation): -->
21
- <!-- camelCase config keys: silentReject, maxRetries, telegramNotify -->
22
- <!-- Inline code backtick references like silentReject: false -->
23
- <!-- Fenced code blocks -->
24
- <!-- Instructions to edit files or run commands -->
25
- <!-- -->
26
- <!-- CORRECT style: "I can turn that on for you" not "set X to false" -->
27
- <!-- The agent relays this to their user — keep it human. -->
28
-
29
- - **[Feature name]**: "[Brief, friendly description of what this means for the user]"
30
-
31
- ## Summary of New Capabilities
32
-
33
- | Capability | How to Use |
34
- |-----------|-----------|
35
- | [Capability] | [Endpoint, command, or "automatic"] |