100	James operates as VP of Product over his project portfolio; you are the interface.
101	The board lives at `/workspace/extra/second-brain/portfolio/` — `BOARD.md` (index +
102	decision queue), `projects/*.md` (one card per project), `PLAN.md` (operating model +
103	decisions; read it once for context).
104
105	**Daily brief** (scheduled task, 07:00 America/Chicago, posted to #daily-brief Slack channel, destination: `slack-daily-brief`):
106	1. Read `BOARD.md`, the project cards, and `repo-awareness.md` (its `Last activity`
107	   lines are refreshed every 30 min from git).
108	2. Send a short brief (~under 20 lines, phone-readable):
109	   - *Moved*: projects with new activity since the last brief
110	   - *Stalled*: anything `Blocked on James` more than ~2 days
111	   - *Decisions* (max 3, numbered): concrete questions James can answer with a short
112	     reply like "1: yes, 2: option b". While cards still say "seeded — confirm",
113	     confirming one card's goal counts as a decision question. At most one
114	     "name the metric" question at a time.
115	   - Where a decision/update warrants deeper discussion, link to the project channel
116	     (e.g. "→ details in #qip-qien").
117	3. When James replies: update the card (Goal / Stage / Next action; append a dated
118	   line to its Notes), update the BOARD.md row, and remove answered items from the
119	   Decision queue.
120
121	Rules: never invent goals — ask. Stage vocabulary is fixed:
122	`research → discovery → spec → build → test → feedback → maintain`. Guard field is
123	per-project: `review-required` (TradingBot25, qip-qien — James approves merges) vs
124	`autonomous-ok` (never block on James). Keep the brief phone-readable; no walls of text.
125
126	## Autopilot running-lock protocol
127
128	**Every autopilot turn** must write `/workspace/agent/autopilot-running-lock.json` at the very start (before reading the board or doing any work) and remove it at the very end (after logging the outcome and before the final message). Format:
129	```json
130	{"started_at":"<ISO timestamp>"}
131	```
132	This prevents overlapping runs: `autopilot-trigger.mjs` checks this file and returns `wakeAgent: false` if the lock is < 45 minutes old. The previous fix (skip-lock only) had a race condition — tasks pre-queued before the lock was written would still fire. The running lock is written at turn-start, eliminating that window.
133
134	Remove the file with: `rm /workspace/agent/autopilot-running-lock.json`
135
136	If the agent crashes and leaves a stale lock, the 45-minute age cutoff auto-expires it.
137
138	## Automated monitoring tasks
139
140	- **GitHub (Anthropic):** Scheduled daily at 3am CT — task `task-1779715363838-v6s2ql`. Monitors anthropics org repos and anthropics/skills commits. (Changed from every 2h per James's request 2026-06-04.)
141	- **YouTube (podcast channels):** Scheduled every 6h — task `task-1779717229224-qeenhv`. Monitors Behind the Craft (Peter Yang, `UCnpBg7yqNauHtlNSpOl5-cg`), Authority Hacker Podcast (`UCTvgSAxisCh58hjzlMdED0A`), and Claude/Code with Claude workshops channel (`UCV03SRZXJEz-hchIAogeJOg`). AI Cookbook Show channel TBD (pending James confirmation). Script: `/workspace/agent/youtube-monitor.mjs`. State: `/workspace/agent/youtube-monitor-state.json`. Note: Anthropic channel (`UCrDwWp7EBBv4NwvScIpBDOA`) not added — broader/marketing content.
142	- **Claude blog (claude.com/blog):** Scheduled every 6h — task `task-1780488302705-fg2aaq`. Script: `/workspace/agent/claude-blog-monitor.mjs`. State: `/workspace/agent/claude-blog-state.json`. Ingest relevant posts (Claude Code features, agent SDKs, workflows, plugins, founder/engineering content). Skip: customer case studies for specific industries, compliance/partner announcements without new capabilities.
143	- **X/Twitter:** Dropped — James doesn't want to pay for X API access ($100/mo Basic tier required for reading tweets).
144

James operates as VP of Product over his project portfolio; you are the interface.
The board lives at `/workspace/extra/second-brain/portfolio/` — `BOARD.md` (index +
decision queue), `projects/*.md` (one card per project), `PLAN.md` (operating model +
decisions; read it once for context).

**Daily brief** (scheduled task, 07:00 America/Chicago, posted to #daily-brief Slack channel, destination: `slack-daily-brief`):
1. Read `BOARD.md`, the project cards, and `repo-awareness.md` (its `Last activity`
   lines are refreshed every 30 min from git).
2. Send a short brief (~under 20 lines, phone-readable):
   - *Moved*: projects with new activity since the last brief
   - *Stalled*: anything `Blocked on James` more than ~2 days
   - *Decisions* (max 3, numbered): concrete questions James can answer with a short
     reply like "1: yes, 2: option b". While cards still say "seeded — confirm",
     confirming one card's goal counts as a decision question. At most one
     "name the metric" question at a time.
   - Where a decision/update warrants deeper discussion, link to the project channel
     (e.g. "→ details in #qip-qien").
3. When James replies: update the card (Goal / Stage / Next action; append a dated
   line to its Notes), update the BOARD.md row, and remove answered items from the
   Decision queue.

Rules: never invent goals — ask. Stage vocabulary is fixed:
`research → discovery → spec → build → test → feedback → maintain`. Guard field is
per-project: `review-required` (TradingBot25, qip-qien — James approves merges) vs
`autonomous-ok` (never block on James). Keep the brief phone-readable; no walls of text.

## Autopilot running-lock protocol

**Every autopilot turn** must write `/workspace/agent/autopilot-running-lock.json` at the very start (before reading the board or doing any work) and remove it at the very end (after logging the outcome and before the final message). Format:
```json
{"started_at":"<ISO timestamp>"}
```
This prevents overlapping runs: `autopilot-trigger.mjs` checks this file and returns `wakeAgent: false` if the lock is < 45 minutes old. The previous fix (skip-lock only) had a race condition — tasks pre-queued before the lock was written would still fire. The running lock is written at turn-start, eliminating that window.

Remove the file with: `rm /workspace/agent/autopilot-running-lock.json`

If the agent crashes and leaves a stale lock, the 45-minute age cutoff auto-expires it.

## Automated monitoring tasks

- **GitHub (Anthropic):** Scheduled daily at 3am CT — task `task-1779715363838-v6s2ql`. Monitors anthropics org repos and anthropics/skills commits. (Changed from every 2h per James's request 2026-06-04.)
- **YouTube (podcast channels):** Scheduled every 6h — task `task-1779717229224-qeenhv`. Monitors Behind the Craft (Peter Yang, `UCnpBg7yqNauHtlNSpOl5-cg`), Authority Hacker Podcast (`UCTvgSAxisCh58hjzlMdED0A`), and Claude/Code with Claude workshops channel (`UCV03SRZXJEz-hchIAogeJOg`). AI Cookbook Show channel TBD (pending James confirmation). Script: `/workspace/agent/youtube-monitor.mjs`. State: `/workspace/agent/youtube-monitor-state.json`. Note: Anthropic channel (`UCrDwWp7EBBv4NwvScIpBDOA`) not added — broader/marketing content.
- **Claude blog (claude.com/blog):** Scheduled every 6h — task `task-1780488302705-fg2aaq`. Script: `/workspace/agent/claude-blog-monitor.mjs`. State: `/workspace/agent/claude-blog-state.json`. Ingest relevant posts (Claude Code features, agent SDKs, workflows, plugins, founder/engineering content). Skip: customer case studies for specific industries, compliance/partner announcements without new capabilities.
- **X/Twitter:** Dropped — James doesn't want to pay for X API access ($100/mo Basic tier required for reading tweets).


Now I need to update the "Autopilot running-lock protocol" section to also document the skip-lock format. Let me add a section about the skip-lock format.

The current section talks about the running-lock but doesn't mention the skip-lock format. I need to add documentation for the skip-lock.

Let me edit CLAUDE.local.md to add the skip-lock format documentation.


Edit

## Autopilot running-lock protocol

**Every autopilot turn** must write `/workspace/agent/autopilot-running-lock.json` at the very start (before reading the board or doing any work) and remove it at the very end (after logging the outcome and before the final message). Format:
```json
{"started_at":"<ISO timestamp>"}
```
This prevents overlapping runs: `autopilot-trigger.mjs` checks this file and returns `wakeAgent: false` if the lock is < 45 minutes old. The previous fix (skip-lock only) had a race condition — tasks pre-queued before the lock was written would still fire. The running lock is written at turn-start, eliminating that window.

Remove the file with: `rm /workspace/agent/autopilot-running-lock.json`

If the agent crashes and leaves a stale lock, the 45-minute age cutoff auto-expires it.

## Autopilot running-lock protocol

**Every autopilot turn** must write `/workspace/agent/autopilot-running-lock.json` at the very start (before reading the board or doing any work) and remove it at the very end (after logging the outcome and before the final message). Format:
```json
{"started_at":"<ISO timestamp>"}
```
This prevents overlapping runs: `autopilot-trigger.mjs` checks this file and returns `wakeAgent: false` if the lock is < 45 minutes old. The previous fix (skip-lock only) had a race condition — tasks pre-queued before the lock was written would still fire. The running lock is written at turn-start, eliminating that window.

Remove the file with: `rm /workspace/agent/autopilot-running-lock.json`

If the agent crashes and leaves a stale lock, the 45-minute age cutoff auto-expires it.

## Autopilot skip-lock format (CRITICAL)

When writing an all-blocked skip-lock, the file **must** include `skip_lock_until` — that is the field the trigger script checks (`autopilot-trigger.mjs` line 29: `lock.skip_lock_until && new Date(lock.skip_lock_until) > new Date()`). A file without this field is silently ignored and the trigger keeps firing.

Correct format — set `skip_lock_until` to the next quota reset time:
```json
{"skip_lock_until":"<next_reset_at ISO timestamp>","reason":"<why>","written_at":"<now ISO timestamp>"}
```

Bug history: 2026-07-24 — agent wrote `written_at` only (no `skip_lock_until`), causing the trigger to fire again 37 minutes after an all-blocked cycle.


The file /workspace/agent/CLAUDE.local.md has been updated successfully. (file state is current in your context — no need to Read it back)

## Autopilot running-lock protocol

**Every autopilot turn** must write `/workspace/agent/autopilot-running-lock.json` at the very start (before reading the board or doing any work) and remove it at the very end (after logging the outcome and before the final message). Format:
```json
{"started_at":"<ISO timestamp>"}
```
This prevents overlapping runs: `autopilot-trigger.mjs` checks this file and returns `wakeAgent: false` if the lock is < 45 minutes old. The previous fix (skip-lock only) had a race condition — tasks pre-queued before the lock was written would still fire. The running lock is written at turn-start, eliminating that window.

Remove the file with: `rm /workspace/agent/autopilot-running-lock.json`

If the agent crashes and leaves a stale lock, the 45-minute age cutoff auto-expires it.

## Autopilot skip-lock format (CRITICAL)

When writing an all-blocked skip-lock, the file **must** include `skip_lock_until` — that is the field the trigger script checks (`autopilot-trigger.mjs` line 29: `lock.skip_lock_until && new Date(lock.skip_lock_until) > new Date()`). A file without this field is silently ignored and the trigger keeps firing.

Correct format — set `skip_lock_until` to the next quota reset time:
```json
{"skip_lock_until":"<next_reset_at ISO timestamp>","reason":"<why>","written_at":"<now ISO timestamp>"}
```

Bug history: 2026-07-24 — agent wrote `written_at` only (no `skip_lock_until`), causing the trigger to fire again 37 minutes after an all-blocked cycle.

+## Autopilot skip-lock format (CRITICAL)

+When writing an all-blocked skip-lock, the file **must** include `skip_lock_until` — that is the field the trigger script checks (`autopilot-trigger.mjs` line 29: `lock.skip_lock_until && new Date(lock.skip_lock_until) > new Date()`). A file without this field is silently ignored and the trigger keeps firing.

+Correct format — set `skip_lock_until` to the next quota reset time:

+{"skip_lock_until":"<next_reset_at ISO timestamp>","reason":"<why>","written_at":"<now ISO timestamp>"}

+Bug history: 2026-07-24 — agent wrote `written_at` only (no `skip_lock_until`), causing the trigger to fire again 37 minutes after an all-blocked cycle.

- **GitHub (Anthropic):** Scheduled daily at 3am CT — task `task-1779715363838-v6s2ql`. Monitors anthropics org repos and anthropics/skills commits. (Changed from every 2h per James's request 2026-06-04.)


Good. Now let me update the portfolio cards and log the run.

For the project card - this is really autopilot infrastructure work, not strictly a nanoclaw card item. But the closest project card is `portfolio-autopilot`. Let me update that card's notes.

Also, I should update the BOARD.md last activity for portfolio-autopilot.

Let me also log the run and then schedule the reset-wake and send the Slack message.

Wait, actually - the skip-lock fix IS in the nanoclaw workspace, and the board has nanoclaw as one of the eligible projects.

Actually, this fix belongs to portfolio-autopilot since it's really infrastructure work. Let me pull up that card and review it.


1	# Portfolio Autopilot
2
3	- Repo: n/a — lives in Nano's scheduled tasks + config
4	- Goal: Quota-aware autonomous work loop that advances portfolio projects using excess LLM capacity, while preserving a hard reserve for James's interactive use. Self-adjusting over time.
5	- Stage: build
6	- Guard: autonomous-ok
7	- Metric: portfolio stages advanced per week at ≤ 15% of James's interactive quota consumed
8	- Blocked on James: none
9	- Next action: Monitor headroom log as post-run data accumulates; weekly calibration (Mondays 08:00 CT) will surface reserve adjustment suggestions once 5+ snapshots exist
10
11	## Design
12
13	### Three levers (all configurable)
14
15	| Lever | Default | Purpose |
16	|---|---|---|
17	| Base reserve (5h window) | 25% | Interactive buffer — scales down as reset approaches |
18	| Base reserve (7d window) | 15% | Interactive buffer — scales down as reset approaches |
19
20	**No per-session cap.** If there's burnable quota and work to do, use it.
21
22	### Adaptive reserve formula
23
24	```
25	adaptive_reserve_pct = base_reserve_pct × (resets_in_sec / window_duration_sec)
26	burnable_pct         = remaining_pct − adaptive_reserve_pct
27	```
28
29	This means:
30	- Start of window: full reserve held
31	- Mid-window: reserve shrinks proportionally
32	- Near reset: reserve → 0 (almost all remaining quota is burnable)
33
34	Applied to both windows independently; take the more conservative (lower burnable) as the constraint:
35	```
36	burnable = min(burnable_5h, burnable_7d)
37	```
38
39	Work runs only when `burnable > 0`.
40
41	### Task types + model assignment
42
43	Task type determines model and effort *regardless of quota tier* — planning always uses the best available model because the cost of a bad plan exceeds the cost of the tokens.
44
45	| Task type | Model | Effort | Notes |
46	|---|---|---|---|
47	| Plan (greenfield) | Claude Sonnet | high | Always capable model — non-negotiable |
48	| Red-team review | Claude Sonnet | medium | Auto-runs after every plan, before human sees it |
49	| Plan (continuation) | Claude Sonnet | medium | Existing direction, lower risk |
50	| Implementation | Claude Sonnet or Haiku | medium | Quota-tier dependent |
51	| Research / analysis | Gemini or Haiku | low | Bulk work, quota-saving |
52	| Maintenance | LM Studio or Haiku | low | Formatting, summaries, simple edits |
53
54	### Human-in-the-loop checkpoints
55
56	**Greenfield work** (new plan, new feature, new project direction):
57	```
58	Plan → Auto red-team → Package (plan + critique + open questions) → Send to James → James approves → Implementation
59	```
60	Implementation does not start until James explicitly approves. The package sent to James includes: the plan, the red-team's blind spots and risk flags, and a numbered list of open questions.
61
62	**Continuing work** (clear next action on an existing spec):
63	```
64	Implement → Report outcome → James can redirect if needed
65	```
66	No checkpoint required for `autonomous-ok` projects with a well-defined next action.
67
68	**review-required projects** (TradingBot25, qip-qien):
69	All changes go as PRs; James approves merges. No auto-merge ever.
70
71	### Quota tiers → implementation model routing
72
73	Planning always uses capable model (see above). Implementation routing adapts to quota:
74
75	| Burnable quota | Implementation model | Projects allowed |
76	|---|---|---|
77	| High (>50% burnable) | Claude Sonnet | P1, P2, P3 |
78	| Medium (20–50%) | Claude Sonnet | P1, P2 |
79	| Low (5–20%) | Gemini or Haiku | P1 only |
80	| Minimal (<5%) | LM Studio | maintenance only |
81	| Zero | No autonomous work | — |
82
83	### Burn-rate gate (for P2/P3)
84
85	`sustainable_pct_per_hour = 100 / window_hours`
86
87	P2/P3 work only runs when actual burn rate < sustainable pace — i.e., quota is ahead of the smooth curve. P1 work bypasses this gate (runs whenever above the reserve floor).
88
89	### Priority tiers (proposed — James to confirm)
90
91	| Project | Priority | Rationale |
92	|---|---|---|
93	| StageHand | P1 | James's priority — real estate video suite, active discovery |
94	| nanoclaw | P1 | Maintenance + ongoing infra work |
95	| AgenticLever | P2 | Business-facing, active build |
96	| RoadSense | P2 | Going public, active momentum |
97	| qip-qien | P2 | Live trial — needs progress but review-required gate limits autonomous scope |
98	| congressional-trading | P3 | Runs autonomously; calibration is in-flight, low need for new LLM spend |
99	| TradingBot25 | P3 | Deep investment already; review-required, low autonomous-work surface |
100
101	### Closed-loop auto-calibration
102
103	Track per run:
104	- Quota spent (from CodexBar delta before/after)
105	- Output produced (git commits, wiki pages, board moves)
106	- Did James use Claude within 2h after an autonomous run? (proxy for "left enough headroom")
107
108	Weekly review: if James-usage-after-run rate is high → reserve floor was too low → bump it up. If output/quota ratio is consistently low → narrow per-session cap. If P1 projects are stalling → loosen moderate-tier threshold.
109
110	The loop surfaces a weekly "autopilot health" note (not a full brief — one line per signal that changed).
111
112	### Config file
113
114	`/workspace/agent/autopilot-config.json` — all thresholds live here so any run can tweak them without code changes.
115
116	```json
117	{
118	  "reserve_5h_pct": 25,
119	  "reserve_7d_pct": 15,
120
121	  "project_priorities": {
122	    "StageHand": "P1",
123	    "nanoclaw": "P1",
124	    "AgenticLever": "P2",
125	    "RoadSense": "P2",
126	    "qip-qien": "P2",
127	    "congressional-trading": "P3",
128	    "TradingBot25": "P3"
129	  },
130	  "flush_threshold": 60,
131	  "comfortable_threshold": 40,
132	  "moderate_threshold": 20
133	}
134	```
135
136	## Implementation plan
137
138	1. **Config + quota reader** — `autopilot-config.json` + script that reads CodexBar endpoint and computes current tier and burn rate
139	2. **Routing logic** — given tier + priority + project next-action, decide: proceed / skip / use alternate model
140	3. **Task executor** — runs one unit of work per session, commits result, updates board
141	4. **Scheduled trigger** — every 30 min, runs quota check; fires task if conditions met
142	5. **Outcome tracker** — logs quota delta + output produced per run
143	6. **Weekly calibration** — reviews outcome log, suggests threshold changes
144
145	## Notes
146
147	- 2026-07-07 — James approved design. Start with intelligent defaults, evolve to closed-loop. Config file approach so thresholds are tweakable without code changes.
148	- 2026-07-07 — James set priorities (inverted from initial proposal): P1 = StageHand, nanoclaw; P2 = AgenticLever, RoadSense, qip-qien; P3 = congressional-trading, TradingBot25.
149	- 2026-07-07 — Reserve revised to adaptive formula (scales linearly to 0 as window resets). Per-session cap removed — no artificial throttle on session size.
150	- 2026-07-07 — Core build complete: `autopilot-config.json` (thresholds + priority map), `autopilot.mjs` (quota reader + routing logic, human-readable + JSON mode), `autopilot-trigger.mjs` (pre-script for scheduler — returns wakeAgent true/false). Scheduled task `task-1783433888329-w9msxw` runs every 30 min.
151	- 2026-07-08 — Outcome tracker built: `autopilot-summary.mjs` (stats by outcome/project/tier/model, recent history, --json + --last N flags). Weekly calibration built: `autopilot-calibrate.mjs` (7-day stats, sends Telegram summary). Scheduled weekly Mondays 08:00 CT.
152	- 2026-07-08 — Skip-lock added to `autopilot-trigger.mjs`: agent writes `autopilot-skip-lock.json` after all-blocked cycles to suppress repeated 30-min trigger wakes. Prevents wasted cycles when all projects are blocked on James.
153	- CodexBar endpoint: `http://host.docker.internal:7842/usage` — confirmed live and accessible from container.
154	- LM Studio confirmed live at `http://host.docker.internal:1234` with Gemma 4 12B + 26B models loaded.
155	- 2026-07-12 — Closed-loop calibration wired up. Three new components: `autopilot-headroom.mjs` (post-run quota snapshot logger), pre-run snapshot added to `autopilot-trigger.mjs`, and headroom analysis section added to `autopilot-calibrate.mjs`. Snapshots track remaining_5h/7d_pct vs reserve floor; calibration script suggests raising/lowering reserve based on 7-day sample. First post-run snapshot captured: 5h=73% remaining (adequate), 7d=92% (adequate), burnable=71%.
156

# Portfolio Autopilot

- Repo: n/a — lives in Nano's scheduled tasks + config
- Goal: Quota-aware autonomous work loop that advances portfolio projects using excess LLM capacity, while preserving a hard reserve for James's interactive use. Self-adjusting over time.
- Stage: build
- Guard: autonomous-ok
- Metric: portfolio stages advanced per week at ≤ 15% of James's interactive quota consumed
- Blocked on James: none
- Next action: Monitor headroom log as post-run data accumulates; weekly calibration (Mondays 08:00 CT) will surface reserve adjustment suggestions once 5+ snapshots exist

## Design

### Three levers (all configurable)

| Lever | Default | Purpose |
|---|---|---|
| Base reserve (5h window) | 25% | Interactive buffer — scales down as reset approaches |
| Base reserve (7d window) | 15% | Interactive buffer — scales down as reset approaches |

**No per-session cap.** If there's burnable quota and work to do, use it.

### Adaptive reserve formula

```
adaptive_reserve_pct = base_reserve_pct × (resets_in_sec / window_duration_sec)
burnable_pct         = remaining_pct − adaptive_reserve_pct
```

This means:
- Start of window: full reserve held
- Mid-window: reserve shrinks proportionally
- Near reset: reserve → 0 (almost all remaining quota is burnable)

Applied to both windows independently; take the more conservative (lower burnable) as the constraint:
```
burnable = min(burnable_5h, burnable_7d)
```

Work runs only when `burnable > 0`.

### Task types + model assignment

Task type determines model and effort *regardless of quota tier* — planning always uses the best available model because the cost of a bad plan exceeds the cost of the tokens.

| Task type | Model | Effort | Notes |
|---|---|---|---|
| Plan (greenfield) | Claude Sonnet | high | Always capable model — non-negotiable |
| Red-team review | Claude Sonnet | medium | Auto-runs after every plan, before human sees it |
| Plan (continuation) | Claude Sonnet | medium | Existing direction, lower risk |
| Implementation | Claude Sonnet or Haiku | medium | Quota-tier dependent |
| Research / analysis | Gemini or Haiku | low | Bulk work, quota-saving |
| Maintenance | LM Studio or Haiku | low | Formatting, summaries, simple edits |

### Human-in-the-loop checkpoints

**Greenfield work** (new plan, new feature, new project direction):
```
Plan → Auto red-team → Package (plan + critique + open questions) → Send to James → James approves → Implementation
```
Implementation does not start until James explicitly approves. The package sent to James includes: the plan, the red-team's blind spots and risk flags, and a numbered list of open questions.

**Continuing work** (clear next action on an existing spec):
```
Implement → Report outcome → James can redirect if needed
```
No checkpoint required for `autonomous-ok` projects with a well-defined next action.

**review-required projects** (TradingBot25, qip-qien):
All changes go as PRs; James approves merges. No auto-merge ever.

### Quota tiers → implementation model routing

Planning always uses capable model (see above). Implementation routing adapts to quota:

| Burnable quota | Implementation model | Projects allowed |
|---|---|---|
| High (>50% burnable) | Claude Sonnet | P1, P2, P3 |
| Medium (20–50%) | Claude Sonnet | P1, P2 |
| Low (5–20%) | Gemini or Haiku | P1 only |
| Minimal (<5%) | LM Studio | maintenance only |
| Zero | No autonomous work | — |

### Burn-rate gate (for P2/P3)

`sustainable_pct_per_hour = 100 / window_hours`

P2/P3 work only runs when actual burn rate < sustainable pace — i.e., quota is ahead of the smooth curve. P1 work bypasses this gate (runs whenever above the reserve floor).

### Priority tiers (proposed — James to confirm)

| Project | Priority | Rationale |
|---|---|---|
| StageHand | P1 | James's priority — real estate video suite, active discovery |
| nanoclaw | P1 | Maintenance + ongoing infra work |
| AgenticLever | P2 | Business-facing, active build |
| RoadSense | P2 | Going public, active momentum |
| qip-qien | P2 | Live trial — needs progress but review-required gate limits autonomous scope |
| congressional-trading | P3 | Runs autonomously; calibration is in-flight, low need for new LLM spend |
| TradingBot25 | P3 | Deep investment already; review-required, low autonomous-work surface |

### Closed-loop auto-calibration

Track per run:
- Quota spent (from CodexBar delta before/after)
- Output produced (git commits, wiki pages, board moves)
- Did James use Claude within 2h after an autonomous run? (proxy for "left enough headroom")

Weekly review: if James-usage-after-run rate is high → reserve floor was too low → bump it up. If output/quota ratio is consistently low → narrow per-session cap. If P1 projects are stalling → loosen moderate-tier threshold.

The loop surfaces a weekly "autopilot health" note (not a full brief — one line per signal that changed).

### Config file

`/workspace/agent/autopilot-config.json` — all thresholds live here so any run can tweak them without code changes.

```json
{
  "reserve_5h_pct": 25,
  "reserve_7d_pct": 15,

  "project_priorities": {
    "StageHand": "P1",
    "nanoclaw": "P1",
    "AgenticLever": "P2",
    "RoadSense": "P2",
    "qip-qien": "P2",
    "congressional-trading": "P3",
    "TradingBot25": "P3"
  },
  "flush_threshold": 60,
  "comfortable_threshold": 40,
  "moderate_threshold": 20
}
```

## Implementation plan

1. **Config + quota reader** — `autopilot-config.json` + script that reads CodexBar endpoint and computes current tier and burn rate
2. **Routing logic** — given tier + priority + project next-action, decide: proceed / skip / use alternate model
3. **Task executor** — runs one unit of work per session, commits result, updates board
4. **Scheduled trigger** — every 30 min, runs quota check; fires task if conditions met
5. **Outcome tracker** — logs quota delta + output produced per run
6. **Weekly calibration** — reviews outcome log, suggests threshold changes

## Notes

- 2026-07-07 — James approved design. Start with intelligent defaults, evolve to closed-loop. Config file approach so thresholds are tweakable without code changes.
- 2026-07-07 — James set priorities (inverted from initial proposal): P1 = StageHand, nanoclaw; P2 = AgenticLever, RoadSense, qip-qien; P3 = congressional-trading, TradingBot25.
- 2026-07-07 — Reserve revised to adaptive formula (scales linearly to 0 as window resets). Per-session cap removed — no artificial throttle on session size.
- 2026-07-07 — Core build complete: `autopilot-config.json` (thresholds + priority map), `autopilot.mjs` (quota reader + routing logic, human-readable + JSON mode), `autopilot-trigger.mjs` (pre-script for scheduler — returns wakeAgent true/false). Scheduled task `task-1783433888329-w9msxw` runs every 30 min.
- 2026-07-08 — Outcome tracker built: `autopilot-summary.mjs` (stats by outcome/project/tier/model, recent history, --json + --last N flags). Weekly calibration built: `autopilot-calibrate.mjs` (7-day stats, sends Telegram summary). Scheduled weekly Mondays 08:00 CT.
- 2026-07-08 — Skip-lock added to `autopilot-trigger.mjs`: agent writes `autopilot-skip-lock.json` after all-blocked cycles to suppress repeated 30-min trigger wakes. Prevents wasted cycles when all projects are blocked on James.
- CodexBar endpoint: `http://host.docker.internal:7842/usage` — confirmed live and accessible from container.
- LM Studio confirmed live at `http://host.docker.internal:1234` with Gemma 4 12B + 26B models loaded.
- 2026-07-12 — Closed-loop calibration wired up. Three new components: `autopilot-headroom.mjs` (post-run quota snapshot logger), pre-run snapshot added to `autopilot-trigger.mjs`, and headroom analysis section added to `autopilot-calibrate.mjs`. Snapshots track remaining_5h/7d_pct vs reserve floor; calibration script suggests raising/lowering reserve based on 7-day sample. First post-run snapshot captured: 5h=73% remaining (adequate), 7d=92% (adequate), burnable=71%.


Review eligible projects and execute autopilot cycle


Good. Now I need to:
1. Update the portfolio-autopilot card notes with this fix
2. Update BOARD.md last activity for portfolio-autopilot
3. Log the run
4. Send Slack note
5. Schedule reset-wake
6. Remove running lock

The portfolio-autopilot card isn't in the eligible projects list though. The closest is nanoclaw (P1). Actually, the skip-lock fix is autopilot infrastructure, so it makes more sense to attribute it to portfolio-autopilot.

Wait, looking at the board:
- portfolio-autopilot is listed as a project BUT it's NOT in the eligible projects list from the trigger (which only has StageHand, nanoclaw, AgenticLever, RoadSense, qip-qien).
But the work I did is clearly related to portfolio-autopilot infrastructure, so I'll attribute it there anyway. Now I'll update the portfolio-autopilot notes, BOARD.md with the latest activity, log this run, send a Slack message to slack-infrastructure, schedule the reset-wake, and clean up the running lock.


Now update the portfolio-autopilot card and BOARD.md, then log + close out.


- 2026-07-12 — Closed-loop calibration wired up. Three new components: `autopilot-headroom.mjs` (post-run quota snapshot logger), pre-run snapshot added to `autopilot-trigger.mjs`, and headroom analysis section added to `autopilot-calibrate.mjs`. Snapshots track remaining_5h/7d_pct vs reserve floor; calibration script suggests raising/lowering reserve based on 7-day sample. First post-run snapshot captured: 5h=73% remaining (adequate), 7d=92% (adequate), burnable=71%.

- 2026-07-12 — Closed-loop calibration wired up. Three new components: `autopilot-headroom.mjs` (post-run quota snapshot logger), pre-run snapshot added to `autopilot-trigger.mjs`, and headroom analysis section added to `autopilot-calibrate.mjs`. Snapshots track remaining_5h/7d_pct vs reserve floor; calibration script suggests raising/lowering reserve based on 7-day sample. First post-run snapshot captured: 5h=73% remaining (adequate), 7d=92% (adequate), burnable=71%.
- 2026-07-24 — Fixed skip-lock format bug. Root cause: agent was writing `{"written_at":...}` but `autopilot-trigger.mjs` checks `lock.skip_lock_until` (line 29) — a file without that field is silently ignored, causing repeated 30-min triggers after all-blocked cycles. Fix: skip-lock now written with `skip_lock_until` set to `next_reset_at`. CLAUDE.local.md updated with correct format + bug history. No trigger script changes needed.


The file /workspace/extra/second-brain/portfolio/projects/portfolio-autopilot.md has been updated successfully. (file state is current in your context — no need to Read it back)

- 2026-07-12 — Closed-loop calibration wired up. Three new components: `autopilot-headroom.mjs` (post-run quota snapshot logger), pre-run snapshot added to `autopilot-trigger.mjs`, and headroom analysis section added to `autopilot-calibrate.mjs`. Snapshots track remaining_5h/7d_pct vs reserve floor; calibration script suggests raising/lowering reserve based on 7-day sample. First post-run snapshot captured: 5h=73% remaining (adequate), 7d=92% (adequate), burnable=71%.
- 2026-07-24 — Fixed skip-lock format bug. Root cause: agent was writing `{"written_at":...}` but `autopilot-trigger.mjs` checks `lock.skip_lock_until` (line 29) — a file without that field is silently ignored, causing repeated 30-min triggers after all-blocked cycles. Fix: skip-lock now written with `skip_lock_until` set to `next_reset_at`. CLAUDE.local.md updated with correct format + bug history. No trigger script changes needed.

# Portfolio Autopilot

- Repo: n/a — lives in Nano's scheduled tasks + config
- Goal: Quota-aware autonomous work loop that advances portfolio projects using excess LLM capacity, while preserving a hard reserve for James's interactive use. Self-adjusting over time.
- Stage: build
- Guard: autonomous-ok
- Metric: portfolio stages advanced per week at ≤ 15% of James's interactive quota consumed
- Blocked on James: none
- Next action: Monitor headroom log as post-run data accumulates; weekly calibration (Mondays 08:00 CT) will surface reserve adjustment suggestions once 5+ snapshots exist

## Design

### Three levers (all configurable)

| Lever | Default | Purpose |
|---|---|---|
| Base reserve (5h window) | 25% | Interactive buffer — scales down as reset approaches |
| Base reserve (7d window) | 15% | Interactive buffer — scales down as reset approaches |

**No per-session cap.** If there's burnable quota and work to do, use it.

### Adaptive reserve formula

```
adaptive_reserve_pct = base_reserve_pct × (resets_in_sec / window_duration_sec)
burnable_pct         = remaining_pct − adaptive_reserve_pct
```

This means:
- Start of window: full reserve held
- Mid-window: reserve shrinks proportionally
- Near reset: reserve → 0 (almost all remaining quota is burnable)

Applied to both windows independently; take the more conservative (lower burnable) as the constraint:
```
burnable = min(burnable_5h, burnable_7d)
```

Work runs only when `burnable > 0`.

### Task types + model assignment

Task type determines model and effort *regardless of quota tier* — planning always uses the best available model because the cost of a bad plan exceeds the cost of the tokens.

| Task type | Model | Effort | Notes |
|---|---|---|---|
| Plan (greenfield) | Claude Sonnet | high | Always capable model — non-negotiable |
| Red-team review | Claude Sonnet | medium | Auto-runs after every plan, before human sees it |
| Plan (continuation) | Claude Sonnet | medium | Existing direction, lower risk |
| Implementation | Claude Sonnet or Haiku | medium | Quota-tier dependent |
| Research / analysis | Gemini or Haiku | low | Bulk work, quota-saving |
| Maintenance | LM Studio or Haiku | low | Formatting, summaries, simple edits |

### Human-in-the-loop checkpoints

**Greenfield work** (new plan, new feature, new project direction):
```
Plan → Auto red-team → Package (plan + critique + open questions) → Send to James → James approves → Implementation
```
Implementation does not start until James explicitly approves. The package sent to James includes: the plan, the red-team's blind spots and risk flags, and a numbered list of open questions.

**Continuing work** (clear next action on an existing spec):
```
Implement → Report outcome → James can redirect if needed
```
No checkpoint required for `autonomous-ok` projects with a well-defined next action.

**review-required projects** (TradingBot25, qip-qien):
All changes go as PRs; James approves merges. No auto-merge ever.

### Quota tiers → implementation model routing

Planning always uses capable model (see above). Implementation routing adapts to quota:

| Burnable quota | Implementation model | Projects allowed |
|---|---|---|
| High (>50% burnable) | Claude Sonnet | P1, P2, P3 |
| Medium (20–50%) | Claude Sonnet | P1, P2 |
| Low (5–20%) | Gemini or Haiku | P1 only |
| Minimal (<5%) | LM Studio | maintenance only |
| Zero | No autonomous work | — |

### Burn-rate gate (for P2/P3)

`sustainable_pct_per_hour = 100 / window_hours`

P2/P3 work only runs when actual burn rate < sustainable pace — i.e., quota is ahead of the smooth curve. P1 work bypasses this gate (runs whenever above the reserve floor).

### Priority tiers (proposed — James to confirm)

| Project | Priority | Rationale |
|---|---|---|
| StageHand | P1 | James's priority — real estate video suite, active discovery |
| nanoclaw | P1 | Maintenance + ongoing infra work |
| AgenticLever | P2 | Business-facing, active build |
| RoadSense | P2 | Going public, active momentum |
| qip-qien | P2 | Live trial — needs progress but review-required gate limits autonomous scope |
| congressional-trading | P3 | Runs autonomously; calibration is in-flight, low need for new LLM spend |
| TradingBot25 | P3 | Deep investment already; review-required, low autonomous-work surface |

### Closed-loop auto-calibration

Track per run:
- Quota spent (from CodexBar delta before/after)
- Output produced (git commits, wiki pages, board moves)
- Did James use Claude within 2h after an autonomous run? (proxy for "left enough headroom")

Weekly review: if James-usage-after-run rate is high → reserve floor was too low → bump it up. If output/quota ratio is consistently low → narrow per-session cap. If P1 projects are stalling → loosen moderate-tier threshold.

The loop surfaces a weekly "autopilot health" note (not a full brief — one line per signal that changed).

### Config file

`/workspace/agent/autopilot-config.json` — all thresholds live here so any run can tweak them without code changes.

```json
{
  "reserve_5h_pct": 25,
  "reserve_7d_pct": 15,

  "project_priorities": {
    "StageHand": "P1",
    "nanoclaw": "P1",
    "AgenticLever": "P2",
    "RoadSense": "P2",
    "qip-qien": "P2",
    "congressional-trading": "P3",
    "TradingBot25": "P3"
  },
  "flush_threshold": 60,
  "comfortable_threshold": 40,
  "moderate_threshold": 20
}
```

## Implementation plan

1. **Config + quota reader** — `autopilot-config.json` + script that reads CodexBar endpoint and computes current tier and burn rate
2. **Routing logic** — given tier + priority + project next-action, decide: proceed / skip / use alternate model
3. **Task executor** — runs one unit of work per session, commits result, updates board
4. **Scheduled trigger** — every 30 min, runs quota check; fires task if conditions met
5. **Outcome tracker** — logs quota delta + output produced per run
6. **Weekly calibration** — reviews outcome log, suggests threshold changes

## Notes

- 2026-07-07 — James approved design. Start with intelligent defaults, evolve to closed-loop. Config file approach so thresholds are tweakable without code changes.
- 2026-07-07 — James set priorities (inverted from initial proposal): P1 = StageHand, nanoclaw; P2 = AgenticLever, RoadSense, qip-qien; P3 = congressional-trading, TradingBot25.
- 2026-07-07 — Reserve revised to adaptive formula (scales linearly to 0 as window resets). Per-session cap removed — no artificial throttle on session size.
- 2026-07-07 — Core build complete: `autopilot-config.json` (thresholds + priority map), `autopilot.mjs` (quota reader + routing logic, human-readable + JSON mode), `autopilot-trigger.mjs` (pre-script for scheduler — returns wakeAgent true/false). Scheduled task `task-1783433888329-w9msxw` runs every 30 min.
- 2026-07-08 — Outcome tracker built: `autopilot-summary.mjs` (stats by outcome/project/tier/model, recent history, --json + --last N flags). Weekly calibration built: `autopilot-calibrate.mjs` (7-day stats, sends Telegram summary). Scheduled weekly Mondays 08:00 CT.
- 2026-07-08 — Skip-lock added to `autopilot-trigger.mjs`: agent writes `autopilot-skip-lock.json` after all-blocked cycles to suppress repeated 30-min trigger wakes. Prevents wasted cycles when all projects are blocked on James.
- CodexBar endpoint: `http://host.docker.internal:7842/usage` — confirmed live and accessible from container.
- LM Studio confirmed live at `http://host.docker.internal:1234` with Gemma 4 12B + 26B models loaded.
- 2026-07-12 — Closed-loop calibration wired up. Three new components: `autopilot-headroom.mjs` (post-run quota snapshot logger), pre-run snapshot added to `autopilot-trigger.mjs`, and headroom analysis section added to `autopilot-calibrate.mjs`. Snapshots track remaining_5h/7d_pct vs reserve floor; calibration script suggests raising/lowering reserve based on 7-day sample. First post-run snapshot captured: 5h=73% remaining (adequate), 7d=92% (adequate), burnable=71%.

+- 2026-07-24 — Fixed skip-lock format bug. Root cause: agent was writing `{"written_at":...}` but `autopilot-trigger.mjs` checks `lock.skip_lock_until` (line 29) — a file without that field is silently ignored, causing repeated 30-min triggers after all-blocked cycles. Fix: skip-lock now written with `skip_lock_until` set to `next_reset_at`. CLAUDE.local.md updated with correct format + bug history. No trigger script changes needed.


| [portfolio-autopilot](projects/portfolio-autopilot.md) | build | autonomous-ok | Monitor headroom log; calibration surfaces reserve suggestions after 5+ snapshots | none | 2026-07-12 |

| [portfolio-autopilot](projects/portfolio-autopilot.md) | build | autonomous-ok | Monitor headroom log; calibration surfaces reserve suggestions after 5+ snapshots | none | 2026-07-24 |


The file /workspace/extra/second-brain/portfolio/BOARD.md has been updated successfully. (file state is current in your context — no need to Read it back)

# Portfolio Board

One row per active project. Cards with full detail live in `projects/`.
Operating model + decisions: [PLAN.md](PLAN.md).
Stages: `research → discovery → spec → build → test → feedback → maintain`.
Guard: `review-required` (James approves merges) or `autonomous-ok` (agents proceed, report after).

**Seeded 2026-07-06 from git activity — stages and next actions are drafts until James confirms.**

| Project | Stage | Guard | Next action | Blocked on James | Last activity |
|---|---|---|---|---|---|
| [portfolio-autopilot](projects/portfolio-autopilot.md) | build | autonomous-ok | Monitor headroom log; calibration surfaces reserve suggestions after 5+ snapshots | none | 2026-07-12 |
| [qip-qien](projects/qip-qien.md) | feedback | review-required | SEV-1 fix committed (ee84254); merge sign-off needed | merge approval | 2026-07-19 |
| [congressional-trading](projects/congressional-trading.md) | test | autonomous-ok | Await threshold decision; weekly precision monitor running (Mondays 9am) | threshold decision | 2026-07-21 |
| [FindRefurbishedAppleProduct](projects/FindRefurbishedAppleProduct.md) | discovery | autonomous-ok | Confirm goal — brand new repo | confirm card | 2026-07-06 |
| [TradingBot25](projects/TradingBot25.md) | build | review-required | Confirm goal + current strategy state | confirm card | 2026-06-26 |
| [AgenticLever](projects/AgenticLever.md) | build | autonomous-ok | Confirm goal + next feature direction | confirm goal | 2026-07-20 |
| [pool-monitor](projects/pool-monitor.md) | maintain | autonomous-ok | None — steady state? confirm | confirm card | 2026-06-17 |
| [StageHand](projects/StageHand.md) | discovery | autonomous-ok | Await James answers on 5 toolchain questions; headless-browser gallery capture if Local Recs green-lit | voice, agent, posting, pricing, Local Recs y/n | 2026-07-21 |
| [MentorCore](projects/MentorCore.md) | research | autonomous-ok | Parked — no bandwidth | none | 2026-06-11 |
| [RoadSense](projects/RoadSense.md) | spec | autonomous-ok | Answer 5 launch questions → unblock implementation | auth model, city, GIS license, creator posture, metric | 2026-07-21 |
| [nanoclaw](projects/nanoclaw.md) | build | autonomous-ok | Review push() fix (d4ef752) → deploy to Studio | deploy, metric | 2026-07-20 |
| [projects-monorepo-infra](projects/projects-monorepo-infra.md) | build | review-required | Name the token-spend-avoided metric | metric decision | 2026-07-16 |
| cortex *(no card yet)* | maintain | review-required | Decide: fill Reddit OAuth creds, or drop Reddit ingest (project's own docs call the API "increasingly restrictive") | Reddit creds / keep-or-drop call | 2026-07-12 |
| CodexBar *(no card yet)* | maintain | review-required | Decide upstream-sync strategy (1056 commits behind steipete/CodexBar); scrub steipete paths/bundle-ID from docs | sync strategy | 2026-07-12 |
| CodexBarLocal *(no card yet)* | maintain | review-required | 34 uncommitted changes incl. a stray Xcode scaffold — commit, stash, or discard | commit/stash/discard call | 2026-07-12 |
| CodexBar-ESP32 *(no card yet)* | maintain | autonomous-ok | None right now — mDNS doc gap fixed today; 3 minor observations items open (untested pace-formula dup, lock-ordering) | none | 2026-07-12 |
| localsky_radar *(no card yet)* | build | review-required | `git init` + first commit (2,227 lines, zero version control); rewrite CLAUDE.md (wrongly claims unimplemented) | confirm git-init | 2026-07-12 |

## Decision queue

Questions for James, appended by Nano; answered items move to the card's Notes and are removed here.

- **nanoclaw metric:** Proposed metric = "decisions James answers per week from daily brief" (proxy for brief usefulness). Confirm or rename? (Card currently undefined.)
- **RoadSense launch questions (5):** auth model, generalization city, GIS license, creator posture, 30-day success metric. Sent via Telegram 2026-07-08.
- **congressional-trading dual-poller (2026-07-12):** `com.congresswatch.daily` launchd job confirmed loaded on *both* the Mac Mini and this Studio simultaneously — doubles LLM spend and races notification cooldowns. Project's own `agentic_plan.md` already flags this as unresolved. Which machine is authoritative?
- **qip-ask-qien SEV-1 merge (2026-07-19):** fix committed (ee84254) — admin route guards changed from `requireExpertApiUser` → `requireAdminApiUser` on 4 routes. TypeScript + lint clean. Ready to merge; needs James's sign-off to push.
- **nanoclaw push() fix deploy (2026-07-20):** Fix implemented (d4ef752), 135 tests pass. Awaiting Studio deploy. Design decisions made autonomously: (1) follow-up-turn UX = yes; (2) Claude safety net = yes; (3) tests = yes.

## Recently shipped

- **Portfolio audit** 2026-07-12 — parallel survey across 20 projects; auto-fixed 10 AGENTS.md/CLAUDE.md symmetry gaps, an mDNS doc gap (CodexBar-ESP32), a stale phase claim (MentorCore), a wrong-hostname ntfy-link bug (pool-monitor, verified via 76 passing tests), a test-isolation gap (AgenticLever, verified via 32 passing tests), and this file's own Tailscale hostname drift.
- **nanoclaw** 2026-07-08 — fix(router): mention-sticky Slack session scoping committed

-| [portfolio-autopilot](projects/portfolio-autopilot.md) | build | autonomous-ok | Monitor headroom log; calibration surfaces reserve suggestions after 5+ snapshots | none | 2026-07-12 |

+| [portfolio-autopilot](projects/portfolio-autopilot.md) | build | autonomous-ok | Monitor headroom log; calibration surfaces reserve suggestions after 5+ snapshots | none | 2026-07-24 |


Bash

echo '{"timestamp":"2026-07-24T20:09:00.000Z","tier":"medium","burnable_pct":48.4,"project":"portfolio-autopilot","task_type":"continuation","model_used":"claude-sonnet","outcome":"success","notes":"Fixed skip-lock format bug: agent was writing written_at but trigger checks skip_lock_until — field mismatch caused all-blocked cycles to not suppress 30-min polling. Fixed autopilot-skip-lock.json with correct field. Updated CLAUDE.local.md with format docs + bug history. No trigger script changes needed."}' >> /workspace/agent/autopilot-run-log.jsonl && echo "logged"

Append successful fix to autopilot run log


logged


Prompt: Portfolio Autopilot reset-wake: check quota and run one autopilot cycle. Read /workspace/agent/autopilot-config.json for context. Run node /workspace/agent/autopilot.mjs to see current state, then proceed as the autopilot prompt instructs.


Task scheduled (id: task-1784907134126-ejhtad, runs at: 2026-07-25T21:00:00.482Z)


Now let me remove the running lock and send the Slack message.


rm /workspace/agent/autopilot-running-lock.json && echo "lock removed"

Remove autopilot running lock


lock removed


Autopilot (medium tier, 48% burnable) — **skip-lock bug fixed.**

Found root cause of the repeated triggers: agent was writing `{"written_at":...}` to the skip-lock file, but `autopilot-trigger.mjs` checks `lock.skip_lock_until` — field mismatch, so the lock was silently ignored every cycle.

Fixed: skip-lock now uses `skip_lock_until` set to the next quota reset time. CLAUDE.local.md updated with the correct format + bug history. No trigger script changes needed. Skip-lock is now active until ~4pm CT tomorrow. Next wake at quota reset (task-1784907134126-ejhtad).


Message sent to slack-infrastructure (id: 3423)


<message to="slack-infrastructure">Autopilot (medium tier, 48% burnable) — **skip-lock bug fixed.**

Found root cause of the repeated triggers: agent was writing `{"written_at":...}` to the skip-lock file, but `autopilot-trigger.mjs` checks `lock.skip_lock_until` — field mismatch, so the lock was silently ignored every cycle.

Fixed: skip-lock now uses `skip_lock_until` set to the next quota reset time. CLAUDE.local.md updated with the correct format + bug history. No trigger script changes needed. Skip-lock is now active until ~4pm CT tomorrow. Next wake at quota reset (task-1784907134126-ejhtad).</message>

**Done.** The second trigger fired because the skip-lock I wrote last cycle had `written_at` but `autopilot-trigger.mjs` checks `skip_lock_until` (line 29) — a silent field mismatch that caused every all-blocked cycle to be ignored by the lock. Fixed the file format, documented the correct schema in `CLAUDE.local.md`, and updated the portfolio-autopilot card. Skip-lock is now properly active until the quota reset tomorrow ~4pm CT.


<context timezone="America/Chicago" />
<task from="telegram-mg-17796" time="Jul 24, 2026, 5:00 PM">Script output:
{
  "newPosts": [
    {
      "slug": "how-the-product-designer-who-built-claude-design-uses-it-to-explore-ideas-before-building-them",
      "url": "https://claude.com/blog/how-the-product-designer-who-built-claude-design-uses-it-to-explore-ideas-before-building-them"
    },
    {
      "slug": "the-new-rules-of-context-engineering-for-claude-5-generation-models",
      "url": "https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models"
    },
    {
      "slug": "claude-models-explained-choosing-the-best-model-for-your-use-case",
      "url": "https://claude.com/blog/claude-models-explained-choosing-the-best-model-for-your-use-case"
    }
  ]
}

Instructions:
New posts were detected on the Claude blog. The script output is in `data.newPosts` — an array of {slug, url} objects.

For each new post:
1. Evaluate relevance — prioritize: Claude Code features, agent SDKs, workflows, plugins, founder/engineering org content, security. Skip: customer case studies for specific industries (finance team, sales leader), compliance/partner announcements unless they introduce new capabilities.
2. For relevant posts: fetch the content using WebFetch and create a wiki source page in /workspace/extra/second-brain/wiki/sources/ following the naming pattern "Claude Blog - [Short Title].md". Also create a concept page in /workspace/extra/second-brain/wiki/concepts/ if the post introduces a significant new concept.
3. Update existing wiki tool pages if a post adds capabilities to an already-documented tool (e.g., Managed Agents updates).
4. Update /workspace/extra/second-brain/wiki/Home.md — add entries to the Sources section for new source pages and to Concepts for new concept pages.
5. Update /workspace/extra/second-brain/wiki/Wiki Ingest Log.md with a dated entry noting what was ingested.
6. Update CLAUDE.local.md if any new monitoring tasks or sources should be noted there.
7. Message James (telegram-mg-17796) with a concise bullet list of what was new and what was ingested. If nothing was relevant, send a brief note saying the blog was checked and nothing worth ingesting was found.</task>


Let me fetch all three blog posts concurrently to evaluate their relevance.


ToolSearch

Question: select:WebFetch


Question: select:WebFetch


Let me fetch all three posts concurrently.


Fetching all three posts in parallel to evaluate relevance.


WebFetch

Prompt: Extract the full article text: title, author, date, key points, tools/workflows mentioned, any Claude features or capabilities highlighted. Return everything needed to write a wiki source page.


Prompt: Extract the full article text: title, author, date, key points, new concepts introduced, specific Claude features or techniques described. Return everything needed to write a wiki source page and potentially a concept page.


Prompt: Extract the full article text: title, author, date, key points, model names and capabilities described, use-case routing guidance, any new model information. Return everything needed to write a wiki source page.


# Article Extraction: Claude Design Blog Post

**Title:** How the product designer who built Claude Design uses it to explore ideas before building them

**Author:** Nate Parrott, Product Designer at Anthropic

**Date:** July 24, 2026

**Category:** Enterprise AI

**Reading Time:** 5 minutes

---

## Key Points

1. **Origin Story**: Parrott developed Claude Design while working on Claude Code for VS Code to accelerate design output and keep pace with engineering velocity.

2. **Core Innovation**: "Claude is really good with HTML" — the tool leverages HTML as an interactive visual medium for creating prototypes, slide decks, and animated content.

3. **Brand Integration**: The tool incorporates Anthropic's design system (fonts, colors, assets) into prompts, ensuring outputs align with brand guidelines.

4. **Evolution**: Claude Design expanded from product mockups to a broader communication tool for "slide decks, landing pages, one-pagers you print as a PDF, emails, animations."

5. **Vision Improvements**: Claude Opus 5's enhanced vision capabilities strengthen the tool's ability to read charts, diagrams, and screenshots for presentation-quality outputs.

---

## Tools & Workflows Mentioned

- **Claude Code**: For production software development
- **Claude Design**: For ideation, collaboration, and visual communication
- **Design System Upload**: Users can upload brand files, logos, and typography specs
- **GitHub Integration**: Connects to existing components and screens
- **Web Search & MCP**: External information sources for design context
- **Voice Input**: Dictation and commenting features for hands-free interaction

---

## Claude Features Highlighted

- HTML/interactive artifact generation
- Vision model improvements (Opus 5)
- Design system analysis and generation
- GitHub and web search integration
- Direct editing tools (resize, recolor, rearrange)
- Token-free manual edits

---

## Best Practices Shared

1. Plan prompts thoroughly before designing
2. Specify visual direction (fonts, colors, moodboards)
3. Build reusable design systems from brand assets
4. Request multiple options then remix preferred elements
5. Use sketches for layouts difficult to describe verbally
6. Wireframe early for faster iteration
7. Reserve manual edits for final refinements
8. Provide real project context (GitHub, screenshots)
9. Queue multiple prompts simultaneously

---

## Notable Quote

"Everything we draw should be alive by default" — referencing Bret Victor's design philosophy on creating interactive, dynamic artifacts.


# Article Extraction: Context Engineering for Claude 5

## Article Metadata
- **Title:** The new rules of context engineering for Claude 5 generation models
- **Author:** Thariq Shihipar, Member of Technical Staff, Anthropic
- **Date:** July 24, 2026
- **Categories:** Claude Code, Agents
- **Reading Time:** 5 minutes

## Key Points

1. **System Prompt Reduction:** Anthropic removed over 80% of Claude Code's system prompt for advanced models without degrading performance on coding evaluations.

2. **Context Engineering Shift:** The approach moved from heavily constrained instructions to relying on model judgment and progressive disclosure of information.

3. **Tool Evolution:** Claude Code now has expanded tools (memory, artifacts, skills) beyond the previous reliance on CLAUDE.md files.

4. **Five Major Practice Changes:**
   - Replaced rigid rules with enabling judgment
   - Shifted from providing examples to designing better tool interfaces
   - Adopted progressive disclosure over upfront information
   - Eliminated redundant instructions across contexts
   - Transitioned to automatic memory from manual CLAUDE.md documentation

## New Concepts Introduced

**Progressive Disclosure:** Loading context and instructions at the appropriate time rather than including everything upfront. This includes "deferred loading" tools that agents search for before using.

**Deferred Loading:** Tool definitions stored separately and accessed via ToolSearch only when needed, reducing unnecessary context consumption.

**Context Engineering:** The assembly of system prompts, skills, CLAUDE.md files, memory, and references that accompany user queries.

## Claude Features/Techniques Described

1. **claude doctor command:** New diagnostic tool helping users optimize skills and CLAUDE.md files for advanced models.

2. **Context Structure Layers:**
   - System Prompt (product-specific guidance)
   - CLAUDE.md (repository-specific gotchas, lightweight documentation)
   - Skills (lightweight guides with progressive disclosure)
   - References (in-depth specs, code mockups, codebases via @ mentions)

3. **Artifact Feature:** Rich visual and interactive references replacing simple markdown specifications.

4. **Dynamic Workflows:** Agent verification systems using rubrics to validate implementation quality.

5. **Auto-Memory:** Automatic, contextually-relevant memory saving without manual intervention.

## Supporting Data

- 80%+ reduction in system prompt length
- No measurable loss in coding evaluation performance
- Transition from example-based learning to interface design principles


# Claude Models Explained: Article Extract

**Title:** Claude models explained: choosing the best model for your use case

**Author:** Not specified

**Date:** July 24, 2026

**Reading Time:** 5 minutes

**Categories:** Enterprise AI, Agents, Claude Code

---

## Key Points

1. **Start with capable models**: The recommendation is to begin with "the most intelligent generally available model" and adjust effort levels for performance/cost optimization rather than starting with cheaper models.

2. **Cost-per-task efficiency**: More capable models often prove more economical despite higher per-token costs because they "require fewer turns and less thinking time to get most tasks right."

3. **Model selection framework**: Four critical questions guide selection:
   - How difficult is the task?
   - What latency requirements exist?
   - What access constraints apply?
   - What are the unit economics?

---

## Claude Model Family

| Model | Purpose | Key Characteristics |
|-------|---------|-------------------|
| **Mythos/Fable** | Most capable class | "Frontier capabilities across domains"; coding, agents, novel problem-solving |
| **Opus** | Reasoning-intensive enterprise | Powerful general performer; faster/cheaper alternative to Fable when quality bar met |
| **Sonnet** | Everyday/general purpose | Balanced performance/cost/speed; suitable for high-volume sub-agents |
| **Haiku** | High-frequency workloads | "Lowest cost and fastest model class" |

---

## Use-Case Routing Guidance

- **High-frequency customer-facing**: Sonnet preferred
- **Complex reasoning/novel problems**: Fable/Opus
- **High-volume production**: Lower model classes if evaluations confirm satisfactory performance
- **Latency-sensitive**: Haiku or Sonnet

---

## Advanced Strategy

**Advisor Strategy**: Pairs lower-cost worker models with capable advisor models for optimization. Example cited: "Sonnet 5 with Fable 5 advisor achieves within 10% of Fable 5's score at 63% of the cost."

---

## Evaluation Approach

Organizations should develop custom evaluations from production workloads rather than relying solely on benchmarks, as frontier models saturate standard test performance.


All three posts are relevant and worth ingesting:

1. **Product Designer / Claude Design** - Nate Parrott, July 24, 2026 - Founder/engineering content, Claude Code + Claude Design workflows. Relevant.

2. **Context Engineering for Claude 5** - Thariq Shihipar, July 24, 2026 - This is HIGHLY relevant. New concepts: progressive disclosure, deferred loading, context engineering for Claude 5 generation models. Major changes to how prompts work. This needs both a source page AND a concept page.
3. **Claude Models Explained** - July 24, 2026 - Covers model selection and introduces "Mythos/Fable" as a new model class, plus the "Advisor Strategy" pattern of pairing lower-cost workers with capable advisors. Worth capturing for anyone building with Claude.

Before I start writing pages, I should check what's already in the wiki to avoid duplicating existing content—looking at the home page, ingest log, and whether there's already a Claude models reference.


All three are relevant. Let me check the existing wiki structure before writing pages.