feat(miner): add manage-phase status CLI command

[james3773]

Summary

• Add a read-only gittensory-miner manage status command that aggregates managed PR rows from the local portfolio queue and event ledger.
• Introduce manage_pr_update event vocabulary plus table/JSON renderers for CI state, gate verdict, outcome, and last-polled timestamp.
• Cover empty portfolio, mixed portfolio/event snapshots, --json output shape, and bin entrypoint wiring in unit tests.

Closes #2325.

Scope

• The PR title follows type(scope): short summary Conventional Commit format.
• This PR is focused on manage-phase status rendering and does not mix unrelated UI/deploy changes.
• This follows CONTRIBUTING.md.
• Linked issue: feat(miner-manage): local manage-phase CLI status command #2325.

Validation

• npm run test:ci locally — Node.js is not installed on the contributor machine; CI will run the full gate on push.
• New behavior has unit tests for empty portfolio, mixed state, JSON output, and CLI help/status wiring.

Safety

• No secrets, wallet details, hotkeys, or private scoring output in code or PR text.
• Read-only command: SELECT/list only, no GitHub writes, no uploads.

UI Evidence

Not applicable — miner CLI package only.

Notes

• Portfolio PR identifiers use the pr:<number> convention; manage rows merge latest manage_pr_update payloads from the append-only event ledger.
• Top-level gittensory-miner status is reserved for the foundation laptop-mode command (feat(miner-foundation): slim laptop-mode CLI entry point (status/doctor commands) #2288); manage-phase portfolio rendering lives at manage status.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.01%. Comparing base (cea0943) to head (6838abc).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2871   +/-   ##
=======================================
  Coverage   96.01%   96.01%           
=======================================
  Files         259      259           
  Lines       28304    28304           
  Branches    10291    10291           
=======================================
  Hits        27177    27177           
  Misses        491      491           
  Partials      636      636           

🚀 New features to boost your workflow:

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

[loopover-orb]

Caution

🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

🛑 Gittensory review result - reject/close recommended

_{Review updated: 2026-07-04 02:44:54 UTC}

8 files · 1 AI reviewer · 1 blocker · readiness 80/100 · CI green · unstable

🛑 Suggested Action - Reject/Close

• AI reviewers agree on a likely critical defect: packages/gittensory-miner/bin/gittensory-miner.js:31 starts `startUpdateCheck(...)` before the `manage status` dispatch at packages/gittensory-miner/bin/gittensory-miner.js:68, so `gittensory-miner manage status` can perform an npm-registry lookup despite the new command being documented as local/offline/read-only
• move the manage-status dispatch above `startUpdateCheck`, matching the existing `status`/`doctor` pattern. — Resolve the flagged defect, or override if the AI reviewers are mistaken, then re-run the gate.

Review summary
The change adds a focused `gittensory-miner manage status` read path that builds rows from active `pr:<number>` portfolio entries and overlays matching `manage_pr_update` ledger events. The aggregation and renderers are small and covered for empty, mixed, JSON, and bin-entrypoint cases, but the bin wiring violates the command’s documented offline/read-only contract by starting the opportunistic npm update check before dispatching `manage status`. That makes the new command capable of network I/O on the default path, unlike `status` and `doctor`.

Blockers

• packages/gittensory-miner/bin/gittensory-miner.js:31 starts `startUpdateCheck(...)` before the `manage status` dispatch at packages/gittensory-miner/bin/gittensory-miner.js:68, so `gittensory-miner manage status` can perform an npm-registry lookup despite the new command being documented as local/offline/read-only; move the manage-status dispatch above `startUpdateCheck`, matching the existing `status`/`doctor` pattern.

Nits — 5 non-blocking

• nit: packages/gittensory-miner/lib/manage-status.js:57 initializes `ciState` with `item.status === "in_progress" ? "unknown" : "unknown"`, which is a dead conditional and should be collapsed or changed to reflect a real queued/in-progress distinction.
• nit: packages/gittensory-miner/lib/manage-status.js:63 relies on `readEvents()` iteration order for “latest” event wins; either document that ordering contract here or sort by ledger-created/id metadata before merging.
• packages/gittensory-miner/bin/gittensory-miner.js: handle `manage status` before creating `updateCheck`, the same way `status` and `doctor` are handled, so the command cannot reach the registry path.
• packages/gittensory-miner/lib/manage-status.js: replace the redundant `ciState` ternary with a single `"unknown"` default unless there is a meaningful status-derived value to show.
• test/unit/miner-manage-status.test.ts: add a bin-entrypoint test that runs `manage status` without `--no-update-check` against a delayed registry fixture and asserts no registry call/nudge occurs, mirroring the offline contract tests for local commands.

Why this is blocked

• packages/gittensory-miner/bin/gittensory-miner.js:31 starts `startUpdateCheck(...)` before the `manage status` dispatch at packages/gittensory-miner/bin/gittensory-miner.js:68, so `gittensory-miner manage status` can perform an npm-registry lookup despite the new command being documented as local/offline/read-only; move the manage-status dispatch above `startUpdateCheck`, matching the existing `status`/`doctor` pattern.

Signal	Result	Evidence
Code review	❌ 1 blocker	1 reviewer
Linked issue	✅ Linked	#2325
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	❌ 5/25	Preflight is holding this PR: the review lane is unavailable, so it is not ready for automated review.
Contributor workload	✅ 10/10	Author activity: 892 registered-repo PR(s), 642 merged, 28 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	jony376; Gittensor profile; 892 PR(s), 28 issue(s).
Gate result	❌ Blocking	Repo-configured hard blocker found.

Review context

• Author: jony376
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository registration is not available in the local Gittensory cache.
• Public profile languages: not available
• Official Gittensor activity: 892 PR(s), 28 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Await review-lane availability.
• Refresh registry data or choose a registered active repo.

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.

_{🟩 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 Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[loopover-orb]

Gittensory is closing this pull request on the maintainer's behalf (AI reviewers agree on a likely critical defect: packages/gittensory-miner/bin/gittensory-miner.js:31 starts `startUpdateCheck(...)` before the `manage status` dispatch at packages/gittensory-miner/bin/gittensory-miner.js:68, so `gittensory-miner manage status` can perform an npm-registry lookup despite the new command being documented as local/offline/read-only; move the manage-status dispatch above `startUpdateCheck`, matching the existing `status`/`doctor` pattern.). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs are re-reviewed automatically, so an inaccurate close may be reopened, but that does not guarantee it can merge (e.g. if conflicts or failing CI remain).