Skip to content

fix(specs): ten 999 function and cron specs come home from trinity's mirror - #7304

Merged
gHashTag merged 4 commits into
masterfrom
fix/vendor-mirror-specs-6968
Oct 7, 2026
Merged

gHashTag merged 4 commits into
masterfrom
fix/vendor-mirror-specs-6968

Conversation

@gHashTag

@gHashTag gHashTag commented Oct 7, 2026 •

Copy link
Copy Markdown
Owner

Closes #6968

Why the world scan is red

t27-world-scan.yml in gHashTag/trinity has failed on every run since 2026-10-03. agents-from-specs reported 9 orphan entries in apps/website/i18n/agents.ru.json. The cause is not a token or a wrong owner. The 404 in the log comes from dmitrii-f-t27/homebrew-tap, and dmitrii-f-t27/999-multibots-telegraf is a different repository with no .t27 files.

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:

Function Cron in the code Cron card
ton-pending-watch 0 * * * * inngest/999-multibots-telegraf/ton-pending-watch
robokassa-unclaimed-watch 20 7 * * * inngest/999-multibots-telegraf/robokassa-unclaimed-watch
club-invoice-abandoned-watch 20 * * * * inngest/999-multibots-telegraf/club-invoice-abandoned-watch
client-telemetry-daily 0 7 * * * inngest/999-multibots-telegraf/client-telemetry-daily
crm-proactive-sweep */30 * * * * inngest/999-multibots-telegraf/crm-proactive-sweep

So the specs come home. The RU entries describe live functions and stay.

What changes

  • ae41f48: 9 new specs, byte-identical to trinity main 0e1a789d7. These are specs/functions/{ton-pending-watch,robokassa-unclaimed-watch,club-invoice-abandoned-watch,client-telemetry-daily}.t27 and specs/crons/999-multibots-telegraf-{the same four,crm-proactive-sweep}.t27.
  • 48eab40: the tenth file, 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:

Only .t27 files change.

Evidence

Run in a scratch trinity worktree at main 0e1a789d7, with T27_REF=fix/vendor-mirror-specs-6968 and T27_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.mjs rc 0, t27 @ 48eab40f1, 1483 specs. specs/numeric/ocp_mx.t27 is in the synced corpus.
  • node scripts/agents-from-specs.mjs rc 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.
  • t27 hooks: tri hooks pre-commit: PASSED, L1 issue reference PASSED, own-language PASSED on push.

What this does not fix

check:agents still fails after this merges, for two reasons in trinity's qa/agents-spec-contract.mjs. Both need trinity .mjs edits and the owner's owner-approved-foreign label, so they are filed in trinity, not here:

  1. Line 155 requires SCHEDULE on every non-timer cron. The 13 HOST "launchd" cards from 0930ccd use INTERVAL_MS, which trinity#1354 already taught the generator.
  2. specs/i18n/blog-ru.t27 (755baec, 2026-10-05) is an i18n contract that no trinity generator claims yet.

With both patched locally, check:agents passes: 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-user from SIDE_EFFECTS and the NOTE said the card never reaches an end client. In 999 services/crmProactive.ts:1411-1413, pushCard reads the seller's autopilot switch first and, when it is on, calls confirmProposal -> 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. SIDE_EFFECTS is now [5]str with messages-user kept, 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

gHashTag and others added 2 commits October 7, 2026 00:01
…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>
@gHashTag

gHashTag commented Oct 7, 2026

Copy link
Copy Markdown
Owner Author

The two trinity contract gaps that keep check:agents red after this merges are filed as gHashTag/trinity#1453. Patch A (launchd INTERVAL_MS) is parked on trinity branch fix/contract-launchd-interval at 785b6e31a; it needs the owner's owner-approved-foreign label. Gap B (specs/i18n/blog-ru.t27 has no consumer) needs the owner's choice between a pending list and a blog consumer.

@gHashTag gHashTag left a comment

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
@gHashTag

gHashTag commented Oct 7, 2026

Copy link
Copy Markdown
Owner Author

Fixed in 35e3bf3: SIDE_EFFECTS keeps messages-user (now [5]str), and the NOTE says that with autopilot on, pushCard confirms the draft through POST /api/tg/proposal/confirm (999 services/crmProactive.ts:1411-1413, #2903, #2925), so the message reaches the client's chat from the seller's account. The PR body and the work report's head_sha follow the new head.

@github-actions

github-actions Bot commented Oct 7, 2026

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-10-07 05:53:11 UTC

Summary

Status Count
Total Open PRs 50
PRs with Failing Checks 49
PRs with All Checks Green 1
READY 0
FAILING 49
PENDING 0
NO CHECKS YET 0

These columns do not partition: 0 + 49 + 0 + 0 = 49, and there are 50 open PRs. A PR is being counted twice or not at all.

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=b23641f01baa != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

1 similar comment
@github-actions

github-actions Bot commented Oct 7, 2026

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-10-07 05:53:11 UTC

Summary

Status Count
Total Open PRs 50
PRs with Failing Checks 49
PRs with All Checks Green 1
READY 0
FAILING 49
PENDING 0
NO CHECKS YET 0

These columns do not partition: 0 + 49 + 0 + 0 = 49, and there are 50 open PRs. A PR is being counted twice or not at all.

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=b23641f01baa != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

@gHashTag

gHashTag commented Oct 7, 2026

Copy link
Copy Markdown
Owner Author

The two red checks on 35e3bf3 are master drift, not this PR:

Both workflows were checked once on master (gh run list --branch master); no re-run was requested.

Picks up #7316, which makes the corpus and t27b types ratchets green.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Oct 7, 2026

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-10-07 06:50:47 UTC

Summary

Status Count
Total Open PRs 50
PRs with Failing Checks 49
PRs with All Checks Green 1
READY 0
FAILING 49
PENDING 0
NO CHECKS YET 0

These columns do not partition: 0 + 49 + 0 + 0 = 49, and there are 50 open PRs. A PR is being counted twice or not at all.

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=b23641f01baa != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

This was referenced Oct 7, 2026
@gHashTag
gHashTag merged commit fe1c866 into master Oct 7, 2026
30 of 32 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Nine function and cron specs live only in trinity's vendored mirror, so the t27 world scan is red

1 participant