CodeVetter · Repo Unpack · Contributor handoff
microsoft/rushstack
Begin at the owning package and follow its manifest, rig, source entrypoint, and relevant tests before widening scope. Shared Rush graph and daemon changes require attention to native execution, retained processes, ownership, and cancellation. Generated files and copied frontend/backend contracts introduce edit-order and build-order traps. Tests and CI were inspected, not executed; recommendations below identify existing checks for a separately authorized execution task.
- Use existing Heft build/test phase scripts for package validation and repository test/retest commands for broader integration when execution is authorized; this investigation inspected those scripts and CI without running them.
- Read rush.json before choosing tool versions or workspace layout: Rush and PNPM are pinned, Node ranges are constrained, and project folders must have depth two.
- For Rush lifecycle changes, read phased-commands.md together with PhasedScriptAction; operation creation precedes graph hooks, and watch sessions reuse graph objects rather than recreating operations each iteration.
- For API output changes, account for local versus production semantics: local builds can rewrite expected reports and tolerate warnings, while production warnings fail extraction; missing expected-report folders receive special handling.
- Edit Documenter’s generators and plugin callbacks rather than generated Markdown pages; emitted pages carry a generated-file notice, and every generation empties the configured output directory.
- For Explorer contract changes, read the web package alongside the backend: build/lfx-shared and dist are populated by copying frontend-package outputs, and TypeScript compilation depends on the shared-code copy task.
- Daemon dogfooding guidance requires a stable extracted client closure instead of mutable workspace outputs; preserve native fallback/routing behavior and consult descriptor-boundary tests when altering retained child reuse.
- Treat rushd-review-map.md as historical review context: it names an earlier frozen snapshot and explicitly requires additional review for later fixes, so it does not certify the inspected commit or bound its current risk.