Repository navigation
fix(specs): ten 999 function and cron specs come home from trinity's mirror - #7304
Conversation
…s mirror trinity#1124 wrote these specs straight into trinity's vendored copy of this repo (apps/website/public/t27/files/specs). The world scan rebuilds that copy from here, so every run deleted them, left nine RU entries in agents.ru.json without a spec, and failed. It has been red since 2026-10-05; the runs of 10-03 and 10-04 failed on the 29-vs-28 count these specs also settle (29 + 4 = 33 = the witness rows). Byte-identical to trinity main 0e1a789d. All five functions are live in 999-multibots-telegraf main @dbbe759 with the schedules the specs state. master's own crm-proactive-sweep function spec is newer and is kept. Closes #6968 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…he deployed id trinity#1124 wrote its own copy of specs/functions/crm-proactive-sweep.t27 into the site mirror on 2026-10-04, two days after t27#4113 created the spec here. The scan that would have reconciled them has been red since 2026-10-03, so the site carried trinity's copy while t27 kept LEGACY_ID "". With LEGACY_ID empty, agents-from-specs cannot join the function to inngest/999-multibots-telegraf/crm-proactive-sweep, and check:agents fails with "its cron card null is in the crons catalog". Kept: t27's newer reading (per-seller steps, the 502 history, the test). Taken from trinity's copy, each checked against 999 main 40d0531eb: - LEGACY_ID "crm-proactive-sweep": the id inngest.createFunction registers - GUARD "safe-mode": isSafeMode returns before the first step - SIDE_EFFECTS messages-owners + external-webhook: the card goes to the seller's own chat after the render's CRM tools are called over HTTP - SAFE_PROBE "" / PROBE_RESULT "skipped": the 2026-09-09 probe pass predates the 2026-09-12 registration, so no probe was sent Refs #6968 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
The two trinity contract gaps that keep |
gHashTag
left a comment
There was a problem hiding this comment.
Independent review: one defect in specs/functions/crm-proactive-sweep.t27. Not merging.
Everything else checks out. The head is 48eab40 and only .t27 files change. The 9 new specs are blob-identical to trinity 0e1a789d7. In 999 main (40d0531eb is an ancestor of main), crmProactiveSweep.ts registers the id crm-proactive-sweep at L103, returns on isSafeMode at L111 before resolve-sellers, and uses the cron */30 * * * *. The other four ids and crons match the table, and all five are in registerFunctions.ts. The work-report JSON parses, and its head_sha matches the head.
Defect: SIDE_EFFECTS drops messages-user, and the NOTE says "not to an end client", but under autopilot the sweep writes to the end client.
In src/services/crmProactive.ts on main, liveDeps().push is pushCard. When takeAutopilotSend(ownerId, lead) is true, pushCard calls confirmProposal (telegramProposals.ts, POST /api/tg/proposal/confirm). The code comment there reads "THE MESSAGE IS ALREADY IN THE CLIENT'S CHAT", and the owner gets only a receipt. Autopilot has been on main since #2903/#2925 (2026-09-23/24). So a scheduled run, with nobody pressing a button, can send the drafted message into a client's chat from the seller's account. The function card should show that.
Suggested fix: keep messages-user next to messages-owners ([5]str). Reword the NOTE to say that the card goes to the seller's private chat, and that when the seller has turned on autopilot (services/crmAutopilot.ts), the same tick confirms the draft through the render and the message reaches the client without a press.
Separately, the required checks check-linked-issue and parse-ratchet were still queued when I read them.
…es to the client Review of #7304: pushCard (999 services/crmProactive.ts:1411-1413) reads the seller's autopilot switch first and, when it is on, confirms the draft through the render's POST /api/tg/proposal/confirm. The message then lands in the client's chat from the seller's account with no press (999 #2903, #2925). SIDE_EFFECTS keeps messages-user next to messages-owners, and the NOTE says so. Refs #6968 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Fixed in 35e3bf3: |
1 similar comment
PR DashboardGenerated at: 2026-10-07 05:53:11 UTC
Summary
Seal Status
|
|
The two red checks on 35e3bf3 are master drift, not this PR:
Both workflows were checked once on master ( |
Picks up #7316, which makes the corpus and t27b types ratchets green. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
PR DashboardGenerated at: 2026-10-07 06:50:47 UTC
Summary
Seal Status
|
Closes #6968
Why the world scan is red
t27-world-scan.ymlin gHashTag/trinity has failed on every run since 2026-10-03.agents-from-specsreported 9 orphan entries inapps/website/i18n/agents.ru.json. The cause is not a token or a wrong owner. The 404 in the log comes fromdmitrii-f-t27/homebrew-tap, anddmitrii-f-t27/999-multibots-telegrafis a different repository with no.t27files.The cause is gHashTag/trinity#1124 (2026-10-04). It wrote ten specs straight into trinity's vendored mirror
apps/website/public/t27/files, not into t27. Every sync rebuilds that mirror from t27 and wipes the ten. The RU entries for them stay behind as orphans. All five functions are live in gHashTag/999-multibots-telegraf main with the schedules the cards state:0 * * * *inngest/999-multibots-telegraf/ton-pending-watch20 7 * * *inngest/999-multibots-telegraf/robokassa-unclaimed-watch20 * * * *inngest/999-multibots-telegraf/club-invoice-abandoned-watch0 7 * * *inngest/999-multibots-telegraf/client-telemetry-daily*/30 * * * *inngest/999-multibots-telegraf/crm-proactive-sweepSo the specs come home. The RU entries describe live functions and stay.
What changes
specs/functions/{ton-pending-watch,robokassa-unclaimed-watch,club-invoice-abandoned-watch,client-telemetry-daily}.t27andspecs/crons/999-multibots-telegraf-{the same four,crm-proactive-sweep}.t27.specs/functions/crm-proactive-sweep.t27, already existed here (specs/functions: crm-proactive-sweep -- one step per seller after the 502 runs #4113, 2026-10-02). trinity#1124 wrote a second version of it two days later. This commit keeps t27's newer reading (per-seller steps, the 502 history, the test) and takes four corrections from trinity's copy, each checked against 999 main 40d0531eb:LEGACY_ID "crm-proactive-sweep": the idinngest.createFunctionregisters (crmProactiveSweep.ts#L103). With""the function cannot join its cron card, andcheck:agentsfails with "its cron card null is in the crons catalog".GUARD "safe-mode":isSafeModereturns before the first step.SIDE_EFFECTSaddsmessages-ownersandexternal-webhookand keepsmessages-user: the card goes to the seller's own chat (services/crmProactive.ts) after the render's CRM tools are called over HTTP, and when the seller has autopilot on,pushCardconfirms the draft through the render'sPOST /api/tg/proposal/confirmand the message reaches the client's chat (999 cli/tri-mcp is in neither workspace members nor exclude -- the same defect Cargo.toml already documents for ffi #2903, Ten constants declare a type they cannot fit; three of four backends emit them verbatim #2925).SAFE_PROBE "",PROBE_RESULT "skipped": the 2026-09-09 probe pass predates the 2026-09-12 registration.Only
.t27files change.Evidence
Run in a scratch trinity worktree at main 0e1a789d7, with
T27_REF=fix/vendor-mirror-specs-6968andT27_SKIP_REMOTE=1. The full run with every extra repository was stopped because the Mac had 5 GB of disk left; the CI run after the merge is the full check.node scripts/sync-t27-specs.mjsrc 0,t27 @ 48eab40f1, 1483 specs.specs/numeric/ocp_mx.t27is in the synced corpus.node scripts/agents-from-specs.mjsrc 0: functions 33 (typecheck ok 33/33), cron cards joined 10/10, crons 55 (typecheck ok 55/55), i18n ru functions 33/33, orphans 0.tri hooks pre-commit: PASSED, L1 issue reference PASSED, own-language PASSED on push.What this does not fix
check:agentsstill fails after this merges, for two reasons in trinity'sqa/agents-spec-contract.mjs. Both need trinity.mjsedits and the owner'sowner-approved-foreignlabel, so they are filed in trinity, not here:SCHEDULEon every non-timer cron. The 13HOST "launchd"cards from 0930ccd useINTERVAL_MS, which trinity#1354 already taught the generator.specs/i18n/blog-ru.t27(755baec, 2026-10-05) is an i18n contract that no trinity generator claims yet.With both patched locally,
check:agentspasses: orphans 0, cron cards 10/10. The trinity issue is linked in a comment below once it is filed.Review round 1 (35e3bf3)
The reviewer of 48eab40 found one defect: the first version dropped
messages-userfromSIDE_EFFECTSand the NOTE said the card never reaches an end client. In 999services/crmProactive.ts:1411-1413,pushCardreads the seller's autopilot switch first and, when it is on, callsconfirmProposal-> the render'sPOST /api/tg/proposal/confirm; the message then lands in the client's chat from the seller's account with no press.SIDE_EFFECTSis now[5]strwithmessages-userkept, and the NOTE says so. Nothing else changed.{ "version": 1, "head_sha": "8021ff2a645477408d89670fc40f7f6708144b20", "summary": "Ten function and cron specs that trinity#1124 wrote straight into trinity's vendored mirror come home to t27, so the world scan stops wiping them and orphaning their Russian entries; crm-proactive-sweep gets the legacy id its cron card joins on.", "changes": [ "specs/functions/ton-pending-watch.t27, robokassa-unclaimed-watch.t27, club-invoice-abandoned-watch.t27, client-telemetry-daily.t27: new, byte-identical to trinity main 0e1a789d7", "specs/crons/999-multibots-telegraf-{ton-pending-watch,robokassa-unclaimed-watch,club-invoice-abandoned-watch,client-telemetry-daily,crm-proactive-sweep}.t27: new, byte-identical to trinity main 0e1a789d7", "specs/functions/crm-proactive-sweep.t27: LEGACY_ID, GUARD, SIDE_EFFECTS and the probe fields corrected against 999 main 40d0531eb; NOTE records why" ], "tests": [ { "command": "T27_REF=fix/vendor-mirror-specs-6968 T27_SKIP_REMOTE=1 node scripts/sync-t27-specs.mjs (trinity apps/website, main 0e1a789d7)", "result": "rc 0, t27 @ 48eab40f1, 1483 specs, specs/numeric/ocp_mx.t27 present", "status": "passed", "evidence": "local run in a scratch trinity worktree" }, { "command": "node scripts/agents-from-specs.mjs", "result": "rc 0; functions 33/33 typecheck ok, cron cards joined 10/10, crons 55/55 typecheck ok, i18n ru functions 33/33, no orphans", "status": "passed", "evidence": "generator summary lines" }, { "command": "npm run check:agents with the two trinity contract patches applied locally", "result": "rc 0; orphans 0, cron cards 10/10; without the patches it fails at qa/agents-spec-contract.mjs:155 (launchd) and :688 (blog-ru), both outside this repository", "status": "passed", "evidence": "local run; the patches were reverted afterwards" }, { "command": "git -c core.hooksPath=.githooks commit / git push", "result": "tri hooks pre-commit PASSED, issue reference PASSED, own-language PASSED", "status": "passed", "evidence": "hook output on ae41f4899, 48eab40f1 and 35e3bf350" } ], "limitations": [ "The full scan with every extra repository was not run locally (5 GB of disk left); the CI run of t27-world-scan.yml after this merges is the full check", "The world scan stays red on check:agents until trinity's qa/agents-spec-contract.mjs learns launchd jobs and the blog-ru contract, which needs the owner's owner-approved-foreign label" ], "tags": [ "t27", "specs", "worldscan" ] }🤖 Generated with Claude Code