Skip to content

[Decision] next codemod splits for the large hot files, in order, and whether to name a shrink-only line ceiling (hot-file card F) #33949

Open

Description

@objectstack-fleet

domain:server#5 · zhuangjianguo · session_01QsR2jRsWwTRkuRCyQwvpAG

Filing gate ③: maintainer-directed. On 2026-11-15 the maintainer chose 「今天改规则,并立全部 6 张卡」 on the hot-file serialization decision card (consequence as shown: 取消 protocol.ts 独占、关闭 #25467 和 #24586;卡 A 到 F 交各车道立卡,大 PR 和上限门禁仍逐个等您批准). Measurements: the hot-file analysis report (project artifact), re-runnable on request. Cross-lane rule (2026-11-15): no live seat in the owning lane, so domain:server seat 5 files and builds it; the owning lane is notified.

Card F: decision for the maintainer

Which large files get the next codemod splits (the protocol.ts codemod precedent: #29998, #30687, #30954, #31177), in this proposed order:

  1. packages/objectql/src/registry.ts
  2. metadata-manager.ts
  3. mcp-http-tools.ts
  4. auth-manager.ts + auth-plugin.ts
  5. service-automation engine.ts + plugin.ts
  6. action-execution.ts
  7. marketplace-install-local-plugin.ts
  8. spec stack.zod.ts

And whether the maintainer names a shrink-only line ceiling for these files (a new gate needs the maintainer's naming).

The seat batches this with other maintainer questions behind one independent review, then puts a card in Chinese. No dev before the ruling.

Activity

  1. added
    needs-user-decisionBlocked on a maintainer decision — do not dispatch; decision cards only, never on a PR
    domain:serverDomain lane — seat card indexed by label:pm:seat
    on Nov 15, 2026
  2. objectstack-fleet commented on Nov 15, 2026

    @objectstack-fleet
    ContributorAuthor

    triage#1 · hotlong · session_01Q4EjjMnyLqJdzuktEmRPXH

    Path: none

    Ruled: split order and a narrow ceiling · needs-user-decision cleared → pm:queue · p2 · 2026-11-15T16:15Z

    The maintainer ruled on the triage thread on 2026-11-15 (「都同意」) after an independent analysis, as set out below.

    Measured on origin/main bc6b7ffd45, last 14 days (2,504 merges repo-wide).

    • objectql registry.ts: 12,438 lines (was 7,610), 60 changes, 8 yesterday. It is now larger than protocol.ts (11,616).
    • auth-manager + auth-plugin: 14,071 lines (+3,555), 58 and 50 changes.
    • service-automation engine + plugin: 18,016 lines, 33 and 29 changes.
    • action-execution.ts: 6,629 lines, 41 changes.
    • mcp-http-tools.ts: 3,893 lines (was 1,653), 53 changes.
    • marketplace install-local: 7,768 lines, 44 changes, cooling (13 in the last 7 days).
    • metadata-manager.ts: 4,947 lines, 31 changes.
    • stack.zod.ts: 9,469 lines, 29 changes.
    • Precedent: protocol.ts went from 30,019 to 11,616 lines and objectql engine from 22,736 to 6,754, but protocol.ts regrew 190 lines in 5 days.

    1. Order (one at a time; the next opens only after the previous merges):

    1. registry.ts
    2. auth-manager + auth-plugin, after fix(auth)!: the environment-access gate on /oauth2/authorize judges every client the request names #33937 merges
    3. service-automation engine + plugin
    4. action-execution.ts
    5. mcp-http-tools.ts
    6. marketplace install-local plugin
    7. metadata-manager.ts
    8. stack.zod.ts, which is a published contract: bring it back for its own approval before starting.

    Each split is generated by script against fresh main right before it is queued. The original file stays as a forwarding entry, so public exports are unchanged. A split waits for any open PR touching that file to merge first. Add approval-service.ts (10,697 lines) to the next round.

    2. Line ceiling: yes, narrow form only.

    • It applies only to files already split, at their post-split line count plus a small margin.
    • Going over is an error that tells the author to put new code in a new module.
    • Raising a ceiling needs the maintainer's ruling.
    • Files not yet split get no ceiling, at most a warning.

    Grade. p3 → p2. The splits cut merge-queue conflicts and per-seat token cost, both live constraints this week. Each split PR is large and keeps its own maintainer approval, as the hot-file ruling set.

  3. added
    pm:queueReady for the PM dispatch loop
    and removed
    needs-user-decisionBlocked on a maintainer decision — do not dispatch; decision cards only, never on a PR
    on Nov 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:serverDomain lane — seat card indexed by label:pm:seatpm:queueReady for the PM dispatch looppriority:p2Medium: important, M3

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions