feat(mcp): add the idea-intake bridge and loopover_intake_idea tool

[luciferlive112116]

Summary

Implements #4798 — a submission surface a renter can actually use to turn a freeform idea into a strict, claimable task-graph conforming to the #4779 schema, scored against the same feasibility gate the loop already runs on (buildFeasibilityVerdict).

• new packages/loopover-engine/src/idea-intake.ts (pure — no IO, no AI): validateIdeaSubmission (bounds/owner/name/public-safe checks, all failures surfaced at once), buildTaskGraph (assembles constituent issues with inferred type labels — never gittensor:priority — folded acceptance criteria, and per-issue feasibility), and scoreTaskGraph. The graph verdict is the least-favorable across issues (avoid > raise > go, inherited unchanged from the gate), and an issue carrying a dependsOn is held (raise) until its prerequisite lands (spec §2 rule 5). The idea → constituent-issue decomposition is the one fuzzy step and is passed in, so the bridge itself stays deterministic and testable. Re-exported from the engine barrel; src/idea-intake.ts is a thin re-export shim (relative-source import, matching src/signals/slop.ts).
• new loopover_intake_idea MCP tool (src/mcp/server.ts): validates a submission and returns the scored task-graph, or an actionable error list for a malformed/empty submission — pure and source-free, mirroring loopover_check_slop_risk.

Acceptance (spec §4 + #4798): Example A (simple idea → one issue → go) and Example B (multi-step → dependency chain → raise) both produce their expected task-graphs, and a malformed/empty submission returns a clear, actionable error rather than a silent failure — tested at the engine level and end-to-end through the MCP tool.

Closes #4798

Scope

• Conventional Commit title (feat(mcp): …).
• Focused: one coherent feature (the idea-intake bridge + its tool surface).
• Follows CONTRIBUTING.md; no site//CNAME/VitePress.
• Linked open issue: Closes #4798.

Validation

• git diff --check
• npm run typecheck (clean)
• npm --workspace @loopover/engine run build and npm run build:mcp (the new engine module + shim + MCP tool compile; cross-package resolution via the relative-source shim)
• npm run test:coverage on the changed code: packages/loopover-engine/src/idea-intake.ts is 100% lines & branches (82/82); the new src/mcp/server.ts handler + schema + registration are fully covered (statements and both branch sides).
• MCP tool-invariant suites pass with the new tool: mcp-output-schemas ("outputSchema on EVERY tool" + "every newly-schematized tool returns schema-valid structured content"), mcp-cli-tools, mcp-tool-rename-aliases, miner-mcp-tool-docs-parity — 56 tests.
• New behavior has unit + end-to-end (MCP) tests for the worked examples, schema validation, and the malformed-input path.

If any required check was skipped, explain why:

• The full test:ci was not run end-to-end locally (several shell/self-host steps are Linux-only on this Windows box); the change-relevant gates above were validated directly.

Safety

• No secrets, wallet/hotkey/coldkey, trust scores, rewards, private rankings, or private maintainer evidence. The bridge is metadata-only and the tool is source-free; renter text is length-bounded and the tool never mints gittensor:priority.
• Public output stays sanitized (no scoring/reward/trust language in the tool payload).
• No auth/cookie/CORS/GitHub App/session changes (the tool is a pure function over caller-supplied data, mirroring loopover_check_slop_risk).
• MCP behavior is added and tested (output schema + schema-valid structured content).
• No UI changes.
• No changelog edit.

[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 95.08%. Comparing base (f3d1add) to head (b332e13).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5792   +/-   ##
=======================================
  Coverage   95.07%   95.08%           
=======================================
  Files         581      582    +1     
  Lines       46178    46245   +67     
  Branches    14809    14838   +29     
=======================================
+ Hits        43906    43973   +67     
  Misses       1516     1516           
  Partials      756      756           

Flag	Coverage Δ
shard-1	43.90% <11.94%> (-0.05%)	⬇️
shard-2	35.86% <89.55%> (+0.10%)	⬆️
shard-3	32.23% <11.94%> (-0.03%)	⬇️
shard-4	33.58% <11.94%> (+0.58%)	⬆️
shard-5	31.17% <11.94%> (-0.61%)	⬇️
shard-6	44.66% <77.61%> (+0.04%)	⬆️

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

Files with missing lines	Coverage Δ
packages/loopover-engine/src/idea-intake.ts	100.00% <100.00%> (ø)
src/mcp/server.ts	95.79% <100.00%> (+0.04%)	⬆️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Tip

🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-14 16:40:47 UTC}

6 files · 1 AI reviewer · no blockers · readiness 100/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This PR adds a pure idea-intake bridge (`validateIdeaSubmission`, `buildTaskGraph`, `scoreTaskGraph`) in `packages/loopover-engine/src/idea-intake.ts`, wires it through the engine barrel and a thin `src/idea-intake.ts` re-export shim (matching the `src/signals/slop.ts` convention), and exposes it as a new `loopover_intake_idea` MCP tool. The core logic — least-favorable graph verdict, dependency holding via `raise`, `gittensor:priority` exclusion, and per-issue feasibility defaults — matches the linked spec (#4779) and is exercised by both engine-level and MCP-level tests covering Example A/B and malformed-submission paths. Two spec-vs-implementation gaps are worth a look: `buildTaskGraph` does not topologically sort or validate `dependsOn` keys against issues actually present in the graph, and the `targetRepo` check only validates `owner/name` format, not the 'installed, registered repo' requirement the spec text (and the code's own comment) implies.

Nits — 5 non-blocking

• packages/loopover-engine/src/idea-intake.ts:242-243 (buildTaskGraph): no topological reordering or validation of dependsOn keys — a decomposition array supplied out of order, or referencing a key not present in the graph, is silently accepted and scored issue-by-issue without regard to actual graph structure, contrary to spec §2's 'topologically ordered by dependsOn.'
• packages/loopover-engine/src/idea-intake.ts:96-98: the comment claims 'an uninstallable/malformed repo is rejected at intake' but the regex only checks `owner/name` format, not actual installation/registration — consider softening the comment or noting that installation-check is deliberately out of scope for this pure module.
• src/mcp/server.ts: decomposition draft `title`/`body` fields accepted by the zod schema have no length bound (unlike the top-level idea fields), so a caller could pass an arbitrarily large per-issue title/body that only fails later inside acceptanceCriteria generation, not at the schema boundary.
• idea-intake.ts has no cycle-detection or self-dependency guard (e.g. `dependsOn: ['issue-1']` on issue-1 itself) — low risk given decomposition is renter-reviewed input, but worth a one-line comment on the assumption.
• Consider a small topological-sort or at-least dependsOn-key-existence check in buildTaskGraph, since the MCP tool now takes decomposition directly from an external caller rather than only from a trusted internal source.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#4798
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low 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: 91 registered-repo PR(s), 37 merged, 39 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	luciferlive112116; Gittensor profile; 91 PR(s), 39 issue(s).
Gate result	✅ Passing	No configured blocker found.
Improvement	✅ Minor	risk: clean · value: minor — Code changes are accompanied by test evidence. LLM value judgment: significant — This lands a complete, spec-conformant, well-tested new capability (deterministic idea→task-graph translation reusing the existing feasibility gate) that closes the linked issue #4798 and unblocks the freeform-scoring work described as depending on it (#5671).

Linked issue satisfaction

Addressed
The PR implements both a pure engine module and an MCP tool (loopover_intake_idea) that validate a freeform idea submission, build/score a task-graph against the feasibility gate, and include tests covering a trivial idea (go), a multi-step dependency idea (raise), and malformed/empty input returning an actionable error list — matching the issue's proposal, acceptance criteria, and test scenarios.

Review context

• Author: luciferlive112116
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, JavaScript, MDX, Rust, TypeScript
• Official Gittensor activity: 91 PR(s), 39 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

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.

[BETA] Chat with Gittensory

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

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

Full command reference: https://gittensory.aethereal.dev/docs/gittensory-commands

_{🟩 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]

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