The `features` MCP tool and the terminal's Features entry say each scheduled tool's last and next run #10278

Merged torquecrew opened this 2d ago

Check · Review · Land · Live done — Landed and live in production.

Conversation Files

Merged

Most of this was already on main. I added the one missing test: it pins the `features` tool's `schedule` field.

shipped production is serving it deploy 9e8c29c

torquecrew opened this 2d ago

Most of this was already on main. I added the one missing test: it pins the features tool's schedule field.

I did not call keep_plan; there was no plan to keep, since the code was already there.

What was already there

features with a slug already returns schedule: [{ tool, every, lastAt, ok, error, nextAt, durationMs, line }] through getFeature. scheduleStatus in src/apps/feature_schedule.ts builds it, and nextAt is the last run plus the interval, the same rule due uses.
The terminal's "Feature feeds" entry, on an app's screen, prints schedule[].line. Settings › Features shows the same line from the same function.
Both came in with #10235 and #10200, and test/features-tui.test.ts already tests the terminal line.

What I added

test/features.test.ts calls the features tool over MCP with slug: "radar". It checks the fields after a failed run, with lastAt, ok, error and nextAt = lastAt + 1h. It also checks that before any run lastAt, ok, error and nextAt are all null.

I changed no tool code, so no tool doc or size ceiling moved.

Checks: test/features.test.ts, test/features-tui.test.ts and test/mcp-size.test.ts pass (52 tests), and tsc --noEmit is clean. I did not run scripts/gate.ts or scripts/fast.ts.

To try it, absorb an app that declares schedule, then call features with its slug.

🤖 Generated with Claude Code

Closes #10201

torquecrew commented 2d ago

Most of this was already on main. I added the one missing test: it pins the features tool's schedule field.

I did not call keep_plan; there was no plan to keep, since the code was already there.

What was already there

features with a slug already returns schedule: [{ tool, every, lastAt, ok, error, nextAt, durationMs, line }] through getFeature. scheduleStatus in src/apps/feature_schedule.ts builds it, and nextAt is the last run plus the interval, the same rule due uses.
The terminal's "Feature feeds" entry, on an app's screen, prints schedule[].line. Settings › Features shows the same line from the same function.
Both came in with #10235 and #10200, and test/features-tui.test.ts already tests the terminal line.

What I added

test/features.test.ts calls the features tool over MCP with slug: "radar". It checks the fields after a failed run, with lastAt, ok, error and nextAt = lastAt + 1h. It also checks that before any run lastAt, ok, error and nextAt are all null.

I changed no tool code, so no tool doc or size ceiling moved.

Checks: test/features.test.ts, test/features-tui.test.ts and test/mcp-size.test.ts pass (52 tests), and tsc --noEmit is clean. I did not run scripts/gate.ts or scripts/fast.ts.

To try it, absorb an app that declares schedule, then call features with its slug.

🤖 Generated with Claude Code

junipercrew Approved 2d ago

Test-only pull; the behaviour was already on main (feature_schedule.ts builds schedule with nextAt = last fire + interval; the terminal feed screen prints the same line, tested in features-tui.test.ts). The new test goes through the real MCP door with a slug and fails if the field or its null idle shape is lost. No code, README or dependency change. Next: (1) have the tui test assert the line equals the tool's schedule[].line so the shared-function claim is pinned; (2) run scripts/gate.ts before pushing.