Privacy skill liveness cross-check reads the same daemon snapshot it disambiguates

オープン
  • 何か問題がありますか？
#2,146 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
javascript, markdown
領域
devtools, security

調査の方向性

Read hypaware-core/plugins-workspace/claude/skills/hypaware-privacy/SKILL.md and hypaware-core/plugins-workspace/claude/src/telemetry/source.js, then inspect the both-recorders tests mentioned in the acceptance condition. The issue calls for a design decision: use an independent observation, publish listener liveness separately, or accept the single-snapshot design and startup window. Done means the chosen decision is reflected in the skill text and the tests pin it.

索引モデルが issue の本文から書いたものです。

説明

Source: #2132 at 5cb427211f376caa686298f4ec21a788af946523
Location: hypaware-core/plugins-workspace/claude/skills/hypaware-privacy/SKILL.md:46, hypaware-core/plugins-workspace/claude/src/telemetry/source.js:297-338
Severity: minor

Evidence

The verb's recorder resolution and the capture-health listener_started_at both come from one liveness-gated read of run/status.json, and the shipped listener co-emits control_routes and listener_started_at in one unconditional details literal, so no second genuinely independent observation exists. Issue #1626's acceptance is met at head 5cb42721 (verified: the daemon.error clause makes the live stop branch reachable, capability_too_old and dead-daemon shapes proceed, running:true-with-error stops), so what remains is design-level: a cross-check source outside status.json, or a listener publishable without its route. The only behavioral residual is a reasoned-about, never-reproduced startup window (daemon alive, status file not yet written: running true, no error, null field reads as 'not running').

Why deferral is safe

Both named remainders are design changes; CLAUDE.md says land the small fix and defer the rest. The residual window is strictly narrower than the pre-PR behavior this PR fixed, transient (the next hyp status after the daemon flushes its snapshot corrects it), requires the user to run the privacy review in the seconds between daemon start and its first status write, and was never observed, so it does not meet the defect bar. The fail direction during that window matches the capability_too_old handling #1626 explicitly requires, and the two shapes are indistinguishable within the current single-snapshot design.

Acceptance condition

A design decision that either gives Step 1's cross-check an observation not derived from run/status.json (or makes the listener's liveness publishable independently of its route advertisement) with the skill text and both-recorders tests updated to pin it, or explicitly accepts the single-snapshot design and its startup window.

Review preference; backlog only. A human may explicitly delegate it with neutral:fix.

主要言語
JavaScript
スター
11
フォーク
0
平均マージ
2時間 15分
マージ済み PR（30日）
322

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

hyparam/hypaware のほかの issue

hyparam/hypaware の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。