Deferred, non-blocking residue from the two review rounds on PR #678 (fix for #676), triaged at head b0a9e41730282b84ccb1480486ee0a4b4a062cc5. Every numbered finding from both rounds (round 1: 2 major + 1 minor; round 2: 3 major + 1 minor) is verified fixed at that head; these three were noted by the rounds as real but deliberately out of that PR's scope. None blocks merge.
Note: PR #678 is stacked on PR #658 (base fix/issue-653); the file:line references below are to that branch. Do not start this until #658 and #678 have both merged and #678 has been retargeted to master.
1. Dropped upstream names are printed unsanitized and uncapped
src/core/daemon/status.js prints the dropped names from the status file directly into the warning message (droppedUpstreamConsequence, lines 321, 339, 345, via stringList only), while recentEntrypointsFromSources (lines 397-416) runs the same class of untrusted-file strings through sanitizeLabel and caps them. Both read the same file another build may have written.
Why non-blocking: pre-existing, it predates PR #678 entirely (the old parenthetical on the base branch printed the same list), and the exposure is display of a local file's content in local CLI output. Both review rounds deferred it as belonging to a separate change. Hardening, not a defect introduced or left by #678.
2. The hedged branch's "the same name" can have no printed antecedent
A nameless drop (an entry missing name, an ordinary current-build config) reaches the !attribution branch of droppedUpstreamConsequence with names.length === 0, so the message (src/core/daemon/status.js:329) says "unless an adapter preset already covers the same name" about a name the operator never sees, and the preset hedge is arguably vacuous there (an entry with no name cannot collide with a preset).
Why non-blocking: the sentence is awkward, not false. Closing it needs the gateway source to distinguish a nameless drop from a deduped one, which status.json cannot express today; both shapes surface only as names.length !== dropped. That is a source-side change (e.g. an upstreams_dropped_unnamed count in the details published by hypaware-core/plugins-workspace/ai-gateway/src/source.js), not a wording fix.
3. registered_presets is snapshotted at status() time, the routing table at listener-launch time
The source publishes registered_presets as Array.from(state.presets.keys()) at status time (hypaware-core/plugins-workspace/ai-gateway/src/source.js:101), while the routing table was merged when the listener launched. A preset registered after source start would be reported covered while absent from the table.
Why non-blocking: unreachable with bundled plugins, all of which register presets in activate(), and the daemon starts sources only after every plugin activates. Theoretical skew, and not fixable from the status-reader side.
Backlink: PR #678 (triage note there records the full disposition). Origin: issue #676, itself deferred from PR #658.
Deferred, non-blocking residue from the two review rounds on PR #678 (fix for #676), triaged at head
b0a9e41730282b84ccb1480486ee0a4b4a062cc5. Every numbered finding from both rounds (round 1: 2 major + 1 minor; round 2: 3 major + 1 minor) is verified fixed at that head; these three were noted by the rounds as real but deliberately out of that PR's scope. None blocks merge.Note: PR #678 is stacked on PR #658 (base
fix/issue-653); the file:line references below are to that branch. Do not start this until #658 and #678 have both merged and #678 has been retargeted tomaster.1. Dropped upstream names are printed unsanitized and uncapped
src/core/daemon/status.jsprints the dropped names from the status file directly into the warning message (droppedUpstreamConsequence, lines 321, 339, 345, viastringListonly), whilerecentEntrypointsFromSources(lines 397-416) runs the same class of untrusted-file strings throughsanitizeLabeland caps them. Both read the same file another build may have written.Why non-blocking: pre-existing, it predates PR #678 entirely (the old parenthetical on the base branch printed the same list), and the exposure is display of a local file's content in local CLI output. Both review rounds deferred it as belonging to a separate change. Hardening, not a defect introduced or left by #678.
2. The hedged branch's "the same name" can have no printed antecedent
A nameless drop (an entry missing
name, an ordinary current-build config) reaches the!attributionbranch ofdroppedUpstreamConsequencewithnames.length === 0, so the message (src/core/daemon/status.js:329) says "unless an adapter preset already covers the same name" about a name the operator never sees, and the preset hedge is arguably vacuous there (an entry with no name cannot collide with a preset).Why non-blocking: the sentence is awkward, not false. Closing it needs the gateway source to distinguish a nameless drop from a deduped one, which
status.jsoncannot express today; both shapes surface only asnames.length !== dropped. That is a source-side change (e.g. anupstreams_dropped_unnamedcount in the details published byhypaware-core/plugins-workspace/ai-gateway/src/source.js), not a wording fix.3.
registered_presetsis snapshotted atstatus()time, the routing table at listener-launch timeThe source publishes
registered_presetsasArray.from(state.presets.keys())at status time (hypaware-core/plugins-workspace/ai-gateway/src/source.js:101), while the routing table was merged when the listener launched. A preset registered after source start would be reportedcoveredwhile absent from the table.Why non-blocking: unreachable with bundled plugins, all of which register presets in
activate(), and the daemon starts sources only after every plugin activates. Theoretical skew, and not fixable from the status-reader side.Backlink: PR #678 (triage note there records the full disposition). Origin: issue #676, itself deferred from PR #658.