Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.aiox-core/core/orchestration/fast-path-gate.js:
- Line 215: The current calculation for batchSize uses the || operator which
treats a valid task.itemCount of 0 as missing; change the expression that
computes batchSize to use the nullish coalescing operator so that task.itemCount
is used when explicitly set (including 0) and only falls back to
Math.max(task.files.length, structuredFileCount) when itemCount is null or
undefined; update the expression referencing batchSize, task.itemCount,
task.files, and structuredFileCount accordingly.
- Around line 83-101: normalizeConfig currently accepts out-of-range values
(e.g., minConfidence > 1 or < 0, minBatchItems < 1) and can silently break
routing; update normalizeConfig (used by evaluateFastPath) to validate and clamp
inputs to safe ranges: clamp minConfidence to [0,1], enforce minBatchItems to a
positive integer >= 1 (coerce/round if necessary), and ensure
externalExecutorThreshold is non-negative (or within any documented max); apply
same validation for both camelCase and snake_case keys
(minConfidence/min_confidence, minBatchItems/min_batch_items,
externalExecutorThreshold/external_executor_threshold) and fall back to
DEFAULT_FAST_PATH_CONFIG only after clamping/validation.

In `@tests/config/schema-validation.test.js`:
- Around line 122-124: Add an assertion to the test that checks the default
value for external_executor_threshold so config/schema drift is detected;
specifically, in the same test block that asserts
frameworkConfig.dev.fast_path.enabled, .min_confidence, and .min_batch_items,
add an expectation for frameworkConfig.dev.fast_path.external_executor_threshold
to equal the intended default (e.g., the numeric default your config defines) so
the test fails if that default changes unexpectedly.

---

Nitpick comments:
In @.aiox-core/core/orchestration/index.js:
- Line 26: Replace the relative require for the fast-path gate with an absolute
import per repo rules: find the require call using the symbol fastPathGate
(require('./fast-path-gate')) and change it to use the package/root-absolute
path that maps to the same module (e.g.,
require('core/orchestration/fast-path-gate') or the project's configured
absolute alias) so the import is absolute rather than relative.

In `@tests/core/orchestration/fast-path-gate.test.js`:
- Around line 7-8: Replace the deep relative requires for the fast-path-gate
import and the orchestration import with the project’s absolute import alias;
locate the two require statements that import from
'../../../.aiox-core/core/orchestration/fast-path-gate' and
'../../../.aiox-core/core/orchestration' and change them to use the configured
absolute module specifier (for example
'@aiox-core/core/orchestration/fast-path-gate' and
'@aiox-core/core/orchestration' or the project's equivalent alias) so the test
follows the absolute import convention.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.aiox-core/core/orchestration/fast-path-gate.js:
- Around line 10-53: STRUCTURED_FILE_EXTENSIONS and AUTOMATION_PATTERNS are
exported as mutable structures; change to internal frozen constants and expose
defensive copies/read-only accessors: keep an internal frozen Set
(STRUCTURED_FILE_EXTENSIONS_FROZEN) and a frozen array of frozen pattern objects
(AUTOMATION_PATTERNS_FROZEN using Object.freeze on each pattern object), then
replace direct exports with functions like getStructuredFileExtensions() that
return new Set(STRUCTURED_FILE_EXTENSIONS_FROZEN) or an array-copy of
AUTOMATION_PATTERNS_FROZEN (e.g., return AUTOMATION_PATTERNS_FROZEN.map(p => ({
id: p.id, weight: p.weight, pattern: p.pattern }))) so consumers cannot mutate
core singleton state; update any references to use the new accessors
(STRUCTURED_FILE_EXTENSIONS -> getStructuredFileExtensions, AUTOMATION_PATTERNS
-> getAutomationPatterns).
- Around line 99-113: The boolean flags are currently taking any truthy value
(e.g., the string "false") which can flip behavior; update normalization so the
returned enabled and the external-executor boolean flag are derived only from
explicit booleans or parsed boolean strings and otherwise fall back to the
DEFAULT_FAST_PATH_CONFIG defaults. Concretely, change how the returned enabled
property is computed (symbol: enabled) to: if typeof config.enabled ===
'boolean' use it, else if typeof config.enabled === 'string' accept only
'true'/'false' (map to true/false), otherwise use
DEFAULT_FAST_PATH_CONFIG.minEnabled/default; apply the same explicit
normalization pattern to the external executor boolean config (the boolean flag
used near externalExecutorThreshold) so string values don't become truthy and
the default from DEFAULT_FAST_PATH_CONFIG is used when the input is not a clear
boolean. Ensure you reference and update the same config keys used in the file
(config.enabled and the external executor boolean key adjacent to
externalExecutorThreshold) and keep minConfidence/minBatchItems handling
unchanged.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.aiox-core/development/tasks/fast-path-gate.md:
- Around line 3-14: Add a new "Elicitation" section into fast-path-gate.md
(placed after Purpose and before Inputs) that inserts two explicit checkpoints:
"Before mode selection" and "Before external delegation", each listing required
confirmation questions such as: clarify ambiguous `description` details,
validate `files` list and `itemCount`, confirm `acceptanceCriteria`, and
explicitly request user permission to use `externalExecutorsEnabled` (and any
needed delegation constraints); ensure the section clearly marks that both
checkpoints must be answered before proceeding to mode selection or invoking
external delegation.
- Around line 17-23: Add a pre-evaluation elicitation step before calling
evaluateFastPath(): prompt/record confirmations for scope validation, intended
files, security/production risk, and any sandbox constraints. Surround the
evaluateFastPath() call with explicit error handling: if it throws, returns
invalid output, or an unknown mode, set mode to "standard", record the error and
decision in evidence/logs, and continue the normal workflow. For external
executor runs (aiox-delegate), add timeout and retry/failure handling that
records the executor error, falls back to "standard" mode, and resumes
validation; ensure failures are surfaced in the targeted validation step.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In @.aiox-core/core/orchestration/index.js:
- Line 26: Replace the relative require('./fast-path-gate') with the project's
absolute import for that module so it follows the repo's absolute-import
convention; keep the variable name fastPathGate and the exported module usage
unchanged (i.e., update the require call for fastPathGate to the same absolute
module path pattern used by other imports in the project).