Spec review: peel server integrations into ty plugins (Slack first) - #40
Open
bborn wants to merge 1 commit into
Open
Spec review: peel server integrations into ty plugins (Slack first)#40bborn wants to merge 1 commit into
bborn wants to merge 1 commit into
Conversation
Reviews the "peel taskyou-os server integrations into ty plugins" spec against the shipped ty 0.3.21 binary and this repo's code. Verdict: ship v1 as scoped. Three corrections, four additions. Corrections: - linear-poll cannot become a ty routine — routines are unattended *agent* runs (prompt.md), and linear-poll is 347 lines of deterministic GraphQL. Converting it is a rewrite into 720 metered LLM runs/day/GM. - `ty plugins remove` already exists; the v2 gate is pinning + disable only. - The warn-and-continue failure mode is a two-line fix, not a reason to migrate. Additions: - v1 must disable and delete ty-slack.service first, or existing GMs run two bridges and post every Slack notification twice. - `command: node ./slack-bridge.mjs` won't find node under the daemon's minimal PATH; symlink the resolved node into ~/bin. - Moving from systemd sibling to daemon child is a real coupling trade, acceptable only because the bridge is verifiably restart-safe. - .env and .slack-state.json inside the code dir block v2's git-pull model. Also answers the five open decisions and reorders the three ty supervisor gates to status -> logs -> restart. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reviews the "peel taskyou-os server integrations into ty plugins (start with Slack)" spec, grounded in the installed
ty0.3.21 binary and this repo's code rather than the spec's description of ty.Verdict: ship v1 as scoped. The core thesis is right and the gating is honest. Three corrections, four additions — one of which is a duplicate-message bug in the v1 plan as written.
Confirmed
All of the spec's ty claims hold:
services:is shipped in 0.3.21, the supervisor genuinely has no log capture and no restart/backoff,ty plugins addis an unpinned clone +git pull, andsetup.shhas no version gate. The three v1 gates are real.Also verified something the spec depends on but never states: the bridge is restart-safe —
.slack-state.jsonpersistsnotifyOffset, advances it before posting, and a lost state file resets to EOF rather than replaying history.Corrections
linear-pollcannot become a routine.ty routines --help: routines are "named, unattended agent runs: aprompt.md".linear-poll.mjsis 347 lines of deterministic GraphQL with a cursor and a dedup set. Converting it is a rewrite into 720 metered LLM runs/day/GM with nondeterministic dedup. Drop the "Periodic jobs = routines" section — it contradicts the spec's own (correct) "what does NOT move".ty plugins removealready exists — the v2 gate is--refpinning + per-plugin disable only.Additions v1 needs
ty-slack.servicefirst. Otherwise every existing GM runs two bridges with separate state files, both tailingnotifications.jsonl→ every Slack notification posts twice, and two Socket Mode connections split inbound events and the thread map.command: node ./slack-bridge.mjswon't find node.ty-daemon.service's PATH excludes the asdf node path — which is exactly whysetup_slack_remoteresolves node viabash -lcand bakes{{NODE_BIN}}absolute today. Fix: symlink the resolved node into~/bin(already on the daemon's PATH), keepingplugin.yamlstatic..env+.slack-state.jsoninside the code dir are fine for v1's scp, disqualifying for v2's git-clone-and-pull.Also
Answers the five open decisions (block on the ty release rather than dual-path;
.env-in-dir for v1 with out-of-checkout config as a hard v2 gate; daemon restart is fine for token changes; gate onty --versionand aty plugins listoutcome check; yes to per-pluginservices:opt-in in v2) and reorders the three ty supervisor gates to status → logs → restart — status is the only onesetup.shcan act on, and a crash-at-init bridge needs a log more than it needs a retry.Docs-only; no code changes.
🤖 Generated with Claude Code