fix(miner): reject blank acceptance hints as an objective success signal (#6766)

[shin-core]

Summary

idea-feasibility.js's deriveIdeaIssueStatus computed objectiveSignals from acceptanceHints?.length — array length only, never content. So { acceptanceHints: [" "] } sailed through as issueStatus: "ready", directly contradicting the module's own stated contract: "An idea with no objective success signal is invalid... and is rejected before compute."

• deriveIdeaIssueStatus now counts only non-blank (trimmed, non-empty string) hints toward objectiveSignals — a slot is not a signal.
• idea-feasibility-cli.js's --hint parsing now rejects a whitespace-only value with the same "--hint requires a value." error a missing value already gets.
• No other behavior change: a real hint (alone, or alongside blank ones) still yields "ready", and the missing/absent-hints paths are untouched.

Closes #6766

Test plan

• REGRESSION: acceptanceHints: [" "] and ["", "\t", "\n "] now return "invalid".
• A real hint alongside blank ones still returns "ready" (no over-rejection).
• REGRESSION: --hint " " / "\t" / " \n " return the --hint requires a value. parse error; the existing missing-value and flag-like-value rejections still pass.
• npm run typecheck clean.
• Coverage on both changed files: 100% statements (52/52), 100% branches (35/35) — 29 tests green.

[superagent-security]

🚨 Contributor flagged. Click here for more info: Superagent Dashboard

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.63%. Comparing base (e2cbbec) to head (fd730f1).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6848   +/-   ##
=======================================
  Coverage   93.63%   93.63%           
=======================================
  Files         683      683           
  Lines       68163    68164    +1     
  Branches    18706    18706           
=======================================
+ Hits        63827    63828    +1     
  Misses       3350     3350           
  Partials      986      986           

Flag	Coverage Δ
shard-1	43.63% <0.00%> (-0.06%)	⬇️
shard-2	36.86% <0.00%> (+0.12%)	⬆️
shard-3	32.59% <0.00%> (-0.18%)	⬇️
shard-4	34.46% <66.66%> (-0.35%)	⬇️
shard-5	31.33% <100.00%> (-0.46%)	⬇️
shard-6	46.04% <0.00%> (+0.58%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...ackages/loopover-miner/lib/idea-feasibility-cli.js	100.00% <100.00%> (ø)
packages/loopover-miner/lib/idea-feasibility.js	100.00% <100.00%> (ø)

[loopover-orb]

Warning

⏸️ LoopOver review result - manual review recommended

_{Review updated: 2026-07-17 08:25:15 UTC}

4 files · 1 AI reviewer · no blockers · CI green · unstable

⏸️ Suggested Action - Manual Review

Review summary
This is a narrow, well-targeted fix: `deriveIdeaIssueStatus` now counts only non-blank trimmed hints as objective signals, and the CLI's `--hint` parsing rejects whitespace-only values with the same error as a missing value, closing the gap where `{acceptanceHints: [" "]}` incorrectly produced `issueStatus: "ready"`. Both changes are correctly traced to the root cause (the counting logic itself, not a downstream symptom), and the accompanying tests exercise the real functions with the real blank-string inputs described in the bug, not fabricated states. The fix closes linked issue #6766 and includes no unrelated scope.

Nits — 3 non-blocking

• idea-feasibility.js:41 the filter only guards `typeof hint === "string"`; if the schema truly guarantees string-only hints (per the JSDoc `readonly string[]`) this check is unreachable defensive code — worth confirming schema validation upstream to avoid dead branches, though harmless as written.
• idea-feasibility-cli.js:36 could use a small named helper like `isBlank(value)` shared between the two files if this exact whitespace-check logic proliferates further, purely a DRY consideration.
• Consider whether trimming/blank-checking should also apply to any other free-text fields on the idea intake shape for consistency, if such fields exist elsewhere in idea-feasibility.js.

Flagged checks (non-blocking)

• Contributor trust — Contributor flagged for review

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#6766
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	❌ 8/20	High review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 44 registered-repo PR(s), 25 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	shin-core; Gittensor profile; 44 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor

Review context

• Author: shin-core
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: TypeScript, JavaScript, Solidity, Dart, Python, CSS, PHP, Rust
• Official Gittensor activity: 44 PR(s), 0 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Start here: Add a concise scope and risk note.
• Then work through the remaining 1 step in the Signals table above.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.