--- name: beamho-observer-sky-frontend description: Use when editing beamHO-bench observer-sky satellite rendering, composition, camera framing, display selection, continuity, or screen-space acceptance so frontend changes stay aligned with visual-acceptance rules instead of proxy metrics alone. --- # beamHO Observer-Sky Frontend Use this skill for `beamHO-bench/` when the task affects satellite display, observer-sky composition, god-view framing, display-set behavior, or frontend acceptance for `Synthetic Orbit`, `Starlink TLE`, and `OneWeb TLE`. ## Read First Read these first: 1. `AGENTS.md` 2. `PROJECT_CONSTRAINTS.md` 3. `docs/zh-TW/07-observer-sky-visual-acceptance.md` 4. `sdd/completed/beamHO-bench-implementation-status.md` 5. the current active pending frontend SDD 6. these frontend files: - `src/components/scene/MainScene.tsx` - `src/components/scene/SatelliteSkyLayer.tsx` - `src/components/scene/ObserverSkyCameraRig.tsx` - `src/viz/satellite/view-composition.ts` - `src/viz/satellite/observer-sky-projection.ts` - `src/viz/satellite/display-selection.ts` - `src/viz/satellite/display-continuity.ts` - `src/viz/satellite/display-adapter.ts` - `src/viz/satellite/display-pipeline.ts` - `src/viz/satellite/screen-space-acceptance.ts` ## Ownership Boundaries Keep these boundaries clear: 1. `src/sim/**` - physical/runtime truth - do not push frontend-only composition state back here 2. `src/viz/satellite/**` - projection, selection, continuity, composition, screen-space evaluation 3. `src/components/scene/**` - scene wiring, camera rig, accepted view-mode integration 4. `src/components/sim/**` - renderer-only display components Do not solve a frontend acceptance problem by hiding more state inside runtime contracts. ## Frontend Acceptance Rules The result must satisfy `docs/zh-TW/07-observer-sky-visual-acceptance.md`. In practice, that means: 1. satellites must read as `rise -> pass -> set` 2. `elevation < 0` stays hidden 3. `0 <= elevation < theta_min` stays ghost / non-serving 4. `elevation >= theta_min` reads as active 5. screen-space must not collapse into a center-top cluster 6. satellites must remain identifiable as continuous moving objects 7. display set must remain broader than HO candidate set when the physical pool allows it Do not mark complete if the screen still reads as: 1. a pack of points near the scene center swapping places 2. long pauses followed by abrupt relocation 3. candidate-limit-driven top-N truncation in the visible sky ## Preferred Change Surfaces Typical frontend fixes belong in: 1. `src/viz/satellite/view-composition.ts` 2. `src/viz/satellite/display-selection.ts` 3. `src/viz/satellite/display-continuity.ts` 4. `src/viz/satellite/display-adapter.ts` 5. `src/viz/satellite/display-pipeline.ts` 6. `src/viz/satellite/screen-space-acceptance.ts` 7. `src/components/scene/ObserverSkyCameraRig.tsx` 8. `src/components/scene/MainScene.tsx` 9. `src/components/scene/SatelliteSkyLayer.tsx` Do not reach for generic camera-distance tweaks first if the actual problem is display selection, composition policy, or continuity semantics. ## Validation For observer-sky frontend work, prefer this full set: 1. `npm run lint` 2. `npm run test:sim` 3. `npm run build` 4. `npm run validate:stage` Also check whether tests cover: 1. screen-space spread 2. pass readability 3. continuity readability 4. cross-mode consistency If those tests are missing for the change, add them instead of relying on manual claims alone. ## Closure Rule Frontend observer-sky work is not closure-ready until: 1. automated validation passes 2. manual acceptance is checked against `docs/zh-TW/07-observer-sky-visual-acceptance.md` 3. lifecycle docs are synced 4. the result is not justified only by proxy metrics such as: - sector diversity - determinism - retained-ID counts ## Reporting Always report: 1. which frontend layers changed 2. whether camera/composition or display-set policy changed 3. what automated validation ran 4. whether manual visual acceptance was actually checked 5. what still fails if the screen is not yet acceptable