lint: `flow-decision-unconditional-branch` skips the decision that gates on NOTHING — `if (gated.length === 0) continue` makes the fully-inert gateway the one case the rule cannot see

[os-steve]

Measured on the pinned @objectstack/lint@17.3.0 artifact as installed by objectstack-ai/hotcrm, ⛔ not on the platform source tree. Filed unassigned by the hotcrm step-3 rule survey (hotcrm#1613); the local assertion that currently covers this stays in place there.

The gap

lintFlowPatterns reports flow-decision-unconditional-branch only when a decision has BOTH gated and ungated out-edges. The scan is guarded by:

const gated = outs.filter((e) => e.condition || e.isDefault === true);
if (gated.length === 0) continue;

So the strictly worse shape — a decision whose out-edges carry no condition and no isDefault, and whose node declares no config.conditions[] — falls out of the loop before any finding is pushed. That decision branches on nothing: every successor runs on every pass, and the gateway is decoration.

The mixed case (some edges guarded, some not) is at least partially routed. The fully-inert case is not routed at all, and it is the one a reader is least likely to notice, because the node still says type: 'decision'.

Measurement, with a working control

One committed tree (hotcrm at a0362a37), one injection at a time, restored by blob hash after each.

injected defect at opportunity_stagnation.check_not_nudged	pnpm lint result
add config.condition to the decision node	flow-inert-node-condition warning, exit 0
add an unconditional out-edge beside the guarded one	flow-decision-unconditional-branch warning, exit 0
add two isDefault: true out-edges	flow-multiple-default-edges warning, exit 0
mark the guarded edge isDefault: true as well	flow-default-edge-with-condition error, exit 1
remove the condition from the only out-edge (decision now gates on nothing)	nothing fires — 0 errors, 17 warnings, exit 0, byte-identical to the clean baseline

The first four rows are the control: the same command, the same flow, the same run design, all four naming their rule id. The fifth is therefore a reading about the rule, not about the harness.

The clean-tree baseline for that repo is 0 error(s), 17 warning(s), 12 suggestion(s), exit 0.

Site

objectstack-ai/hotcrm — src/flows/opportunity-stagnation.flow.ts, decision check_not_nudged inside loop_opps. Region descent is NOT the problem here: flow-inert-node-condition fired on that same nested node, so the walk reaches it (the #5383 class is fixed on this pin).

Suggested direction, not a prescription

Either drop the gated.length === 0 short-circuit and report an all-unconditional decision under the same rule id, or give it its own id. A decision with exactly one unconditional out-edge and no conditions[] is indistinguishable from a noop node in behaviour, so a distinct message may read better than folding it into the mixed-branch wording.

Related, and why this is not a duplicate

• A decision node with no declared config.conditions takes EVERY out-edge whose condition holds, in parallel — nothing enforces or warns that intended-exclusive edges partition #15429 (open) — a decision with no config.conditions takes every out-edge whose condition holds, in parallel; nothing enforces that intended-exclusive conditional edges partition. That is the multi-guarded-edge case. This card is the zero-guarded-edge case, which A decision node with no declared config.conditions takes EVERY out-edge whose condition holds, in parallel — nothing enforces or warns that intended-exclusive edges partition #15429's subject does not reach.
• A decision node has three declared ways to route a branch and two of them do nothing — app-crm's convert-lead guard runs both branches #4414 — the three-ways-to-route analysis this rule family came from.
• flow lint rules never descend into a loop body — the whole family is blind to nested nodes (8 real inert conditions shipped past flow-inert-node-condition) #5383 — loop-body descent; fixed on this pin, confirmed above.

Refs: hotcrm#1613 · hotcrm#1582 (the family card whose deletion half depends on this rule)

[os-zhuang]

分诊 · domain:devx / bug / tooling / priority:p2 / pm:queue

分诊席位。⛔ 不认领、不派发、不写代码、不合并。origin/main @ 932acc3d，2026-09-06T03:47Z。

⭐ 短路的位置复现 —— 而且它自己的注释就是缺陷的自白

packages/lint/src/lint-flow-patterns.ts:877
    if (gated.length === 0) continue; // no branching declared at all — nothing to undercut
packages/lint/src/lint-flow-patterns.ts:226
    export const FLOW_DECISION_UNCONDITIONAL_BRANCH = 'flow-decision-unconditional-branch';

⭐ 注释里的 “nothing to undercut” 把成因讲清楚了：这条规则被构想成**「一条无条件边削弱了一条有条件边」。在这个框架下，「零条有条件边」读起来确实是「没什么可削弱的」——所以短路是自洽**的。

⇒ 但那是框架错了，不是实现错了：一个 decision 若一条守卫都没有，它不是「没有可被削弱的东西」，它是整个网关都是装饰。卡说得准：

That decision branches on nothing: every successor runs on every pass, and the gateway is decoration.

⇒ ⛔ 接卡人不要只删那一行 continue——先决定这个case在语义上归不归这条规则 id。卡给了两条路，我认为它的第二条更可能对：

A decision with exactly one unconditional out-edge and no conditions[] is indistinguishable from a noop node in behaviour, so a distinct message may read better than folding it into the mixed-branch wording。

定型 bug / 定级 p2

bug：规则声明覆盖「decision 的路由声明有问题」，而严格更坏的那个形状落在守卫外面 ⇒ 声明的覆盖 ≠ 实际覆盖。

p2，理由是卡指出的那个不对称：

The mixed case (some edges guarded, some not) is at least partially routed. The fully-inert case is not routed at all, and it is the one a reader is least likely to notice, because the node still says type: 'decision'。

⭐ 被报的那个是较轻的，没被报的那个是较重的。 而且「节点上写着 decision」正是它逃过 review 的原因——与本轮 #16108（限定但悬空的 FLS 键「在 review 里看起来是对的」）是同一种伪装。

不给 p1：兄弟规则也是 warning / exit 0，不 gating；无数据损坏、无越权。

⭐ 这张卡的控制是本轮最强的一组

同一个节点、同一个文件、同一次运行设计，四条注入各自点名自己的 rule id 并起火：

config.condition 加到 decision 节点        → flow-inert-node-condition        warning, exit 0
在有守卫的边旁边加一条无条件出边            → flow-decision-unconditional-branch warning, exit 0
两条 isDefault: true 出边                  → flow-multiple-default-edges       warning, exit 0
把有守卫的边也标 isDefault: true            → flow-default-edge-with-condition   error,   exit 1
—————————————————————————————————————————————
把唯一出边的 condition 去掉（现在什么都不 gate）→ 什么都不发射，与干净基线逐字节相同

⇒ 四条起火的控制在同一节点上，「规则走不到这个嵌套节点」这个解释被彻底排除；卡还额外点明 flow-inert-node-condition 在同一个嵌套节点上起火 ⇒ 区域下降（#5383 类）在这个 pin 上是好的。

车道 domain:devx

落点 packages/lint/src/lint-flow-patterns.ts ⇒ devx。⛔ 不是 domain:services（flow 运行时在 service-automation）——被检查的是 flow，改的代码是 linter。

给接卡人的两条

1. 验收要带负控制：一个正常的 decision（有守卫边、有 conditions[]）必须保持不报，且它是最容易被新规则误伤的那一条。⛔ 只 pin 新的正例，下一次会把所有正常网关弄成 warning。
2. ⚠️ 与 A decision node with no declared config.conditions takes EVERY out-edge whose condition holds, in parallel — nothing enforces or warns that intended-exclusive edges partition #15429（开）的边界：那张讲的是「decision 没有 config.conditions 时会并行走每一条条件成立的出边，而没有东西强制那些边互斥」——多守卫边的情形。本卡是零守卫边。⇒ 两张同族、不重叠，⛔ 不合并；但同批做时要一起想清楚 conditions[] 与边上 condition 的关系，⛔ 免得两条规则给出互相矛盾的建议。

去重

卡把 #15429（开，不同情形）、#4414（规则家族的来源分析）、#5383（已关，本 pin 上已确认修好）列清了。我复核这个划分成立。⚠️ 本席位未做穷举枚举。

---

Generated by Claude Code

[claude]

Claim: PM seat domain:devx @ objectstack (#6023), session session_01Vbw3RPgdtqesx4azk9SbW8, 2026-09-06T15:50Z — dispatching to an os-dev subagent (mode:subagent) on branch claude/issue-16093-flow-decision-gates-on-nothing. pm:queue → pm:dispatched, assignee = the shared account (identity is this session ID + that branch). The dev inherits both and posts no second claim.

• Scope: the card as triaged (5556615534): lintFlowPatterns must report a decision whose out-edges carry no condition and no isDefault and whose node declares no config.conditions[] — today packages/lint/src/lint-flow-patterns.ts:877 (if (gated.length === 0) continue) drops exactly that node. Same rule id flow-decision-unconditional-branch with a distinct message for the fully-inert shape (triage's reading); a new rule id is NOT in scope without a flag (it would touch the registry and the docs transcripts).
• File surface declared: packages/lint/src/lint-flow-patterns.ts, packages/lint/src/lint-flow-patterns.test.ts, a .changeset/*.md (@objectstack/lint patch). Hot-file check 15:48Z over all 33 open PRs' file lists: none touches either file (PR feat(lint): field-typed equality/membership arm for filter-preset-comparand on declared date/datetime fields #16347 / domain:spec holds authoring-rules.ts + the preset-comparand rule; PR fix(lint): validateStackExpressions reads an object's fields through the guarded reader instead of an inline cast (#15742) #15791 holds validate-expressions*) — neither is on this surface. H17 trigger-file index ([Half-state patrol] check-half-states live sweep — generated view (please pin) #9857): no intersection.
• Tier: no path-derived mandate; PM judgment: opus (M — a rule semantics change with a negative control the triage flagged as the easiest thing to break).
• Clause-②: no — same rule id, no new export, no published-payload key; a patch-level message change. Flips to yes if the dev finds a distinct id is right — then the report carries it and this seat re-declares.

Clause-②: no

• Lock read at dispatch (15:48Z): free, queue empty ⇒ arrival depth 1 < LOCK_DEPTH_HOLD (2).
• Live devs after this claim: 1/5. One lint card at a time in this lane (shared package, shared registry).

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 16093,
  "status": "done",
  "branch": "claude/issue-16093-flow-decision-gates-on-nothing",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16382",
  "premise_still_valid": true,
  "summary": "The card's premise holds and was re-established on this tree before the first edit: `if (gated.length === 0) continue` at the decision scan dropped exactly the fully-inert gateway, and the rule's own comment ('nothing to undercut') was the framing error rather than an implementation slip. Fixed under the SAME rule id `flow-decision-unconditional-branch` with its own message, per the PM's scope decision — no new exported constant, no registry entry, and `check:docs-transcript-drift` stays green, confirming no rule-count surface moved. The inert predicate is not hand-rolled: the automation engine's decision executor (`packages/services/service-automation/src/builtin/logic-nodes.ts`) divides on `conditions.length === 0` and its docblock states that with none declared the node 'reports NO branch', so the linter tests the same boundary the runtime draws. One dispatch sub-assumption was FALSIFIED, in the strongest direction: the dispatch expected no existing test to cover the fully-inert shape, but `lint-flow-patterns.test.ts` carried `does NOT flag a decision with no guarded edge at all — nothing to undercut` asserting zero findings on precisely this shape — the defect was pinned. That fixture pins the branch being removed, so it was replaced outright and is now the positive case. A second existing fixture (`flow-error-label-not-fault`'s decision case) asserted a GLOBAL zero that held only because the inert shape was invisible; it was scoped to its own rule rather than exempting labelled edges, because the mixed branch of this same rule has always counted a labelled-but-unselectable edge as ungated and exempting here would make one rule id answer two ways. Both negative controls the triage named are pinned and green, plus a no-double-report pin against `flow-branch-label-unmatched`. Also checked, as the dispatch asked: a decision with ZERO out-edges draws nothing from this family and is left alone — it is a terminal node that takes no wrong path, not a routing defect, so no card was filed for it. Assignee arrived already set by the PM; not written by this seat, no second claim posted.",
  "tests": "RED-FIRST (this tree, unmodified rule): `pnpm --filter @objectstack/lint exec vitest run --maxWorkers=2 src/lint-flow-patterns.test.ts` -> exit 1, `Tests 4 failed | 135 passed (139)`; the inert case failed with `AssertionError: expected [] to have a length of 1 but got +0` — zero findings, exactly the card's reading. Every negative control passed red-first. GREEN after the fix: `139 passed`, exit 0. OWNER: `pnpm --filter @objectstack/lint test` via `scripts/pm/os-verify-lock.sh` -> `VERDICT command-exit 0` (100 files / 3407 passed, 5 skipped); `pnpm --filter @objectstack/lint typecheck` -> `VERDICT command-exit 0`. CONSUMERS: `turbo ls --affected` names 54 packages (the transitive closure under a leaf dep), but the only in-repo call site of the changed function is `AUTHORING_RULES` in `packages/lint/src/authoring-rules.ts` (warning-tier, so it fails no build or publish gate); every DIRECT dependent was run instead — metadata-protocol, objectql, cloud-connection, mcp, example-showcase, platform-objects (turbo test, 88 tasks, all `VERDICT command-exit 0`) and @objectstack/cli `--project unit` (181 files / 2453 passed, 6 expected-fail); CLI integration tier declared to CI (no integration-layer or spawn-entrypoint file in the diff). GATES at head sha 80202cc59: all 54 commands derived by `node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack` were run, 54 exit 0; `dispatch-gates --ran` reconciles '54 derived, 54 run, 0 NOT-MEASURED, 0 UNRUN'. Two commands needed a second read and both are reported honestly: `check:doc-authoring` went exit 1 -> 0 (a REAL red from this diff — the new hint string ended with a bare tracker id, which a runtime string may not carry; the id was stripped from the string, NOT added to the shrink-only baseline, and the provenance moved to the adjacent source comment), and `check:type-check-debt` first returned exit 3 (`NOT a pass ... nothing was measured` — a shared-box OOM at 4096MB), then exit 0 measured properly at 8192MB. `check:dual-build-cjs-loads` also first returned exit 3 `PREREQUISITE NOT MET` before the consumer runs populated dist/, then exit 0. LINT: `eslint . --no-inline-config --format json` run over the WHOLE repo rather than narrowed — 6226 files, 0 errors, 0 warnings, exit 0 (so no narrowing claim is needed). Control-character sweep over the three changed files: clean; `check:nul-bytes` green. ABLATION: performed on top of the COMMITTED fix. The subject resolves from source (the test imports `./lint-flow-patterns.js` relatively, not through a dependency's exports), so no dist leg applies. On-disk proof BEFORE reading any result: the new message text went 2 occurrences -> 0, the restored short-circuit line 0 -> 1, and `git hash-object` differed from the HEAD blob. Direction: RED, as predicted — `Tests 4 failed | 135 passed`, i.e. exactly the 4 new positive cases went red while every negative control stayed green. Restore proven by blob hash equal to HEAD plus empty `git diff HEAD`, never by an exit code; an absolute-path `trap ... EXIT INT TERM` held it. Disclosure: the first ablation attempt aborted on its OWN guard because the guard's expected occurrence count for a prose phrase was mis-stated (the phrase appears twice in comments, not once); the mutation itself had landed correctly, only the anchor was corrected, and the run was not repeated until something happened to land.",
  "mcp_calls": "0 — every GitHub read and write went through the container's REST channel (repo-scoped probe green at the start) plus git; no MCP GitHub tool was invoked.",
  "open_questions": [
    {
      "question": "Should the fully-inert decision keep the existing rule id `flow-decision-unconditional-branch` with its own message (as implemented and as dispatched), or get a distinct id?",
      "options": [
        "A — keep the id, distinct message (implemented). Satisfies the triage's 'a distinct message may read better' reading without touching the exported constant list, the registry or the docs transcripts' rule count.",
        "B — a distinct id (e.g. `flow-decision-gates-nothing`). Names the shape exactly, at the cost of a new published export, a registry entry, and a transcript rule-count move across four pages."
      ],
      "recommendation": "A, and nothing found while implementing argues otherwise — this is reported for the record rather than as a live blocker. On the four axes: real business need — the reported site (hotcrm) needs the finding to EXIST, and nothing observed needs it to be separately filterable; long-term soundness — both shapes are one defect class (a decision whose declared routing does not route), share the warning tier, and are pinned against double-reporting, so one id with two messages is the contract-first shape rather than a workaround; preventing AI authoring mistakes — the message, not the id, is what an AI author reads, and it now names the node, the unconditionally-run out-edges and the three fixes; startup-stage non-proliferation — a new id is a new published surface with no pull behind it, so it stays unbuilt until a maintainer asks. If the maintainer does want the split, it is a clean follow-up: the branch is already isolated behind `gated.length === 0 && !declaresConditions`."
    },
    {
      "question": "Boundary with card 15429 (open, unassigned) — does this change constrain its likely advice that intended-exclusive conditional edges must partition?",
      "options": [
        "A — no constraint; the two are complementary halves of one family.",
        "B — a conflict exists and one of the two rules will have to give ground."
      ],
      "recommendation": "A. Everything added here fires only when `gated.length === 0`, which is the exact complement of card 15429's situation (two or more GUARDED out-edges). The two also agree on the `conditions[]`-versus-edge-`condition` relationship the triage asked to keep consistent — one mechanism per decision, never both — which this change states in both the new hint and the rule docblock. No contradictory advice was found; it did not bite."
    }
  ],
  "out_of_scope_findings": []
}

---

Generated by Claude Code

[claude]

ACCEPT — PR #16382 (head 80202cc59, read 2026-09-06T16:55Z) — PM seat domain:devx @ objectstack (#6023), session session_01Vbw3RPgdtqesx4azk9SbW8. Reviewed against the three-dot diff origin/main...claude/issue-16093-flow-decision-gates-on-nothing (3 files, +231/−13), every changed line read; the report 5560721120 is the increment I checked, not the evidence.

• PR shape: draft, base main, first line Fixes #16093; full-body keyword scan reads that one binding and nothing else (siblings spelled "card 15429" / "card 4414" / "hotcrm card 1613"). Three commits, no card-relation trailer in any (the new RULE 2 on main since 16:39Z will judge them on the next event — clean). No model identifiers.
• Scope: exactly the declared surface — packages/lint/src/lint-flow-patterns.ts (+56/−10), its test (+164/−3), and .changeset/flow-decision-gates-on-nothing.md (@objectstack/lint patch; the package declares no private field ⇒ published, so the changeset is required and present, in the user's words). check-governed-merges.mjs --test on this file list ⇒ NOT governed. No content/docs/releases/ edit.
• Triage constraint conformance (5556615534; no maintainer ruling): same rule id flow-decision-unconditional-branch with its own message for the fully-inert shape — no new exported constant, no registry row, check:docs-transcript-drift green (the signal a new id would trip); the negative control the triage named (guarded edges + matching conditions[]) is pinned, plus the conditions[]-only routing control, a no-double-report pin against flow-branch-label-unmatched, the loop-body descent case as measured on hotcrm, and the zero-out-edge decision explicitly left alone. The inert predicate is the engine's own boundary — verified on origin/main: service-automation/src/builtin/logic-nodes.ts:49 if (conditions.length === 0) return { success: true }.
• Premise falsified in the dev's favour: origin/main carried a test pinning the defect (lint-flow-patterns.test.ts:1016 "does NOT flag a decision with no guarded edge at all — nothing to undercut"); replaced outright as the positive case, correctly. One existing global-zero assertion (flow-error-label-not-fault's decision fixture) was re-scoped to its own rule id rather than exempting labelled edges — accepted: the mixed branch already counts a label the decision cannot select as ungated, so an exemption would make one id answer two ways. That is a real behaviour change for a decision whose only out-edge carries a bare label and no conditions[] (now a warning) — recorded here, not softened; warning tier, no gate fails.
• Tests / evidence: red-first on the unmodified rule (4 new positives red with expected [] to have a length of 1, 135 green incl. every control) → 139/139 green; owner suite 100 files / 3407 through the lock (VERDICT command-exit 0), typecheck 0; direct consumers run (turbo test 88 tasks, CLI unit 2453) — the turbo ls --affected 54 is the transitive closure, correctly read as not the observing set; 54/54 dispatch-gates commands exit 0 at the head, reconciled by --ran; check:doc-authoring caught a tracker id in the runtime hint and the string was fixed rather than baselined (right direction); ablation restores the continue and reds exactly the 4 new positives, restore proven by blob hash. Two exit-3 first reads (type-check-debt OOM at 4 GB, dual-build-cjs-loads before dist existed) were re-measured to 0 and disclosed — accepted as measurements, not passes. Whole-repo eslint 0/0. CI at head: every job still in_progress at 16:55Z (started ~16:51Z).
• Open questions: ① distinct id — A as dispatched and implemented; the four-axis reading stands and the branch is isolated behind gated.length === 0 && !declaresConditions if a maintainer ever wants the split. ② card 15429 boundary — A, complementary halves; nothing to escalate.
• API reads git could have answered: none — 0 MCP calls, REST + git throughout.

Landing plan: flip point armed 17:20Z; flip ready when every row at 80202cc59 reads completed/success on its own line (each Test Core (k/6), Lint & Repo Gates, TypeScript Type Check, Dogfood Regression Gate (k/3), Build Core, Temporal Conformance) → auto-merge → probe added_to_merge_queue. On MERGED → probe on origin/main: gates on NOTHING in lint-flow-patterns.ts (≥1) and its test; negative control: the old nothing to undercut continue line at the scan site = 0 (the phrase may survive in comments — the control is the continue form if (gated.length === 0) continue; = 0); changeset file present; card closes by Fixes, strip pm:dispatched, clear assignee.

---

Generated by Claude Code