Summary
The performance harness records cpu_cores: 0 on Android/Termux when os.cpus() returns an empty array. computeEfficiency() then silently treats zero as four cores through hwProfile.cpu_cores || 4, creating metadata/scoring disagreement and invalid hardware normalization.
The 12-node diagnostic exhibition observed this on both Android participants (gongyung and daegyo). Their reports were retained only as diagnostics and excluded from ranking.
Current behavior
cpu_cores: os.cpus().length
cpu_model: os.cpus().length > 0 ? os.cpus()[0].model : 'unknown'
Later:
const cpuCores = hwProfile.cpu_cores || 4;
This makes the report say 0 while scoring as if the node had 4 cores. The fallback is neither observable nor defensible.
Expected behavior
- Hardware metadata and scoring use the same positive core count and record how it was derived.
- Termux/Android has a bounded, safe fallback chain.
- If no trustworthy positive value is available, the report is explicitly non-comparable; it does not invent four cores.
Implementation direction
Use an ordered capability probe with no network or privileged reads, for example:
os.availableParallelism() when available and positive.os.cpus().length when positive.- A bounded platform fallback such as
_NPROCESSORS_ONLN, /sys/devices/system/cpu/online, or a safe /proc/cpuinfo count.
- If all fail, set hardware-profile completeness false and block normalized scoring.
Record a safe enum such as cpu_core_source and retain cpu_model: unknown when unavailable. Do not record hostnames, device identifiers, serials, IPs, or raw /proc contents.
Acceptance criteria
Required tests
- Normal Linux
os.cpus() path.
- Empty
os.cpus() with successful availableParallelism().
- Termux-style fallback with a CPU-online range such as
0-7.
- Total probe failure, proving fail-closed comparability.
- Schema/packet bridge regression for the new source/completeness fields.
Verification
npm test
node scripts/perf-harness.js --iterations 3 --json --validate
node scripts/harness-to-packet.js results/ --agent-id termux-hardware-check
At least one real Termux canary should be run only after the source-only fixture suite is green and operator approval is obtained.
Safety boundary
Read-only local hardware probes. No device identifiers, ADB mutation, package installation, provider calls, service restarts, or public scoring.
Summary
The performance harness records
cpu_cores: 0on Android/Termux whenos.cpus()returns an empty array.computeEfficiency()then silently treats zero as four cores throughhwProfile.cpu_cores || 4, creating metadata/scoring disagreement and invalid hardware normalization.The 12-node diagnostic exhibition observed this on both Android participants (
gongyunganddaegyo). Their reports were retained only as diagnostics and excluded from ranking.Current behavior
Later:
This makes the report say
0while scoring as if the node had4cores. The fallback is neither observable nor defensible.Expected behavior
Implementation direction
Use an ordered capability probe with no network or privileged reads, for example:
os.availableParallelism()when available and positive.os.cpus().lengthwhen positive._NPROCESSORS_ONLN,/sys/devices/system/cpu/online, or a safe/proc/cpuinfocount.Record a safe enum such as
cpu_core_sourceand retaincpu_model: unknownwhen unavailable. Do not record hostnames, device identifiers, serials, IPs, or raw/proccontents.Acceptance criteria
cpu_coresis a positive integer for supported Linux and Android/Termux fixtures.computeEfficiency()never silently substitutes four cores for zero/missing metadata.unknownwithout invalidating a report when core count is trustworthy.Required tests
os.cpus()path.os.cpus()with successfulavailableParallelism().0-7.Verification
npm test node scripts/perf-harness.js --iterations 3 --json --validate node scripts/harness-to-packet.js results/ --agent-id termux-hardware-checkAt least one real Termux canary should be run only after the source-only fixture suite is green and operator approval is obtained.
Safety boundary
Read-only local hardware probes. No device identifiers, ADB mutation, package installation, provider calls, service restarts, or public scoring.