instar 0.24.14 → 0.24.15
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.
- package/.claude/skills/setup-wizard/skill.md +5 -281
- package/dist/cli.js +0 -0
- package/package.json +1 -1
- package/src/data/builtin-manifest.json +3 -3
- package/upgrades/0.24.15.md +49 -0
- package/upgrades/0.24.11.md +0 -23
- package/upgrades/0.24.14.md +0 -26
- package/upgrades/0.24.6.md +0 -20
- package/upgrades/0.24.7.md +0 -24
- package/upgrades/0.24.8.md +0 -19
- package/upgrades/0.24.9.md +0 -19
- package/upgrades/NEXT.md +0 -35
- /package/.claude/skills/secret-setup/{SKILL.md → skill.md} +0 -0
|
@@ -511,9 +511,9 @@ This handles directory creation, registry entry, port allocation, and gitignore
|
|
|
511
511
|
|
|
512
512
|
Regardless of project or personal agent, **a messaging platform is how you talk to your agent**. This should be clear from the very first message. Don't present it as an optional add-on — it's the destination of this entire setup.
|
|
513
513
|
|
|
514
|
-
The terminal session is the on-ramp. Messaging (Telegram
|
|
514
|
+
The terminal session is the on-ramp. Messaging (Telegram or WhatsApp) is where the agent experience lives.
|
|
515
515
|
|
|
516
|
-
**Telegram is recommended** for its topic threads, bot API, and forum-style organization — but
|
|
516
|
+
**Telegram is recommended** for its topic threads, bot API, and forum-style organization — but WhatsApp is a fully supported alternative for users who prefer it or already live there.
|
|
517
517
|
|
|
518
518
|
## Phase 2: Identity Bootstrap — The Birth Conversation
|
|
519
519
|
|
|
@@ -788,8 +788,7 @@ Frame messaging as the core of the experience, then let the user choose their pl
|
|
|
788
788
|
> This is how you'll actually talk to your agent day-to-day. Not the terminal — just messaging on your phone or desktop.
|
|
789
789
|
>
|
|
790
790
|
> 1. **Telegram** (recommended) — Topic threads for organized conversations, powerful bot API, forum-style groups. Best for power users who want structured channels.
|
|
791
|
-
> 2. **
|
|
792
|
-
> 3. **WhatsApp** — Talk to your agent from the messaging app you already use. Simple, familiar, works everywhere.
|
|
791
|
+
> 2. **WhatsApp** — Talk to your agent from the messaging app you already use. Simple, familiar, works everywhere.
|
|
793
792
|
>
|
|
794
793
|
> Which do you prefer? (You can always add the other one later.)
|
|
795
794
|
|
|
@@ -797,16 +796,12 @@ Frame messaging as the core of the experience, then let the user choose their pl
|
|
|
797
796
|
|
|
798
797
|
> "Without a messaging platform, you'll only be able to talk to [agent name] by opening a terminal and running `instar chat`. No mobile access, no proactive messages, no organized threads. Most of what makes an Instar agent useful requires messaging."
|
|
799
798
|
>
|
|
800
|
-
> "You can set it up later with `instar telegram setup
|
|
799
|
+
> "You can set it up later with `instar telegram setup` or `instar whatsapp connect`."
|
|
801
800
|
|
|
802
801
|
### If User Chooses Telegram
|
|
803
802
|
|
|
804
803
|
Proceed with the Telegram setup flow below (Step 3b onward).
|
|
805
804
|
|
|
806
|
-
### If User Chooses Slack
|
|
807
|
-
|
|
808
|
-
Jump to **Phase 4h: Slack Setup**. Slack is a first-class option — treat it with the same energy and completeness as Telegram setup.
|
|
809
|
-
|
|
810
805
|
### If User Chooses WhatsApp
|
|
811
806
|
|
|
812
807
|
Jump to **Phase 4g: WhatsApp Setup**. WhatsApp is a first-class option — treat it with the same energy and completeness as Telegram setup.
|
|
@@ -1525,278 +1520,7 @@ If both Telegram and WhatsApp are configured, mention:
|
|
|
1525
1520
|
|
|
1526
1521
|
No additional config needed — CrossPlatformAlerts wires automatically in `server.ts` when both adapters are present.
|
|
1527
1522
|
|
|
1528
|
-
### 4h.
|
|
1529
|
-
|
|
1530
|
-
Slack is a **first-class messaging option**. The user may arrive here either:
|
|
1531
|
-
- **As their primary choice** from Phase 3 (chose Slack over Telegram/WhatsApp)
|
|
1532
|
-
- **As an additional channel** after Telegram or WhatsApp is already configured
|
|
1533
|
-
|
|
1534
|
-
**If arriving as primary choice from Phase 3**, skip the "want to add" prompt — they already chose this. Go straight to Step 4h-1.
|
|
1535
|
-
|
|
1536
|
-
**If arriving after Telegram/WhatsApp setup**, present:
|
|
1537
|
-
|
|
1538
|
-
> **Want to add Slack as an additional channel?**
|
|
1539
|
-
>
|
|
1540
|
-
> Slack lets you talk to your agent from Slack — channels, threads, reactions, and interactive buttons. It works alongside your other messaging platforms.
|
|
1541
|
-
>
|
|
1542
|
-
> 1. Yes, set up Slack
|
|
1543
|
-
> 2. Skip for now
|
|
1544
|
-
>
|
|
1545
|
-
> Type a number.
|
|
1546
|
-
|
|
1547
|
-
If they choose to skip, move to Phase 4i.
|
|
1548
|
-
|
|
1549
|
-
#### Step 4h-1: Browser Automation for Slack
|
|
1550
|
-
|
|
1551
|
-
**Use the same browser automation detection from Step 3a.** Playwright preferred, Chrome extension as fallback, manual as last resort.
|
|
1552
|
-
|
|
1553
|
-
Tell the user:
|
|
1554
|
-
|
|
1555
|
-
> I'm going to open a browser to set up Slack automatically. I'll create a workspace, configure an app, and set everything up.
|
|
1556
|
-
>
|
|
1557
|
-
> You'll need to log into Slack in the browser window. Ready?
|
|
1558
|
-
|
|
1559
|
-
Wait for confirmation before proceeding.
|
|
1560
|
-
|
|
1561
|
-
#### Step 4h-2: Navigate to Slack and Handle Login
|
|
1562
|
-
|
|
1563
|
-
Navigate to `https://slack.com/signin`. Take a snapshot.
|
|
1564
|
-
|
|
1565
|
-
**If already logged in** (redirected to a workspace or shows user avatar): Skip to Step 4h-3.
|
|
1566
|
-
|
|
1567
|
-
**If not logged in** (sign-in form visible):
|
|
1568
|
-
> "Please log into your Slack account in the browser window. You can use email, Google, or Apple sign-in. Let me know when you're logged in."
|
|
1569
|
-
|
|
1570
|
-
Wait for user confirmation. Take a snapshot to verify.
|
|
1571
|
-
|
|
1572
|
-
**If no Slack account:**
|
|
1573
|
-
> "You'll need a Slack account. Click 'Create an account' in the browser and follow the steps. Let me know when you're logged in."
|
|
1574
|
-
|
|
1575
|
-
#### Step 4h-3: Workspace Setup
|
|
1576
|
-
|
|
1577
|
-
Ask the user:
|
|
1578
|
-
|
|
1579
|
-
> I recommend creating a dedicated workspace for your agent — it keeps things clean and avoids privacy concerns with colleagues. Would you like me to create a dedicated workspace, or install into an existing one?
|
|
1580
|
-
|
|
1581
|
-
**If creating a new workspace:**
|
|
1582
|
-
|
|
1583
|
-
1. Navigate to `https://slack.com/get-started#/createnew`
|
|
1584
|
-
2. Take snapshot, find email field
|
|
1585
|
-
3. Type user's email (from USER.md or ask)
|
|
1586
|
-
4. Click "Continue"
|
|
1587
|
-
5. **WAIT** — user must enter 6-digit email verification code from their inbox
|
|
1588
|
-
> "Check your email for a 6-digit code from Slack and enter it in the browser."
|
|
1589
|
-
Wait for user confirmation.
|
|
1590
|
-
6. Take snapshot — workspace name field
|
|
1591
|
-
7. Type workspace name: `{agent-name}-agent` (e.g., "echo-agent")
|
|
1592
|
-
8. Click "Next"
|
|
1593
|
-
9. Take snapshot — project/channel name field
|
|
1594
|
-
10. Type "general"
|
|
1595
|
-
11. Click "Next"
|
|
1596
|
-
12. Take snapshot — invite page
|
|
1597
|
-
13. Click "Skip" or skip link
|
|
1598
|
-
14. Wait for workspace to load
|
|
1599
|
-
|
|
1600
|
-
**If using existing workspace:**
|
|
1601
|
-
1. Ask which workspace to use
|
|
1602
|
-
2. Navigate to the workspace URL
|
|
1603
|
-
3. Take snapshot to confirm workspace loaded
|
|
1604
|
-
|
|
1605
|
-
#### Step 4h-4: Create Slack App via Manifest
|
|
1606
|
-
|
|
1607
|
-
Build the app manifest JSON with minimal Phase 1 scopes:
|
|
1608
|
-
|
|
1609
|
-
```json
|
|
1610
|
-
{
|
|
1611
|
-
"display_information": {
|
|
1612
|
-
"name": "{agent-name}",
|
|
1613
|
-
"description": "Instar agent"
|
|
1614
|
-
},
|
|
1615
|
-
"features": {
|
|
1616
|
-
"bot_user": {
|
|
1617
|
-
"display_name": "{agent-name}",
|
|
1618
|
-
"always_online": true
|
|
1619
|
-
}
|
|
1620
|
-
},
|
|
1621
|
-
"oauth_config": {
|
|
1622
|
-
"scopes": {
|
|
1623
|
-
"bot": [
|
|
1624
|
-
"channels:history", "channels:manage", "channels:read",
|
|
1625
|
-
"chat:write", "im:history", "im:read", "im:write",
|
|
1626
|
-
"pins:write", "reactions:read", "reactions:write", "users:read"
|
|
1627
|
-
]
|
|
1628
|
-
}
|
|
1629
|
-
},
|
|
1630
|
-
"settings": {
|
|
1631
|
-
"event_subscriptions": {
|
|
1632
|
-
"bot_events": [
|
|
1633
|
-
"message.channels", "message.groups", "message.im",
|
|
1634
|
-
"file_shared", "reaction_added", "app_mention"
|
|
1635
|
-
]
|
|
1636
|
-
},
|
|
1637
|
-
"socket_mode_enabled": true,
|
|
1638
|
-
"org_deploy_enabled": false
|
|
1639
|
-
}
|
|
1640
|
-
}
|
|
1641
|
-
```
|
|
1642
|
-
|
|
1643
|
-
1. URL-encode the manifest JSON
|
|
1644
|
-
2. Navigate to: `https://api.slack.com/apps?new_app=1&manifest_json={ENCODED_JSON}`
|
|
1645
|
-
3. Take snapshot — workspace picker dropdown
|
|
1646
|
-
4. Select the target workspace from dropdown
|
|
1647
|
-
5. Click "Next"
|
|
1648
|
-
6. Take snapshot — manifest review/summary page
|
|
1649
|
-
7. Click "Create" button
|
|
1650
|
-
8. Wait 2-3 seconds for app creation
|
|
1651
|
-
9. Take snapshot — should be on app's Basic Information page
|
|
1652
|
-
10. Extract App ID from the URL (`api.slack.com/apps/A{APP_ID}/...`)
|
|
1653
|
-
|
|
1654
|
-
#### Step 4h-5: Install App to Workspace
|
|
1655
|
-
|
|
1656
|
-
1. Navigate to: `https://api.slack.com/apps/{APP_ID}/install-on-team`
|
|
1657
|
-
2. Take snapshot — "Install to Workspace" button
|
|
1658
|
-
3. Click "Install to Workspace"
|
|
1659
|
-
4. Take snapshot — OAuth authorization page
|
|
1660
|
-
5. Click "Allow"
|
|
1661
|
-
6. Wait for redirect back to app settings
|
|
1662
|
-
7. Take snapshot — OAuth & Permissions page
|
|
1663
|
-
8. **CRITICAL: DO NOT take screenshots/snapshots on this page** — it shows the bot token
|
|
1664
|
-
9. Extract Bot User OAuth Token (`xoxb-...`) from the page using regex. Pattern: `xoxb-\d+-\d+-[A-Za-z0-9]+`
|
|
1665
|
-
10. Store token in memory — do NOT log it
|
|
1666
|
-
|
|
1667
|
-
#### Step 4h-6: Enable Socket Mode & Generate App Token
|
|
1668
|
-
|
|
1669
|
-
1. Navigate to: `https://api.slack.com/apps/{APP_ID}/socket-mode`
|
|
1670
|
-
2. Take snapshot — Socket Mode toggle
|
|
1671
|
-
3. If toggle is OFF, click to enable it
|
|
1672
|
-
4. Navigate to: `https://api.slack.com/apps/{APP_ID}/general`
|
|
1673
|
-
5. Scroll to "App-Level Tokens" section
|
|
1674
|
-
6. Take snapshot — find "Generate Token and Scopes" button
|
|
1675
|
-
7. Click "Generate Token and Scopes"
|
|
1676
|
-
8. Take snapshot — token creation dialog
|
|
1677
|
-
9. Type token name: "socket-mode" in the name field
|
|
1678
|
-
10. Click "Add Scope"
|
|
1679
|
-
11. Select "connections:write" scope
|
|
1680
|
-
12. Click "Generate"
|
|
1681
|
-
13. **CRITICAL: DO NOT take screenshots/snapshots** — token is displayed
|
|
1682
|
-
14. Extract app-level token (`xapp-...`) from the dialog. Pattern: `xapp-\d+-[A-Za-z0-9]+-\d+-[A-Za-z0-9]+`
|
|
1683
|
-
15. Click "Done"
|
|
1684
|
-
|
|
1685
|
-
#### Step 4h-7: Validate Tokens
|
|
1686
|
-
|
|
1687
|
-
Validate both tokens via API (NOT browser):
|
|
1688
|
-
|
|
1689
|
-
```bash
|
|
1690
|
-
# Validate bot token and extract workspace info
|
|
1691
|
-
BOT_RESULT=$(curl -s -X POST https://slack.com/api/auth.test \
|
|
1692
|
-
-H "Authorization: Bearer ${BOT_TOKEN}" \
|
|
1693
|
-
-H "Content-Type: application/json")
|
|
1694
|
-
|
|
1695
|
-
# Expected: {"ok": true, "team_id": "T...", "user_id": "U...", "team": "workspace-name"}
|
|
1696
|
-
|
|
1697
|
-
# Validate app token
|
|
1698
|
-
APP_RESULT=$(curl -s -X POST https://slack.com/api/apps.connections.open \
|
|
1699
|
-
-H "Authorization: Bearer ${APP_TOKEN}" \
|
|
1700
|
-
-H "Content-Type: application/json")
|
|
1701
|
-
|
|
1702
|
-
# Expected: {"ok": true, "url": "wss://..."}
|
|
1703
|
-
```
|
|
1704
|
-
|
|
1705
|
-
If either fails, tell the user and offer to retry the extraction step.
|
|
1706
|
-
|
|
1707
|
-
Extract from `BOT_RESULT`:
|
|
1708
|
-
- `team_id` → `workspaceId`
|
|
1709
|
-
- `team` → `workspaceName`
|
|
1710
|
-
- `user_id` → add to `authorizedUserIds` (this is the installing user)
|
|
1711
|
-
|
|
1712
|
-
#### Step 4h-8: Create System Channels
|
|
1713
|
-
|
|
1714
|
-
```bash
|
|
1715
|
-
# Create lifeline channel
|
|
1716
|
-
LIFELINE=$(curl -s -X POST https://slack.com/api/conversations.create \
|
|
1717
|
-
-H "Authorization: Bearer ${BOT_TOKEN}" \
|
|
1718
|
-
-H "Content-Type: application/json" \
|
|
1719
|
-
-d '{"name": "{agent}-sys-lifeline"}')
|
|
1720
|
-
|
|
1721
|
-
# Create dashboard channel
|
|
1722
|
-
DASHBOARD=$(curl -s -X POST https://slack.com/api/conversations.create \
|
|
1723
|
-
-H "Authorization: Bearer ${BOT_TOKEN}" \
|
|
1724
|
-
-H "Content-Type: application/json" \
|
|
1725
|
-
-d '{"name": "{agent}-sys-dashboard"}')
|
|
1726
|
-
|
|
1727
|
-
# Pin a welcome message in lifeline
|
|
1728
|
-
curl -s -X POST https://slack.com/api/chat.postMessage \
|
|
1729
|
-
-H "Authorization: Bearer ${BOT_TOKEN}" \
|
|
1730
|
-
-H "Content-Type: application/json" \
|
|
1731
|
-
-d '{"channel": "LIFELINE_ID", "text": "Lifeline channel active. This is where I send critical system messages."}'
|
|
1732
|
-
```
|
|
1733
|
-
|
|
1734
|
-
#### Step 4h-9: Write Configuration
|
|
1735
|
-
|
|
1736
|
-
Write Slack config to `.instar/config.json`:
|
|
1737
|
-
|
|
1738
|
-
```javascript
|
|
1739
|
-
node -e "
|
|
1740
|
-
const fs = require('fs');
|
|
1741
|
-
const p = '<project_dir>/.instar/config.json';
|
|
1742
|
-
const c = JSON.parse(fs.readFileSync(p, 'utf-8'));
|
|
1743
|
-
c.messaging = c.messaging || [];
|
|
1744
|
-
// Remove existing slack config if any
|
|
1745
|
-
c.messaging = c.messaging.filter(m => m.type !== 'slack');
|
|
1746
|
-
c.messaging.push({
|
|
1747
|
-
type: 'slack',
|
|
1748
|
-
enabled: true,
|
|
1749
|
-
config: {
|
|
1750
|
-
botToken: '${BOT_TOKEN}',
|
|
1751
|
-
appToken: '${APP_TOKEN}',
|
|
1752
|
-
workspaceId: '${WORKSPACE_ID}',
|
|
1753
|
-
workspaceName: '${WORKSPACE_NAME}',
|
|
1754
|
-
authorizedUserIds: ['${USER_ID}'],
|
|
1755
|
-
stallTimeoutMinutes: 5,
|
|
1756
|
-
logRetentionDays: 90,
|
|
1757
|
-
lifelineChannelId: '${LIFELINE_CHANNEL_ID}',
|
|
1758
|
-
dashboardChannelId: '${DASHBOARD_CHANNEL_ID}'
|
|
1759
|
-
}
|
|
1760
|
-
});
|
|
1761
|
-
fs.writeFileSync(p, JSON.stringify(c, null, 2));
|
|
1762
|
-
fs.chmodSync(p, 0o600);
|
|
1763
|
-
"
|
|
1764
|
-
```
|
|
1765
|
-
|
|
1766
|
-
#### Step 4h-10: Confirm Success and Close Browser
|
|
1767
|
-
|
|
1768
|
-
Close the browser (Playwright: `browser_close()`).
|
|
1769
|
-
|
|
1770
|
-
Tell the user:
|
|
1771
|
-
|
|
1772
|
-
> Slack is set up! Your workspace '{workspaceName}' is ready.
|
|
1773
|
-
> I've created your system channels and configured everything.
|
|
1774
|
-
>
|
|
1775
|
-
> Important: Your bot tokens provide full access to your Slack workspace — treat them like passwords. They don't expire, so if you suspect compromise, revoke them at api.slack.com/apps.
|
|
1776
|
-
>
|
|
1777
|
-
> Would you like me to store your tokens in Bitwarden for extra security? (recommended)
|
|
1778
|
-
|
|
1779
|
-
If they accept Bitwarden, trigger the `secret-setup` skill.
|
|
1780
|
-
|
|
1781
|
-
#### Slack Manual Fallback
|
|
1782
|
-
|
|
1783
|
-
**Only use this if NO browser automation tools are available.** If automation failed partway, tell the user exactly what succeeded.
|
|
1784
|
-
|
|
1785
|
-
Walk the user through:
|
|
1786
|
-
|
|
1787
|
-
1. Go to `https://slack.com/get-started#/createnew` and create a workspace (or use existing)
|
|
1788
|
-
2. Go to `https://api.slack.com/apps?new_app=1` → click "From a manifest"
|
|
1789
|
-
3. Select your workspace
|
|
1790
|
-
4. Paste this manifest: [provide the JSON from Step 4h-4]
|
|
1791
|
-
5. Click Create, then Install to Workspace, then Allow
|
|
1792
|
-
6. Go to Basic Information → App-Level Tokens → Generate Token and Scopes
|
|
1793
|
-
7. Name: "socket-mode", Scope: "connections:write", click Generate
|
|
1794
|
-
8. Copy both tokens (bot token from OAuth page, app token from Basic Info)
|
|
1795
|
-
9. Run: `instar add slack` and paste the tokens when prompted
|
|
1796
|
-
|
|
1797
|
-
Even in manual mode, system channel creation (Step 4h-8) and config writing (Step 4h-9) are done by the wizard, not the user.
|
|
1798
|
-
|
|
1799
|
-
### 4i. Agent Network
|
|
1523
|
+
### 4h. Agent Network
|
|
1800
1524
|
|
|
1801
1525
|
Your agent can join a secure network to communicate with other AI agents. Present this as an optional but recommended step:
|
|
1802
1526
|
|
package/dist/cli.js
CHANGED
|
File without changes
|
package/package.json
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"$schema": "./builtin-manifest.schema.json",
|
|
3
3
|
"schemaVersion": 1,
|
|
4
|
-
"generatedAt": "2026-03-
|
|
5
|
-
"instarVersion": "0.24.
|
|
4
|
+
"generatedAt": "2026-03-28T05:35:45.493Z",
|
|
5
|
+
"instarVersion": "0.24.15",
|
|
6
6
|
"entryCount": 178,
|
|
7
7
|
"entries": {
|
|
8
8
|
"hook:session-start": {
|
|
@@ -352,7 +352,7 @@
|
|
|
352
352
|
"type": "skill",
|
|
353
353
|
"domain": "skills",
|
|
354
354
|
"sourcePath": ".claude/skills/setup-wizard/skill.md",
|
|
355
|
-
"contentHash": "
|
|
355
|
+
"contentHash": "84839d6c1acbb51049cade14b000d64c943a20580b4676f3c14b2ef33cc5874a",
|
|
356
356
|
"since": "2025-01-01"
|
|
357
357
|
},
|
|
358
358
|
"route-group:health": {
|
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
# Upgrade Guide — vNEXT
|
|
2
|
+
|
|
3
|
+
<!-- bump: minor -->
|
|
4
|
+
|
|
5
|
+
## What Changed
|
|
6
|
+
|
|
7
|
+
### Slack Messaging Adapter
|
|
8
|
+
|
|
9
|
+
Instar now includes a full Slack messaging adapter (`SlackAdapter`), enabling agents to send and receive messages via Slack workspaces. The adapter supports:
|
|
10
|
+
|
|
11
|
+
- Sending messages to channels and threads
|
|
12
|
+
- Token validation and secure credential handling
|
|
13
|
+
- Atomic write operations for message persistence
|
|
14
|
+
- CLI tooling for Slack interaction (`slack-cli`)
|
|
15
|
+
- Server-side routes for Slack webhook integration
|
|
16
|
+
|
|
17
|
+
The adapter follows the same pattern as existing messaging adapters (Telegram, WhatsApp) and plugs into the unified channel routing system.
|
|
18
|
+
|
|
19
|
+
### Server-Side Process Review Dashboard
|
|
20
|
+
|
|
21
|
+
A new Systems tab on the dashboard provides real-time visibility into server processes. This includes:
|
|
22
|
+
|
|
23
|
+
- Process telemetry collection and display
|
|
24
|
+
- Health status monitoring for running services
|
|
25
|
+
- Integration with the existing dashboard infrastructure
|
|
26
|
+
|
|
27
|
+
### Architecture Documentation
|
|
28
|
+
|
|
29
|
+
A new "Under the Hood" page on the documentation site explains Instar's internal architecture, giving developers and agents a clearer picture of how the system is structured.
|
|
30
|
+
|
|
31
|
+
### CI Stability Improvements
|
|
32
|
+
|
|
33
|
+
Several CI fixes improve reliability: resolved flaky test exclusions, fixed WhatsApp string test, added `skipStallClear` option to prevent stall-clear interference during topic sends, and fixed test failures blocking the push gate.
|
|
34
|
+
|
|
35
|
+
## What to Tell Your User
|
|
36
|
+
|
|
37
|
+
- **Slack support is here**: Your agent can now send and receive messages through Slack. If your team uses Slack, you can connect it as a messaging channel alongside Telegram and other platforms. Ask your agent to set it up for you.
|
|
38
|
+
|
|
39
|
+
- **Better visibility into what is running**: There is a new Systems tab on your dashboard that shows what server processes are active and their health status. Useful for troubleshooting if something feels off.
|
|
40
|
+
|
|
41
|
+
- **More reliable updates**: Several under-the-hood fixes make the CI pipeline more stable, which means smoother and more frequent releases going forward.
|
|
42
|
+
|
|
43
|
+
## Summary of New Capabilities
|
|
44
|
+
|
|
45
|
+
| Capability | How to Use |
|
|
46
|
+
|-----------|-----------|
|
|
47
|
+
| Slack messaging | Configure Slack token via CLI, then messages route automatically |
|
|
48
|
+
| Process review dashboard | Visit the Systems tab on your Instar dashboard |
|
|
49
|
+
| Architecture docs | Check the "Under the Hood" page on the docs site |
|
package/upgrades/0.24.11.md
DELETED
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
# Upgrade Guide — v0.24.11
|
|
2
|
-
|
|
3
|
-
<!-- bump: patch -->
|
|
4
|
-
|
|
5
|
-
## What Changed
|
|
6
|
-
|
|
7
|
-
- **Health endpoint no longer blocks on stale sessions**: The health check previously called synchronous tmux operations for every tracked session, blocking the event loop. With many stale sessions (common after restart loops), this caused health check timeouts, which triggered MORE restarts — a death spiral. Now uses a cached session count updated asynchronously by the monitor tick.
|
|
8
|
-
|
|
9
|
-
- **Startup session purge**: Before monitoring starts, the server now does a fast one-pass purge of all session records whose tmux sessions no longer exist. Uses a 1-second timeout per session to fail fast. This prevents the startup overload where the server spent all its boot time polling dead sessions.
|
|
10
|
-
|
|
11
|
-
- **CoherenceMonitor suppresses known-pending updates**: When the AutoUpdater has already applied a version and a restart is pending (deferred for active sessions), the CoherenceMonitor no longer flags the version mismatch as a failure. This eliminates the race condition where both systems fought over restart decisions.
|
|
12
|
-
|
|
13
|
-
## What to Tell Your User
|
|
14
|
-
|
|
15
|
-
- **Stability improvement**: "The server should be much more resilient to restart loops now. Even if many sessions build up, the health check stays fast and the server won't get stuck in a crash-restart cycle. Stale sessions are cleaned up instantly on boot instead of dragging things down."
|
|
16
|
-
|
|
17
|
-
## Summary of New Capabilities
|
|
18
|
-
|
|
19
|
-
| Capability | How to Use |
|
|
20
|
-
|-----------|-----------|
|
|
21
|
-
| Non-blocking health endpoint | Automatic — no action needed |
|
|
22
|
-
| Startup session purge | Automatic — runs on every server boot |
|
|
23
|
-
| CoherenceMonitor update suppression | Automatic — no action needed |
|
package/upgrades/0.24.14.md
DELETED
|
@@ -1,26 +0,0 @@
|
|
|
1
|
-
# Upgrade Guide — v0.24.14
|
|
2
|
-
|
|
3
|
-
## What Changed
|
|
4
|
-
|
|
5
|
-
### Server Supervisor Self-Healing
|
|
6
|
-
|
|
7
|
-
The ServerSupervisor now runs preflight diagnostics before every server spawn attempt. Previously, if the shadow install was missing or the node symlink was broken, the server would crash immediately on startup — and restarting via `/lifeline restart` would just repeat the same failure.
|
|
8
|
-
|
|
9
|
-
Now, before each spawn, the supervisor checks and auto-repairs:
|
|
10
|
-
|
|
11
|
-
- **Missing shadow install** — reinstalls via npm automatically
|
|
12
|
-
- **Broken node symlink** — recreates it from available node binaries
|
|
13
|
-
- **Stale lifeline locks** — removes locks older than 10 minutes
|
|
14
|
-
|
|
15
|
-
This means `/lifeline restart` now actually fixes the problem instead of blindly retrying a broken state. Agents on remote machines can self-recover from common post-update failures without manual SSH intervention.
|
|
16
|
-
|
|
17
|
-
## What to Tell Your User
|
|
18
|
-
|
|
19
|
-
Your agent's server is now more resilient. If the server goes down due to a missing or corrupted install, the system will automatically detect and fix the issue before restarting. The /lifeline restart command in Telegram now does real recovery, not just a blind retry.
|
|
20
|
-
|
|
21
|
-
## Summary of New Capabilities
|
|
22
|
-
|
|
23
|
-
- **Preflight self-healing**: Server supervisor diagnoses and fixes common startup failures before each spawn
|
|
24
|
-
- **Shadow install auto-repair**: Missing shadow installs are reinstalled automatically
|
|
25
|
-
- **Node symlink recovery**: Broken node symlinks are recreated from available binaries
|
|
26
|
-
- **Stale lock cleanup**: Old lifeline locks are removed to prevent restart deadlocks
|
package/upgrades/0.24.6.md
DELETED
|
@@ -1,20 +0,0 @@
|
|
|
1
|
-
# Upgrade Guide — v0.24.6
|
|
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
|
-
- **PermissionRequest auto-approve hook**: Subagents spawned via the Agent tool don't inherit `--dangerously-skip-permissions` from the parent session. This caused permission prompts that blocked autonomous work. A new catch-all `PermissionRequest` hook (`auto-approve-permissions.js`) unconditionally approves all permission requests. Real safety remains in PreToolUse hooks.
|
|
12
|
-
- The hook is automatically added to `settings.json` during init and on upgrade via PostUpdateMigrator.
|
|
13
|
-
|
|
14
|
-
## What to Tell Your User
|
|
15
|
-
|
|
16
|
-
No user-facing changes. This fix ensures autonomous sessions and subagents run without interruption.
|
|
17
|
-
|
|
18
|
-
## Summary of New Capabilities
|
|
19
|
-
|
|
20
|
-
- Auto-approve permissions for subagent sessions (prevents blocking on tool use prompts)
|
package/upgrades/0.24.7.md
DELETED
|
@@ -1,24 +0,0 @@
|
|
|
1
|
-
# Upgrade Guide — v0.24.7
|
|
2
|
-
|
|
3
|
-
<!-- bump: patch -->
|
|
4
|
-
|
|
5
|
-
## What Changed
|
|
6
|
-
|
|
7
|
-
- **Tunnel reconnect storm fix**: Added a start mutex to TunnelManager so concurrent `start()` calls coalesce instead of racing. Sleep/wake handler now disables auto-reconnect before force-stopping the tunnel, preventing exit handlers from spawning competing reconnection chains. Previously, sleep/wake cycles could trigger dozens of concurrent tunnel reconnection attempts.
|
|
8
|
-
|
|
9
|
-
- **Non-fatal crash prevention**: The uncaught exception handler no longer crashes the server for "Cannot set headers after they are sent to the client" and similar HTTP lifecycle errors. These are expected during tunnel transitions and don't affect server stability. Previously, a single double-response event would kill the entire server process.
|
|
10
|
-
|
|
11
|
-
- **Lifeline startup grace period fix**: During the 3-minute startup grace period, the Lifeline now probes health optimistically. Previously, health checks were completely skipped during boot, causing incoming Telegram messages to be queued with "Server is temporarily down" even when the server was fully responsive (typically within ~10 seconds of restart).
|
|
12
|
-
|
|
13
|
-
- **Queue delivery confirmation**: When queued messages are replayed after server recovery, the Lifeline now sends a per-topic confirmation ("Server recovered — your queued message has been delivered") so users know their message actually reached the session.
|
|
14
|
-
|
|
15
|
-
## What to Tell Your User
|
|
16
|
-
|
|
17
|
-
Server stability improvements. The server is much less likely to restart unexpectedly, and when it does restart, your messages should flow through almost immediately instead of being queued for up to 3 minutes. You'll also get a confirmation when any queued messages are delivered.
|
|
18
|
-
|
|
19
|
-
## Summary of New Capabilities
|
|
20
|
-
|
|
21
|
-
- Tunnel reconnection is now atomic — no more reconnect storms after sleep/wake
|
|
22
|
-
- Non-fatal HTTP errors are logged as warnings instead of crashing the server
|
|
23
|
-
- Messages reach sessions within seconds of a restart instead of waiting 3 minutes
|
|
24
|
-
- Queued message delivery is confirmed via Telegram
|
package/upgrades/0.24.8.md
DELETED
|
@@ -1,19 +0,0 @@
|
|
|
1
|
-
# Upgrade Guide — v0.24.8
|
|
2
|
-
|
|
3
|
-
<!-- bump: patch -->
|
|
4
|
-
|
|
5
|
-
## What Changed
|
|
6
|
-
|
|
7
|
-
- **Lifeline auto-restart after update**: When the server recovers from a planned update restart, the supervisor now emits an `updateApplied` event. The lifeline listens for this and self-exits after a 5-second flush delay. launchd KeepAlive respawns it with the updated shadow install binary. This ensures both the server AND lifeline always run the same version after an update.
|
|
8
|
-
|
|
9
|
-
- Both restart detection paths are covered: when the supervisor reads the restart request directly, and when the ForegroundRestartWatcher consumes it first (via the planned-exit marker).
|
|
10
|
-
|
|
11
|
-
## What to Tell Your User
|
|
12
|
-
|
|
13
|
-
- **Seamless updates**: "Updates now apply to the entire system automatically — both the server and the Telegram connection. Previously, part of the system could run stale code after an update until the machine rebooted. Now everything picks up new code within seconds."
|
|
14
|
-
|
|
15
|
-
## Summary of New Capabilities
|
|
16
|
-
|
|
17
|
-
| Capability | How to Use |
|
|
18
|
-
|-----------|-----------|
|
|
19
|
-
| Lifeline auto-restart on update | Automatic — no action needed |
|
package/upgrades/0.24.9.md
DELETED
|
@@ -1,19 +0,0 @@
|
|
|
1
|
-
# Upgrade Guide — v0.24.9
|
|
2
|
-
|
|
3
|
-
<!-- bump: patch -->
|
|
4
|
-
|
|
5
|
-
## What Changed
|
|
6
|
-
|
|
7
|
-
- **Restart window**: New config option to control when update restarts happen. When set, automatic restarts are deferred until the configured time window. Updates are still downloaded and applied to the shadow install immediately — only the process restart is held. Manual triggers via the API or conversational commands bypass the window.
|
|
8
|
-
|
|
9
|
-
- Configurable in the agent's config at the path "updates.restartWindow" with start and end times in 24-hour local time format. Supports windows that wrap midnight (e.g., 23:00-05:00).
|
|
10
|
-
|
|
11
|
-
## What to Tell Your User
|
|
12
|
-
|
|
13
|
-
- **Restart window**: "I can now schedule update restarts for off-hours so they don't disrupt your workflow. Updates still download instantly, but the actual server restart waits for the quiet window. If you ever need an immediate update, just ask — manual triggers always work regardless of the window."
|
|
14
|
-
|
|
15
|
-
## Summary of New Capabilities
|
|
16
|
-
|
|
17
|
-
| Capability | How to Use |
|
|
18
|
-
|-----------|-----------|
|
|
19
|
-
| Restart window | Set "updates.restartWindow" in config with start/end times (e.g., "02:00"-"05:00") |
|
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"] |
|
|
File without changes
|