hyp status renders 'reports ready:' beside text saying Pi live capture is refused
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 38/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- javascript
- Domain
- observability
Research direction
Start with hypaware-core/plugins-workspace/pi/src/listener.js at line 127 and trace how status() chooses the state and sets lastError after repeated unsupported batches. Check the accepted SOURCE_HEALTH_STATES values and the consumers of status.json before proposing a representation change. Done means the status no longer renders “ready” while reporting that live capture is refused, without breaking native session recovery.
Written by the indexing model from the issue text.
Description
Source: #2019 at 630a6b2a42d46f26ef87e1f9ed0e8621cdcf1ea7
Location: hypaware-core/plugins-workspace/pi/src/listener.js:127
Severity: nit
Evidence
Re-verified at 630a6b2a: after 4 consecutive version-1 batches, status() returns state 'ready' with lastError 'pi_unsupported_batch - the attached Pi extension keeps sending an unsupported batch version; live capture is refused, native session recovery still applies', so the rendered line says ready while the text says refused.
Why deferral is safe
Representation choice, not incorrect data: state 'ready' plus lastError is the same degraded-but-live shape the Cursor listener already uses, reused deliberately per the PR body, and native recovery does still apply. Moving this source to 'degraded' changes what every reader of status.json sees and is beyond the acceptance condition of issue #2015.
Acceptance condition
If a maintainer wants it, report an accepted SOURCE_HEALTH_STATES word such as 'degraded' while the skew report is active, with the status.json consumers checked.
Review preference; backlog only. A human may explicitly delegate it with neutral:fix.
- Dominant language
- JavaScript
- Stars
- 11
- Forks
- 0
- Avg merge
- 2h 55m
- Merged PRs (30d)
- 294
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hyparam/hypaware
-
neutral:fix
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
report_commands.js runtime output still says 'server' in four places; one names the destinationOpen
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 76/100
Maintainers usually reply within 1 day
All issues in hyparam/hypaware
Similar issues
-
needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
microsoft/playwright#43875 · 1 comment ·
Maintainers usually reply within 1 day
-
Run the dependency drift checkPossibly taken @spaceninja claimed this today. Open
Difficulty 1/5 Under an hour Newbie friendliness 82/100
cloudfour/stylelint-config-cloudfour#683 ·
Maintainers usually reply within 1 day
-
Documentation Enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
JSPrismarine/JSPrismarine#2706 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
PostHog/posthog-js#5524 ·
Maintainers usually reply within 2 days
-
enhancement good first issue help wanted
Difficulty 2/5 Half a day Newbie friendliness 66/100
AlphaaCode/Popbook#10 ·