projscan 4.9.1 → 4.9.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +208 -1358
- package/dist/analyzers/deadCodeCheck.js +93 -0
- package/dist/analyzers/deadCodeCheck.js.map +1 -1
- package/dist/analyzers/unusedDependencyCheck.js +10 -10
- package/dist/analyzers/unusedDependencyCheck.js.map +1 -1
- package/dist/cli/commands/feedback.js +47 -1
- package/dist/cli/commands/feedback.js.map +1 -1
- package/dist/core/evidenceComment.d.ts +2 -1
- package/dist/core/evidenceComment.js +45 -7
- package/dist/core/evidenceComment.js.map +1 -1
- package/dist/core/feedback.d.ts +2 -1
- package/dist/core/feedback.js +186 -0
- package/dist/core/feedback.js.map +1 -1
- package/dist/core/importGraph.d.ts +2 -0
- package/dist/core/importGraph.js +14 -5
- package/dist/core/importGraph.js.map +1 -1
- package/dist/core/languages/LanguageAdapter.d.ts +2 -0
- package/dist/core/languages/javascriptAdapter.js +7 -28
- package/dist/core/languages/javascriptAdapter.js.map +1 -1
- package/dist/core/languages/javascriptProjectConfig.d.ts +20 -0
- package/dist/core/languages/javascriptProjectConfig.js +479 -0
- package/dist/core/languages/javascriptProjectConfig.js.map +1 -0
- package/dist/core/preflightCautionBudget.d.ts +2 -0
- package/dist/core/preflightCautionBudget.js +85 -0
- package/dist/core/preflightCautionBudget.js.map +1 -0
- package/dist/core/preflightInputs.d.ts +30 -2
- package/dist/core/preflightInputs.js +39 -12
- package/dist/core/preflightInputs.js.map +1 -1
- package/dist/core/preflightReport.js +3 -0
- package/dist/core/preflightReport.js.map +1 -1
- package/dist/core/releaseEvidence.d.ts +2 -2
- package/dist/core/releaseEvidence.js +3 -2
- package/dist/core/releaseEvidence.js.map +1 -1
- package/dist/core/understand.js +20 -22
- package/dist/core/understand.js.map +1 -1
- package/dist/core/workplan.js +1 -1
- package/dist/core/workplan.js.map +1 -1
- package/dist/mcp/tools/workspaceGraph.js +12 -9
- package/dist/mcp/tools/workspaceGraph.js.map +1 -1
- package/dist/projscan-sbom.cdx.json +6 -6
- package/dist/publicAgent.d.ts +1 -1
- package/dist/publicAgent.js +1 -1
- package/dist/publicAgent.js.map +1 -1
- package/dist/tool-manifest.json +2 -2
- package/dist/types/dogfood.d.ts +17 -0
- package/dist/types/evidencePack.d.ts +8 -0
- package/dist/types/preflight.d.ts +18 -0
- package/dist/utils/formatSupport.d.ts +1 -0
- package/dist/utils/formatSupport.js +1 -0
- package/dist/utils/formatSupport.js.map +1 -1
- package/docs/demos/projscan-4-1-demo.html +8 -8
- package/docs/demos/projscan-mission-control.tape +2 -2
- package/docs/demos/projscan-mission-proof.tape +9 -5
- package/docs/projscan-mission-control.gif +0 -0
- package/docs/projscan-mission-control.png +0 -0
- package/docs/projscan-mission-proof.gif +0 -0
- package/docs/projscan-proof-router.png +0 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -5,281 +5,47 @@
|
|
|
5
5
|
[](https://www.npmjs.com/package/projscan)
|
|
6
6
|
[](https://github.com/abhiyoheswaran1/projscan/blob/main/LICENSE)
|
|
7
7
|
[](https://nodejs.org)
|
|
8
|
-
[](#
|
|
8
|
+
[](#install)
|
|
9
9
|
|
|
10
|
-
**Local proof for AI-assisted engineering
|
|
10
|
+
**Local proof for AI-assisted engineering.** projscan gives agents and engineers the repo context, risk checks, proof commands, and review gates they need before editing, handing off, or preparing a release candidate.
|
|
11
11
|
|
|
12
|
-
[
|
|
12
|
+
[Install](#install) · [Daily workflows](#daily-workflows) · [MCP Setup](#mcp-setup) · [Commands](#command-map) · [Trust](#trust-model) · [Full Guide](docs/GUIDE.md)
|
|
13
13
|
|
|
14
|
-
<img src="docs/projscan-mission-control.png" alt="projscan Mission Control routing a
|
|
14
|
+
<img src="docs/projscan-mission-control.png" alt="projscan Mission Control routing a saved mission into proof status, remaining work, outcome commands, and review gates" width="760">
|
|
15
15
|
|
|
16
16
|
</div>
|
|
17
17
|
|
|
18
18
|
---
|
|
19
19
|
|
|
20
|
-
##
|
|
20
|
+
## Use It For
|
|
21
21
|
|
|
22
|
-
|
|
22
|
+
Use projscan when an agent asks one of these questions:
|
|
23
23
|
|
|
24
|
-
|
|
24
|
+
- Which files should I read before changing this feature?
|
|
25
|
+
- Which proof commands should I run before handoff?
|
|
26
|
+
- Which risks need fixes, reviewer attention, or release sign-off?
|
|
25
27
|
|
|
26
|
-
|
|
28
|
+
projscan runs core scans on your machine. It respects `.gitignore`, keeps `.env` values out of scans unless you opt in, and exposes the same evidence through a CLI and a 45-tool MCP server. The language layer uses 11 AST adapters covering 12 named languages.
|
|
27
29
|
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
The local plugin platform lets teams add project-specific findings and render `doctor`, `analyze`, and `ci` in their own voice without changing the scan pipeline. Humans get the same information through the CLI.
|
|
31
|
-
|
|
32
|
-
**Core scans run locally by default. No source upload. No projscan account or API key. `.gitignore` is respected by default. `.env` values are path-only unless explicitly enabled. Anonymous product telemetry is off by default and only runs after explicit opt-in. Network-capable paths are explicit: `audit`, registry checks, opt-in telemetry, and optional semantic model downloads.**
|
|
33
|
-
|
|
34
|
-
```bash
|
|
35
|
-
npx projscan
|
|
36
|
-
```
|
|
37
|
-
|
|
38
|
-
<img src="docs/projscan-mission-control.gif" alt="projscan Mission Control turning a plain-language goal into shortcut commands, proof commands, and review gates" width="760">
|
|
39
|
-
|
|
40
|
-
## What's New in 4.9.1
|
|
41
|
-
|
|
42
|
-
4.9.1 turns the post-4.8 release-prep loop into daily workflow proof hardening:
|
|
43
|
-
clearer Start output, quieter release-candidate proof, visible offline privacy
|
|
44
|
-
checks, refreshed README media, and CI aligned with the current test toolchain.
|
|
45
|
-
|
|
46
|
-
- **SvelteKit dataflow coverage.** `RequestEvent` handlers and hooks now
|
|
47
|
-
classify request body readers, headers, URL, params, and cookies through
|
|
48
|
-
framework-gated source patterns.
|
|
49
|
-
- **No-release continuation routing.** Autonomous improvement prompts now route
|
|
50
|
-
to bounded workplans while release, publish, deploy, push, merge, and
|
|
51
|
-
version-bump actions stay blocked unless a release task is active.
|
|
52
|
-
- **Scoped evidence prompts.** Shareable redacted evidence requests can infer
|
|
53
|
-
top-level directory scopes such as `tests` and produce concrete local
|
|
54
|
-
analyze/doctor/CI commands.
|
|
55
|
-
- **Coordination handoffs.** Agent briefs now carry clearer merge-order hints
|
|
56
|
-
and preflight coordination proof paths for parallel-agent work.
|
|
57
|
-
- **Python dependency evidence.** Upgrade previews handle numeric-looking
|
|
58
|
-
package names, Poetry dependency source lines, nested requirements, and nested
|
|
59
|
-
constraints more reliably.
|
|
60
|
-
- **Quieter release-candidate proof.** Start output now avoids duplicate ready
|
|
61
|
-
sections, low-signal test/barrel hotspot cautions stay out of the first
|
|
62
|
-
action, and `privacy-check --offline` exposes the offline boundary in help.
|
|
63
|
-
- **Release CI alignment.** CI now runs the full source test harness on Node 20,
|
|
64
|
-
22, and 24, with a separate Node 18 packed-install smoke job for published
|
|
65
|
-
package compatibility.
|
|
66
|
-
- **Maintainability cleanup.** Mission Control route criteria, public start
|
|
67
|
-
types, plugin loading, telemetry helpers, preflight/report assembly, code
|
|
68
|
-
graph indexing, and HTML reporters have been split into focused modules.
|
|
69
|
-
|
|
70
|
-
<img src="docs/projscan-proof-router.png" alt="projscan intent router and proof workflow showing impact routing, setup discovery, dependency intelligence, and stable-surface guardrails" width="760">
|
|
71
|
-
|
|
72
|
-
<img src="docs/projscan-mission-proof.gif" alt="projscan saving a Mission Control bundle, reporting local mission proof, and resuming from saved proof state" width="760">
|
|
73
|
-
|
|
74
|
-
Regenerate the README media with Playwright and VHS:
|
|
75
|
-
|
|
76
|
-
```bash
|
|
77
|
-
npm run docs:assets
|
|
78
|
-
npm run docs:screenshots
|
|
79
|
-
npm run docs:demos
|
|
80
|
-
```
|
|
81
|
-
|
|
82
|
-
## Mission Execution Plan + Copyable Handoffs
|
|
83
|
-
|
|
84
|
-
`projscan start --intent "<goal>"` gives agents an execution plan with ordered phases, ready commands, blocked inputs, follow-ups, proof, and done criteria. The cursor points to the next useful step and includes MCP `tool` / `args` when projscan can call it directly.
|
|
85
|
-
|
|
86
|
-
Projscan also returns a Markdown runbook, a task card, a review gate, and a resume object. A resumed agent gets the current command, the MCP tool call, placeholder bindings, follow-up templates, the ordered checklist, and the remaining proof queue without walking the full plan. MCP and JSON clients can read `missionControl.taskCard.markdown`, the same Markdown printed by `--task-card` and written to `task-card.md`. They can also read `missionControl.reviewGate.markdown` to know when to stop, report proof, and wait for approval before starting another slice, release, publish, or deploy. `missionControl.reviewGate.worktree` adds the current worktree evidence summary and visible changed files, so review handoffs keep the state projscan computed for the start report. `missionControl.reviewGate.proof` carries the remaining proof queue with commands, MCP calls, and structured proof items for review-only handoffs. `missionControl.reviewGate.doneWhen` mirrors the mission success criteria, so review-only handoffs show the approval target beside proof and worktree evidence. `missionControl.reviewGate.policy` lists the actions blocked until explicit reviewer approval: another slice, release, publish, deploy, push, merge, and version bump. `--review-gate-json` and saved `review-gate.json` expose the full review packet without requiring callers to parse the full handoff. `--review-policy` and saved `review-policy.json` expose only the approval boundary. `missionControl.reviewGate.decisions` gives the reviewer the allowed next choices and copyable reply text: approve another slice, request changes, or review a version candidate without publishing; the same menu appears in default console output, saved bundle README files, task cards, handoff prompts, and runbook Markdown. `--review-replies` and saved `review-replies.txt` print only those reply lines when a reviewer wants the smallest approval surface. The complete handoff object carries the same gate at `missionControl.handoff.reviewGate`, so `--handoff-json` and saved `handoff.json` include the stop boundary.
|
|
87
|
-
|
|
88
|
-
Repo-local agent harnesses are surfaced in the same proof queue. When `AGENTLOOP.md` or `agentloop.config.json` exists, `projscan start` adds `npm exec agentloop -- status` as a coordination/proof command; when `.agentflight/config.json` exists, it adds `npm exec agentflight -- verify`. These commands are reported for copy/paste, saved mission bundles, and JSON clients; `projscan start` does not execute them.
|
|
89
|
-
|
|
90
|
-
Use the index when you want the menu, or call one shortcut directly:
|
|
30
|
+
## Install
|
|
91
31
|
|
|
92
32
|
```bash
|
|
93
|
-
|
|
94
|
-
projscan start
|
|
95
|
-
projscan start --next-command --intent "<goal>" # Current shell command
|
|
96
|
-
projscan start --next-tool-call --intent "<goal>" # Current MCP call as compact JSON
|
|
97
|
-
projscan start --ready-tool-calls --intent "<goal>" # Current + proof MCP calls
|
|
98
|
-
projscan start --proof-commands --intent "<goal>" # Remaining proof commands
|
|
99
|
-
projscan start --checklist --intent "<goal>" # Ordered resume task card
|
|
100
|
-
projscan start --resume-json --intent "<goal>" # Structured resume object
|
|
101
|
-
projscan start --handoff-json --intent "<goal>" # Complete handoff object
|
|
102
|
-
projscan start --mission-script --intent "<goal>" # Shell script: current step + proof
|
|
103
|
-
projscan start --save-mission .projscan/mission --intent "<goal>" # Write bundle + quickstart
|
|
104
|
-
projscan start --task-card --intent "<goal>" # Paste-ready Markdown task card
|
|
105
|
-
projscan start --review-gate --intent "<goal>" # Stop-and-review gate
|
|
106
|
-
projscan start --review-gate-json --intent "<goal>" # Review gate JSON
|
|
107
|
-
projscan start --review-policy --intent "<goal>" # Review policy JSON
|
|
108
|
-
projscan start --review-replies --intent "<goal>" # Copy-only reviewer replies
|
|
109
|
-
projscan start --runbook --intent "<goal>" # Markdown mission runbook
|
|
110
|
-
projscan start --handoff-prompt --intent "<goal>" # One-line handoff prompt
|
|
111
|
-
projscan start --mission .projscan/mission # Resume from saved proof state
|
|
112
|
-
projscan mission-proof --mission .projscan/mission --format markdown # Paste-ready proof report
|
|
113
|
-
projscan mission-proof --list --format json # List saved mission bundles
|
|
114
|
-
projscan mission-proof --list --needs-attention --format json # List bundles that are not passed
|
|
115
|
-
projscan mission-proof --latest --format markdown # Report the newest saved mission bundle
|
|
116
|
-
projscan mission-proof --all --format markdown # Roll up local saved mission bundles
|
|
117
|
-
projscan mission-proof --all --require-passed # Fail if any selected bundle is not passed
|
|
118
|
-
projscan mission-proof --all --summary # One-line proof status for CI logs
|
|
119
|
-
projscan mission-proof --mission .projscan/mission --format json # Local proof summary for scripts
|
|
120
|
-
projscan mission-proof --init-baseline manual-runs.json # Create baseline template
|
|
121
|
-
projscan mission-proof --add-baseline-run manual-runs.json --id manual-1 --status passed --minutes-spent 25 # Record manual run
|
|
122
|
-
projscan mission-proof --check-baseline manual-runs.json # Validate baseline file
|
|
123
|
-
projscan mission-proof --mission .projscan/mission --write reports/mission-proof.md # Save a proof artifact
|
|
33
|
+
npm install -g projscan
|
|
34
|
+
projscan start
|
|
124
35
|
```
|
|
125
36
|
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
When work resumes, point start at the saved bundle:
|
|
37
|
+
Run without a global install:
|
|
129
38
|
|
|
130
39
|
```bash
|
|
131
|
-
projscan start
|
|
40
|
+
npx projscan start
|
|
132
41
|
```
|
|
133
42
|
|
|
134
|
-
|
|
43
|
+
Check the trust boundary first:
|
|
135
44
|
|
|
136
45
|
```bash
|
|
137
|
-
projscan
|
|
138
|
-
projscan
|
|
139
|
-
projscan
|
|
140
|
-
projscan mission-proof --list --mission-status failed --format json
|
|
141
|
-
projscan mission-proof --latest --format markdown
|
|
142
|
-
projscan mission-proof --all --format markdown
|
|
143
|
-
projscan mission-proof --all --require-passed
|
|
144
|
-
projscan mission-proof --all --summary --require-passed
|
|
145
|
-
projscan mission-proof --all --write reports/mission-proof.md
|
|
146
|
-
projscan mission-proof --mission .projscan/mission --write reports/mission-proof.md
|
|
147
|
-
projscan mission-proof --init-baseline manual-runs.json
|
|
148
|
-
projscan mission-proof --init-baseline manual-runs.json --format json
|
|
149
|
-
projscan mission-proof --add-baseline-run manual-runs.json --id manual-1 --status passed --minutes-spent 25 --reruns 1 --failed-gates 0 --reviewer-approvals 1
|
|
150
|
-
projscan mission-proof --add-baseline-run manual-runs.json --id manual-2 --status failed --format json
|
|
151
|
-
projscan mission-proof --check-baseline manual-runs.json
|
|
152
|
-
projscan mission-proof --check-baseline manual-runs.json --format json
|
|
153
|
-
projscan mission-proof --mission .projscan/mission --baseline manual-runs.json --format json
|
|
154
|
-
projscan mission-proof --mission .projscan/mission --baseline manual-runs.json --format json --write reports/mission-proof.json
|
|
155
|
-
```
|
|
156
|
-
|
|
157
|
-
The Markdown report is ready for PR notes, release review, and handoff docs. Add `--list` to show saved mission bundles, status, update time, totals, and copyable resume/proof commands before choosing a target. Add `--needs-attention` or `--mission-status failed` to focus that list. Add `--latest` to select the saved mission bundle with the newest `proof-logs/summary.json`. Add `--all` to discover `.projscan/mission` plus direct child bundles under `.projscan/missions/`. Add `--summary` when terminal logs need one status line. Add `--require-passed` when a local script or CI job should exit nonzero unless every selected bundle passed. Add `--write reports/mission-proof.md` to save the report as a local artifact; `.md` and `.markdown` paths write Markdown by default. Use JSON when agents or scripts need the same proof data, and add `--write reports/mission-proof.json` when CI should archive it. Run `--init-baseline manual-runs.json` to create the local baseline template, then use `--add-baseline-run` to record measured manual runs without editing JSON. Add `--format json` to baseline init, append, or check commands when a wrapper needs the written path, run count, added run, or totals. If `--baseline` or `--check-baseline` points at a missing or malformed file, projscan prints the exact template command or expected JSON shape. Baseline run IDs must be non-empty and unique. Baseline run statuses must be `passed`, `failed`, `running`, `not_run`, or `unknown`; metric fields must be non-negative numbers. The baseline file is optional. When present, it can list manual runs with minutes spent, reruns, failed gates, and reviewer approvals; projscan compares that local baseline with Mission Control proof without uploading source.
|
|
158
|
-
|
|
159
|
-
Default console output shows the same sections inline: `Run Cursor`, `Resume Checklist`, `Handoff Prompt`, `Ready Proof`, and `Proof Queue`. The proof views use the resume-aware remaining queue, so projscan does not repeat the current cursor command as proof.
|
|
160
|
-
|
|
161
|
-
Console output shows the same model for humans:
|
|
162
|
-
|
|
163
|
-
```text
|
|
164
|
-
Execution Plan
|
|
165
|
-
Run 1 ready step, resolve 2 input(s), then gather 4 proof command(s).
|
|
166
|
-
- [ready] Ready Commands
|
|
167
|
-
- Find exact target for impact analysis: projscan search "auth token loader" --format json
|
|
168
|
-
- [blocked] Resolve Inputs
|
|
169
|
-
- symbol: Replace <symbol-from-search> with an exported symbol returned by the search step.
|
|
170
|
-
- [pending] Follow Up
|
|
171
|
-
- If search returns an exported symbol: projscan impact --symbol <symbol-from-search> --format json
|
|
172
|
-
blocked by: input-1
|
|
173
|
-
Run Cursor
|
|
174
|
-
next: ready-1 in Ready Commands
|
|
175
|
-
command: projscan search "auth token loader" --format json
|
|
176
|
-
MCP call: projscan_search {"query":"auth token loader"}
|
|
177
|
-
unlocks: input-1, input-2
|
|
178
|
-
Resume Checklist
|
|
179
|
-
- [ready] run_current ready-1: projscan search "auth token loader" --format json (MCP: projscan_search {"query":"auth token loader"})
|
|
180
|
-
- [blocked] resolve_input input-1: <symbol-from-search> -> Replace <symbol-from-search> with an exported symbol returned by the search step.
|
|
181
|
-
- [blocked] run_follow_up follow-up-1: projscan impact --symbol <symbol-from-search> --format json (MCP: projscan_impact {"symbol":"<symbol-from-search>"})
|
|
182
|
-
- [ready] run_proof proof-2: projscan preflight --mode before_edit --format json (MCP: projscan_preflight {"mode":"before_edit"})
|
|
183
|
-
Handoff Prompt
|
|
184
|
-
Resume: Resume at ready-1 in ready_now: run `projscan search "auth token loader" --format json`. This can unlock input-1 (symbol), input-2 (file). Done when: An exact symbol or file path is selected from search results before impact analysis continues.
|
|
185
|
-
Ready Proof
|
|
186
|
-
Ready-to-run proof commands; placeholder follow-ups are excluded until Needs Input is resolved.
|
|
187
|
-
- projscan preflight --mode before_edit --format json
|
|
188
|
-
- projscan understand --view verify --format json
|
|
189
|
-
Proof Queue
|
|
190
|
-
- proof-2: projscan preflight --mode before_edit --format json (MCP: projscan_preflight {"mode":"before_edit"})
|
|
191
|
-
- proof-3: projscan understand --view verify --format json (MCP: projscan_understand {"view":"verify"})
|
|
192
|
-
```
|
|
193
|
-
|
|
194
|
-
Runbook handoff example:
|
|
195
|
-
|
|
196
|
-
````text
|
|
197
|
-
Agent Runbook
|
|
198
|
-
# Mission Runbook
|
|
199
|
-
Intent: what breaks if I rename the auth token loader
|
|
200
|
-
Status: needs_attention
|
|
201
|
-
Current phase: ready_now
|
|
202
|
-
|
|
203
|
-
## Current Cursor
|
|
204
|
-
- Step: ready-1 in ready_now
|
|
205
|
-
- Command: `projscan search "auth token loader" --format json`
|
|
206
|
-
- MCP call: projscan_search {"query":"auth token loader"}
|
|
207
|
-
- Unlocks: input-1, input-2
|
|
208
|
-
|
|
209
|
-
## Resume
|
|
210
|
-
Run now:
|
|
211
|
-
```sh
|
|
212
|
-
projscan search "auth token loader" --format json
|
|
213
|
-
````
|
|
214
|
-
|
|
215
|
-
MCP call: projscan_search {"query":"auth token loader"}
|
|
216
|
-
After running, resolve:
|
|
217
|
-
|
|
218
|
-
- input-1 (symbol): Replace <symbol-from-search> with an exported symbol returned by the search step.
|
|
219
|
-
- input-2 (file): Replace <file-from-search> with a file path returned by the search step.
|
|
220
|
-
Template inputs:
|
|
221
|
-
- <symbol-from-search> -> input-1 (symbol): Replace <symbol-from-search> with an exported symbol returned by the search step.
|
|
222
|
-
- <file-from-search> -> input-2 (file): Replace <file-from-search> with a file path returned by the search step.
|
|
223
|
-
Resume checklist:
|
|
224
|
-
- [ready] run_current ready-1: projscan search "auth token loader" --format json (MCP: projscan_search {"query":"auth token loader"})
|
|
225
|
-
- [blocked] resolve_input input-1: <symbol-from-search> -> Replace <symbol-from-search> with an exported symbol returned by the search step.
|
|
226
|
-
- [ready] run_proof proof-2: projscan preflight --mode before_edit --format json (MCP: projscan_preflight {"mode":"before_edit"})
|
|
227
|
-
- [pending] confirm_done criterion-1: An exact symbol or file path is selected from search results before impact analysis continues.
|
|
228
|
-
Proof queue:
|
|
229
|
-
- proof-2: `projscan preflight --mode before_edit --format json` (MCP: projscan_preflight {"mode":"before_edit"})
|
|
230
|
-
- proof-3: `projscan understand --view verify --format json` (MCP: projscan_understand {"view":"verify"})
|
|
231
|
-
Remaining proof:
|
|
232
|
-
- `projscan preflight --mode before_edit --format json`
|
|
233
|
-
- `projscan understand --view verify --format json`
|
|
234
|
-
MCP proof calls:
|
|
235
|
-
- proof-2: projscan_preflight {"mode":"before_edit"}
|
|
236
|
-
- proof-3: projscan_understand {"view":"verify"}
|
|
237
|
-
Then use:
|
|
238
|
-
- follow-up-1 (If search returns an exported symbol): projscan impact --symbol <symbol-from-search> --format json
|
|
239
|
-
- follow-up-2 (If search returns a file path): projscan impact <file-from-search> --format json
|
|
240
|
-
Prompt: Resume at ready-1 in ready_now: run `projscan search "auth token loader" --format json`. This can unlock input-1 (symbol), input-2 (file).
|
|
241
|
-
|
|
242
|
-
## Handoff Prompt
|
|
243
|
-
|
|
244
|
-
Resume: Resume at ready-1 in ready_now: run `projscan search "auth token loader" --format json`. This can unlock input-1 (symbol), input-2 (file). Done when: An exact symbol or file path is selected from search results before impact analysis continues. Needs input: symbol=<symbol-from-search>, file=<file-from-search>. Ready proof: Ready-to-run proof commands; placeholder follow-ups are excluded until Needs Input is resolved. projscan preflight --mode before_edit --format json && projscan understand --view verify --format json.
|
|
245
|
-
|
|
246
|
-
## Review Gate
|
|
247
|
-
|
|
248
|
-
- [ ] Complete this task card and remaining proof.
|
|
249
|
-
- [ ] Capture `git status --short`.
|
|
250
|
-
- [ ] Capture `git diff --stat`.
|
|
251
|
-
- [ ] Stop and ask for approval before starting another slice, release, publish, or deploy.
|
|
252
|
-
|
|
253
|
-
Review the completed mission, proof output, and working-tree summary before approving another slice, release, publish, or deploy.
|
|
254
|
-
|
|
255
|
-
## Ready Commands
|
|
256
|
-
|
|
257
|
-
- `projscan search "auth token loader" --format json`
|
|
258
|
-
|
|
259
|
-
## Blocked Inputs
|
|
260
|
-
|
|
261
|
-
- symbol: Replace <symbol-from-search> with an exported symbol returned by the search step.
|
|
262
|
-
|
|
263
|
-
````
|
|
264
|
-
|
|
265
|
-
Run `projscan doctor` for a focused health check:
|
|
266
|
-
|
|
267
|
-
```bash
|
|
268
|
-
npx projscan doctor
|
|
269
|
-
````
|
|
270
|
-
|
|
271
|
-
<img src="https://raw.githubusercontent.com/abhiyoheswaran1/projscan/v4.3.1/docs/npx%20projscan%20doctor.gif" alt="npx projscan doctor" width="700">
|
|
272
|
-
|
|
273
|
-
## Install
|
|
274
|
-
|
|
275
|
-
```bash
|
|
276
|
-
npm install -g projscan
|
|
277
|
-
```
|
|
278
|
-
|
|
279
|
-
Or run directly without installing:
|
|
280
|
-
|
|
281
|
-
```bash
|
|
282
|
-
npx projscan
|
|
46
|
+
projscan privacy-check
|
|
47
|
+
projscan start --intent "what can projscan read?"
|
|
48
|
+
projscan start --intent "does projscan read .env values?"
|
|
283
49
|
```
|
|
284
50
|
|
|
285
51
|
## Daily workflows
|
|
@@ -290,12 +56,14 @@ Use these three workflows before scanning the full command catalog.
|
|
|
290
56
|
|
|
291
57
|
```bash
|
|
292
58
|
projscan start --intent "what files do I need to change for auth?"
|
|
59
|
+
projscan start --intent "what should we build next?" # Routes to a before-edit implementation workplan
|
|
293
60
|
projscan understand --view change --intent "add auth token refresh" --format json
|
|
294
61
|
projscan preflight --mode before_edit --format json
|
|
295
62
|
```
|
|
296
63
|
|
|
297
|
-
|
|
298
|
-
|
|
64
|
+
You get a cited change map, read-first files, likely touched files, blocked inputs, and a before-edit proof gate.
|
|
65
|
+
|
|
66
|
+
Success criteria: the agent can name the files to read first, the likely files to touch, and the proof command to run before editing.
|
|
299
67
|
|
|
300
68
|
### Before handoff or commit
|
|
301
69
|
|
|
@@ -305,9 +73,9 @@ projscan preflight --mode before_commit --format json
|
|
|
305
73
|
projscan evidence-pack --pr-comment
|
|
306
74
|
```
|
|
307
75
|
|
|
308
|
-
|
|
309
|
-
|
|
310
|
-
without reading
|
|
76
|
+
You get concrete fixes, manual review gates, owner routing, baseline trend memory, and exact proof commands for the reviewer.
|
|
77
|
+
|
|
78
|
+
Success criteria: the reviewer sees the top fix, the remaining proof, and any manual sign-off gate without reading the full scan output.
|
|
311
79
|
|
|
312
80
|
### Before release-candidate review
|
|
313
81
|
|
|
@@ -317,780 +85,155 @@ projscan preflight --mode before_merge --format json
|
|
|
317
85
|
projscan evidence-pack --pr-comment
|
|
318
86
|
```
|
|
319
87
|
|
|
320
|
-
|
|
321
|
-
whether the work needs fixes or manual sign-off, and no version, publish, tag,
|
|
322
|
-
or deploy step is implied.
|
|
88
|
+
You get read-only readiness evidence. projscan reports fixes and sign-off gates; it does not tag, publish, deploy, or bump versions from these commands.
|
|
323
89
|
|
|
324
|
-
|
|
90
|
+
Success criteria: release review separates concrete defects from human approval gates before anyone tags or publishes.
|
|
325
91
|
|
|
326
|
-
|
|
92
|
+
## Mission Control
|
|
327
93
|
|
|
328
|
-
|
|
329
|
-
projscan privacy-check # Show exactly what can be read, written, or contacted
|
|
330
|
-
projscan start # First-60-seconds workflow orientation
|
|
331
|
-
projscan start --intent "what can projscan read?" # Routes to local privacy/trust boundary
|
|
332
|
-
projscan start --intent "does projscan read .env values?" # Routes to .env content policy check
|
|
333
|
-
projscan start --intent "is it safe to commit this change?" # Mission Control: inferred mode + ready actions + done criteria + proof
|
|
334
|
-
projscan start --intent "is my branch ready to merge?" # Routes to before-merge preflight readiness
|
|
335
|
-
projscan start --intent "rebase went wrong" # Routes to before-merge preflight recovery
|
|
336
|
-
projscan start --intent "resolve merge conflicts" # Routes to before-merge preflight recovery
|
|
337
|
-
projscan start --intent "what is blocking this PR?" # Routes to before-commit preflight blockers
|
|
338
|
-
projscan start --intent "summarize this repo" # Routes to cited repo map + orientation summary
|
|
339
|
-
projscan start --intent "what files should I read first?" # Routes to cited repo map + read-first files
|
|
340
|
-
projscan start --intent "where do I start in this codebase?" # Routes to cited repo map + read-first files
|
|
341
|
-
projscan start --intent "give me a tour of the repo" # Routes to cited repo map + entrypoints
|
|
342
|
-
projscan start --intent "explain the architecture" # Routes to cited repo map + boundaries
|
|
343
|
-
projscan start --intent "show me the main entrypoints" # Routes to cited repo map + entrypoints
|
|
344
|
-
projscan start --intent "how do I run this project?" # Routes to cited repo map + entrypoints
|
|
345
|
-
projscan start --intent "what command starts the dev server?" # Routes to cited repo map + entrypoints
|
|
346
|
-
projscan start --intent "what npm scripts exist?" # Routes to package/config contract discovery
|
|
347
|
-
projscan start --intent "which script runs e2e tests?" # Routes to package/config contract discovery
|
|
348
|
-
projscan start --intent "what command runs lint?" # Routes to package/config contract discovery
|
|
349
|
-
projscan start --intent "how do I run typecheck?" # Routes to package/config contract discovery
|
|
350
|
-
projscan start --intent "how do I seed the database?" # Routes to package/config contract discovery
|
|
351
|
-
projscan start --intent "what command runs migrations?" # Routes to package/config contract discovery
|
|
352
|
-
projscan start --intent "where should I put this new feature?" # Routes to change-readiness map
|
|
353
|
-
projscan start --intent "implement OAuth login" # Routes to change-readiness map
|
|
354
|
-
projscan start --intent "add billing webhook support" # Routes to change-readiness map
|
|
355
|
-
projscan start --intent "build a settings page" # Routes to change-readiness map
|
|
356
|
-
projscan start --intent "where should I add a new endpoint?" # Routes to change-readiness map
|
|
357
|
-
projscan start --intent "what files do I need to change for auth?" # Routes to change-readiness map
|
|
358
|
-
projscan start --intent "what docs should I update for this change?" # Routes to change-readiness map
|
|
359
|
-
projscan start --intent "where should I add this database migration?" # Routes to change-readiness map
|
|
360
|
-
projscan start --intent "which migrations exist?" # Routes to focused code search
|
|
361
|
-
projscan start --intent "show me generated files" # Routes to focused code search
|
|
362
|
-
projscan start --intent "can I drop this column?" # Routes to impact target search
|
|
363
|
-
projscan start --intent "what are the public contracts?" # Routes to public exports/config contracts
|
|
364
|
-
projscan start --intent "how do I safely deprecate this API?" # Routes to public exports/config contracts
|
|
365
|
-
projscan start --intent "what will this API change break?" # Routes to impact target search
|
|
366
|
-
projscan start --intent "what env vars does this repo need?" # Routes to config contract discovery
|
|
367
|
-
projscan start --intent "environment variables missing" # Routes to config contract discovery
|
|
368
|
-
projscan start --intent "where is NEXT_PUBLIC_API_URL used?" # Routes to focused code search
|
|
369
|
-
projscan start --intent "which env var controls auth?" # Routes to focused code search
|
|
370
|
-
projscan start --intent "where is \"Invalid token\" thrown?" # Routes to focused code search
|
|
371
|
-
projscan start --intent "find error message \"Payment failed\"" # Routes to focused code search
|
|
372
|
-
projscan start --intent "where is eslint config?" # Routes to focused code search
|
|
373
|
-
projscan start --intent "which config file defines aliases?" # Routes to focused code search
|
|
374
|
-
projscan start --intent "where is tsconfig path aliases configured?" # Routes to focused code search
|
|
375
|
-
projscan start --intent "where is Vitest config?" # Routes to focused code search
|
|
376
|
-
projscan start --intent "find Babel config" # Routes to focused code search
|
|
377
|
-
projscan start --intent "where is package manager configured?" # Routes to focused code search
|
|
378
|
-
projscan start --intent "where is pnpm workspace file?" # Routes to focused code search
|
|
379
|
-
projscan start --intent "what is risky in this repo?" # Routes to quality dimensions + top risks
|
|
380
|
-
projscan start --intent "what files are risky to touch?" # Routes to hotspot files
|
|
381
|
-
projscan start --intent "which files are too complex?" # Routes to hotspot files
|
|
382
|
-
projscan start --intent "what file should I refactor first?" # Routes to hotspot files
|
|
383
|
-
projscan start --intent "what tech debt should I pay down?" # Routes to hotspot files
|
|
384
|
-
projscan start --intent "what code should I simplify?" # Routes to hotspot files
|
|
385
|
-
projscan start --intent "find performance bottlenecks" # Routes to hotspot files
|
|
386
|
-
projscan start --intent "where are the slow files?" # Routes to hotspot files
|
|
387
|
-
projscan start --intent "find dead code" # Routes to doctor cleanup issues
|
|
388
|
-
projscan start --intent "find dead code and unused exports I can delete" # Routes to doctor cleanup issues
|
|
389
|
-
projscan start --intent "what can I safely delete?" # Routes to doctor cleanup discovery
|
|
390
|
-
projscan start --intent "what can I remove safely?" # Routes to doctor cleanup discovery
|
|
391
|
-
projscan start --intent "port 3000 already in use" # Routes to focused regression planning
|
|
392
|
-
projscan start --intent "peer dependency conflict after npm install" # Routes to focused regression planning
|
|
393
|
-
projscan start --intent "where is runAudit used?" # Routes to symbol impact/caller analysis
|
|
394
|
-
projscan start --intent "what code handles billing?" # Routes to focused code search
|
|
395
|
-
projscan start --intent "which file contains checkout logic?" # Routes to focused code search
|
|
396
|
-
projscan start --intent "find the Stripe webhook handler" # Routes to focused code search
|
|
397
|
-
projscan start --intent "find the handler for POST /api/users" # Routes to focused code search
|
|
398
|
-
projscan start --intent "where is the /checkout route handled?" # Routes to focused code search
|
|
399
|
-
projscan start --intent "where is /settings page rendered?" # Routes to focused code search
|
|
400
|
-
projscan start --intent "which page renders /billing?" # Routes to focused code search
|
|
401
|
-
projscan start --intent "where is route segment for dashboard?" # Routes to focused code search
|
|
402
|
-
projscan start --intent "where is not-found page handled?" # Routes to focused code search
|
|
403
|
-
projscan start --intent "which feature flags exist?" # Routes to focused code search
|
|
404
|
-
projscan start --intent "what background jobs exist?" # Routes to focused code search
|
|
405
|
-
projscan start --intent "find the email queue processor" # Routes to focused code search
|
|
406
|
-
projscan start --intent "where are metrics emitted?" # Routes to focused code search
|
|
407
|
-
projscan start --intent "where do we initialize Sentry?" # Routes to focused code search
|
|
408
|
-
projscan start --intent "what logs should I check for checkout?" # Routes to focused code search
|
|
409
|
-
projscan start --intent "find the dashboard for payments" # Routes to focused code search
|
|
410
|
-
projscan start --intent "where is seed data defined?" # Routes to focused code search
|
|
411
|
-
projscan start --intent "find fixtures for checkout" # Routes to focused code search
|
|
412
|
-
projscan start --intent "which mocks are used for payments?" # Routes to focused code search
|
|
413
|
-
projscan start --intent "where are Storybook stories for Button?" # Routes to focused code search
|
|
414
|
-
projscan start --intent "where are permissions checked for checkout?" # Routes to focused code search
|
|
415
|
-
projscan start --intent "which role can access admin?" # Routes to focused code search
|
|
416
|
-
projscan start --intent "what routes require login?" # Routes to focused code search
|
|
417
|
-
projscan start --intent "where is rate limiting configured?" # Routes to focused code search
|
|
418
|
-
projscan start --intent "where is cache invalidated for products?" # Routes to focused code search
|
|
419
|
-
projscan start --intent "find retry logic for payments" # Routes to focused code search
|
|
420
|
-
projscan start --intent "what sets request timeout?" # Routes to focused code search
|
|
421
|
-
projscan start --intent "find idempotency key handling" # Routes to focused code search
|
|
422
|
-
projscan start --intent "where is webhook signature verified?" # Routes to focused code search
|
|
423
|
-
projscan start --intent "where is input validation for signup?" # Routes to focused code search
|
|
424
|
-
projscan start --intent "which schema validates checkout?" # Routes to focused code search
|
|
425
|
-
projscan start --intent "where are request params parsed?" # Routes to focused code search
|
|
426
|
-
projscan start --intent "where is database transaction started?" # Routes to focused code search
|
|
427
|
-
projscan start --intent "where do we lock the order row?" # Routes to focused code search
|
|
428
|
-
projscan start --intent "what validates email uniqueness?" # Routes to focused code search
|
|
429
|
-
projscan start --intent "where is Prisma model for User?" # Routes to focused code search
|
|
430
|
-
projscan start --intent "find Drizzle schema for invoices" # Routes to focused code search
|
|
431
|
-
projscan start --intent "where is SQL query for invoices?" # Routes to focused code search
|
|
432
|
-
projscan start --intent "which repository saves orders?" # Routes to focused code search
|
|
433
|
-
projscan start --intent "find DAO for payments" # Routes to focused code search
|
|
434
|
-
projscan start --intent "where is loading state for dashboard?" # Routes to focused code search
|
|
435
|
-
projscan start --intent "where is error boundary for settings?" # Routes to focused code search
|
|
436
|
-
projscan start --intent "find command palette actions" # Routes to focused code search
|
|
437
|
-
projscan start --intent "where are i18n translations for checkout?" # Routes to focused code search
|
|
438
|
-
projscan start --intent "where are design tokens defined?" # Routes to focused code search
|
|
439
|
-
projscan start --intent "where is Tailwind theme configured?" # Routes to focused code search
|
|
440
|
-
projscan start --intent "where is global CSS imported?" # Routes to focused code search
|
|
441
|
-
projscan start --intent "which CSS module styles Button?" # Routes to focused code search
|
|
442
|
-
projscan start --intent "where is dark mode configured?" # Routes to focused code search
|
|
443
|
-
projscan start --intent "what breakpoints are defined?" # Routes to focused code search
|
|
444
|
-
projscan start --intent "where is sidebar nav item for billing?" # Routes to focused code search
|
|
445
|
-
projscan start --intent "which breadcrumb renders settings?" # Routes to focused code search
|
|
446
|
-
projscan start --intent "where is page title set for checkout?" # Routes to focused code search
|
|
447
|
-
projscan start --intent "where is Next.js layout for dashboard?" # Routes to focused code search
|
|
448
|
-
projscan start --intent "where is auth state stored?" # Routes to focused code search
|
|
449
|
-
projscan start --intent "find Redux slice for cart" # Routes to focused code search
|
|
450
|
-
projscan start --intent "where is Zustand store for user settings?" # Routes to focused code search
|
|
451
|
-
projscan start --intent "which context provider supplies theme?" # Routes to focused code search
|
|
452
|
-
projscan start --intent "which hook fetches invoices?" # Routes to focused code search
|
|
453
|
-
projscan start --intent "where is React Query mutation for checkout?" # Routes to focused code search
|
|
454
|
-
projscan start --intent "where do we call Stripe?" # Routes to focused code search
|
|
455
|
-
projscan start --intent "which code sends email through SendGrid?" # Routes to focused code search
|
|
456
|
-
projscan start --intent "where is S3 upload implemented?" # Routes to focused code search
|
|
457
|
-
projscan start --intent "find GitHub API client" # Routes to focused code search
|
|
458
|
-
projscan start --intent "where is GraphQL query for invoices?" # Routes to focused code search
|
|
459
|
-
projscan start --intent "where is websocket connection opened?" # Routes to focused code search
|
|
460
|
-
projscan start --intent "where is OpenAPI spec defined?" # Routes to focused code search
|
|
461
|
-
projscan start --intent "where is Swagger docs configured?" # Routes to focused code search
|
|
462
|
-
projscan start --intent "where is tRPC router for billing?" # Routes to focused code search
|
|
463
|
-
projscan start --intent "which GraphQL resolver handles invoices?" # Routes to focused code search
|
|
464
|
-
projscan start --intent "which protobuf defines user service?" # Routes to focused code search
|
|
465
|
-
projscan start --intent "where is gRPC client for payments?" # Routes to focused code search
|
|
466
|
-
projscan start --intent "where is the Dockerfile?" # Routes to focused code search
|
|
467
|
-
projscan start --intent "where is docker compose for local dev?" # Routes to focused code search
|
|
468
|
-
projscan start --intent "where are Kubernetes manifests?" # Routes to focused code search
|
|
469
|
-
projscan start --intent "find Helm chart for payments" # Routes to focused code search
|
|
470
|
-
projscan start --intent "where is Terraform module for S3?" # Routes to focused code search
|
|
471
|
-
projscan start --intent "which GitHub workflow deploys staging?" # Routes to focused code search
|
|
472
|
-
projscan start --intent "where is Vercel config?" # Routes to focused code search
|
|
473
|
-
projscan start --intent "where is password reset handled?" # Routes to focused code search
|
|
474
|
-
projscan start --intent "where is team invite flow?" # Routes to focused code search
|
|
475
|
-
projscan start --intent "where is onboarding flow implemented?" # Routes to focused code search
|
|
476
|
-
projscan start --intent "find CSV export for users" # Routes to focused code search
|
|
477
|
-
projscan start --intent "what creates audit log entries?" # Routes to focused code search
|
|
478
|
-
projscan start --intent "where is refund handling for payments?" # Routes to focused code search
|
|
479
|
-
projscan start --intent "where is subscription renewal handled?" # Routes to focused code search
|
|
480
|
-
projscan start --intent "where is welcome email template?" # Routes to focused code search
|
|
481
|
-
projscan start --intent "find password reset email copy" # Routes to focused code search
|
|
482
|
-
projscan start --intent "where is push notification copy for invites?" # Routes to focused code search
|
|
483
|
-
projscan start --intent "where is SMS verification template?" # Routes to focused code search
|
|
484
|
-
projscan start --intent "which template sends receipt email?" # Routes to focused code search
|
|
485
|
-
projscan start --intent "where is invoice PDF generated?" # Routes to focused code search
|
|
486
|
-
projscan start --intent "find documentation for auth" # Routes to focused docs search
|
|
487
|
-
projscan start --intent "what depends on src/core/start.ts?" # Routes to file impact/dependency analysis
|
|
488
|
-
projscan start --intent "can I delete src/core/start.ts?" # Routes to file impact/dependency analysis
|
|
489
|
-
projscan start --intent "revert src/core/start.ts safely" # Routes to file impact/dependency analysis
|
|
490
|
-
projscan start --intent "how do I revert this change safely?" # Routes to impact target search
|
|
491
|
-
projscan start --intent "what dependencies does this repo use?" # Routes to dependency inventory
|
|
492
|
-
projscan start --intent "why is the bundle so large?" # Routes to dependency size inventory
|
|
493
|
-
projscan start --intent "find package bloat" # Routes to dependency size inventory
|
|
494
|
-
projscan start --intent "what licenses do our dependencies use?" # Routes to dependency license inventory
|
|
495
|
-
projscan start --intent "who uses lodash?" # Routes to package importer graph query
|
|
496
|
-
projscan start --intent "why do we depend on lodash?" # Routes to package importer graph query
|
|
497
|
-
projscan start --intent "third party notices" # Routes to dependency license inventory
|
|
498
|
-
projscan start --intent "open source compliance check" # Routes to dependency license inventory
|
|
499
|
-
projscan start --intent "what workspaces are in this repo?" # Routes to monorepo workspace map
|
|
500
|
-
projscan start --intent "which workspace owns auth?" # Routes to monorepo workspace map
|
|
501
|
-
projscan start --intent "where should I put this in the monorepo?" # Routes to monorepo workspace map
|
|
502
|
-
projscan start --intent "does lodash have a CVE?" # Routes to scoped npm audit
|
|
503
|
-
projscan start --intent "what CVEs affect this repo?" # Routes to npm audit
|
|
504
|
-
projscan start --intent "find vulnerable packages" # Routes to npm audit
|
|
505
|
-
projscan start --intent "who owns auth?" # Routes to focused ownership search
|
|
506
|
-
projscan start --intent "which team owns payments?" # Routes to focused ownership search
|
|
507
|
-
projscan start --intent "who should I ask about auth?" # Routes to focused ownership search
|
|
508
|
-
projscan start --intent "what should I read before changing src/core/start.ts?" # Routes to exact-file orientation
|
|
509
|
-
projscan start --intent "explain src/core/start.ts" # Routes to per-file purpose/risk/ownership inspection
|
|
510
|
-
projscan start --intent "who owns src/core/start.ts?" # Routes to file ownership/risk context
|
|
511
|
-
projscan start --intent "who should review src/core/start.ts?" # Routes to file ownership/reviewer context
|
|
512
|
-
projscan start --intent "who last touched src/core/start.ts?" # Routes to file ownership/history context
|
|
513
|
-
projscan start --intent "why is src/core/start.ts risky?" # Routes to exact-file risk context
|
|
514
|
-
projscan start --intent "who imports src/core/start.ts?" # Routes to a targeted semantic graph query
|
|
515
|
-
projscan start --intent "where are the tests for src/core/start.ts?" # Routes to focused test-file search
|
|
516
|
-
projscan start --intent "where are tests for auth?" # Routes to focused test-topic search
|
|
517
|
-
projscan start --intent "which tests cover auth?" # Routes to focused existing-test search
|
|
518
|
-
projscan start --intent "locate specs for checkout" # Routes to focused test-topic search
|
|
519
|
-
projscan start --intent "which tests should I run for src/core/start.ts?" # Routes to verification proof planning
|
|
520
|
-
projscan start --intent "what should I test before pushing?" # Routes to verification proof planning
|
|
521
|
-
projscan start --intent "is src/core/start.ts covered by tests?" # Routes to file coverage/risk context
|
|
522
|
-
projscan start --intent "what tests should I add for src/core/start.ts?" # Routes to file test-design context
|
|
523
|
-
projscan start --intent "what changed in this PR?" # Routes to structural PR diff
|
|
524
|
-
projscan start --intent "is this PR too large?" # Routes to structural PR diff
|
|
525
|
-
projscan start --intent "what did I change since main?" # Routes to structural branch diff
|
|
526
|
-
projscan start --intent "is my branch stale?" # Routes to structural branch diff
|
|
527
|
-
projscan start --intent "compare my branch with main" # Routes to structural branch diff
|
|
528
|
-
projscan start --intent "write a commit message for these changes" # Routes to structural diff evidence
|
|
529
|
-
projscan start --intent "summarize my changes for a commit" # Routes to structural diff evidence
|
|
530
|
-
projscan start --intent "how risky is this PR?" # Routes to structural PR review
|
|
531
|
-
projscan start --intent "what are the risks in my PR?" # Routes to structural PR review
|
|
532
|
-
projscan start --intent "what are the top risks before merge?" # Routes to before-merge preflight readiness
|
|
533
|
-
projscan start --intent "am I ready to open a PR?" # Routes to PR-readiness evidence pack
|
|
534
|
-
projscan start --intent "who should review this PR?" # Routes to owner-routing evidence pack
|
|
535
|
-
projscan start --intent "who owns the changed files?" # Routes to changed-file owner routing
|
|
536
|
-
projscan start --intent "write a PR comment for reviewers" # Routes to approval-ready evidence pack
|
|
537
|
-
projscan start --intent "write a PR description" # Routes to approval-ready evidence pack
|
|
538
|
-
projscan start --intent "what should my PR say?" # Routes to approval-ready evidence pack
|
|
539
|
-
projscan start --intent "make a PR checklist" # Routes to approval-ready evidence pack
|
|
540
|
-
projscan start --intent "what should I tell my team about this change?" # Routes to approval-ready evidence pack
|
|
541
|
-
projscan start --intent "what should I fix first?" # Routes to bug-hunt prioritization
|
|
542
|
-
projscan start --intent "what is the fastest safe fix?" # Routes to bug-hunt prioritization before generic safety
|
|
543
|
-
projscan start --intent "find a quick win" # Routes to bug-hunt prioritization
|
|
544
|
-
projscan start --intent "what can I do in five minutes?" # Routes to bug-hunt prioritization
|
|
545
|
-
projscan start --intent "pick an easy task for me" # Routes to bug-hunt prioritization
|
|
546
|
-
projscan start --intent "what should an intern work on?" # Routes to bug-hunt prioritization
|
|
547
|
-
projscan start --intent "what is a low risk improvement?" # Routes to bug-hunt prioritization
|
|
548
|
-
projscan start --intent "pick a small safe task" # Routes to bug-hunt prioritization
|
|
549
|
-
projscan start --intent "what should I do next?" # Routes to an ordered before-edit workplan
|
|
550
|
-
projscan start --intent "what should we build next?" # Routes to a before-edit implementation workplan
|
|
551
|
-
projscan start --intent "explain issue missing-test-framework" # Routes to deep issue context
|
|
552
|
-
projscan start --intent "fix issue missing-test-framework" # Routes to a concrete fix suggestion
|
|
553
|
-
projscan start --intent "is user input reaching SQL sinks?" # Routes to hardening dataflow analysis
|
|
554
|
-
projscan start --intent "does this endpoint expose secrets?" # Routes to hardening dataflow analysis
|
|
555
|
-
projscan start --intent "where is PII handled?" # Routes to hardening dataflow analysis
|
|
556
|
-
projscan start --intent "GDPR compliance check" # Routes to hardening dataflow analysis
|
|
557
|
-
projscan start --intent "where do we store access tokens?" # Routes to hardening dataflow analysis
|
|
558
|
-
projscan start --intent "is this change secure?" # Routes to structural PR review
|
|
559
|
-
projscan start --intent "check this PR for security issues" # Routes to structural PR review
|
|
560
|
-
projscan start --intent "what are the scariest untested files?" # Routes to coverage × hotspot test targets
|
|
561
|
-
projscan start --intent "which files have no tests?" # Routes to coverage × hotspot test targets
|
|
562
|
-
projscan start --intent "what breaks if I bump chalk to 6?" # Routes to offline package upgrade impact
|
|
563
|
-
projscan start --intent "what breaks if I update react?" # Routes to offline package upgrade impact
|
|
564
|
-
projscan start --intent "can I remove lodash?" # Routes to offline package removal impact
|
|
565
|
-
projscan start --intent "is lodash safe to remove?" # Routes to offline package removal impact
|
|
566
|
-
projscan start --intent "CI is failing after this PR" # Routes to a focused regression plan
|
|
567
|
-
projscan start --intent "CI is flaky" # Routes to a focused regression plan
|
|
568
|
-
projscan start --intent "production is down" # Routes to a focused regression plan
|
|
569
|
-
projscan start --intent "why is the login endpoint returning 500?" # Routes to a focused regression plan
|
|
570
|
-
projscan start --intent "why did CI fail?" # Routes to a focused regression plan
|
|
571
|
-
projscan start --intent "why is GitHub Actions failing?" # Routes to a focused regression plan
|
|
572
|
-
projscan start --intent "which GitHub Actions job failed?" # Routes to a focused regression plan
|
|
573
|
-
projscan start --intent "why is CI slow?" # Routes to a focused regression plan
|
|
574
|
-
projscan start --intent "why did the build fail?" # Routes to a focused regression plan
|
|
575
|
-
projscan start --intent "what is making builds slow?" # Routes to a focused regression plan
|
|
576
|
-
projscan start --intent "lint is failing" # Routes to a focused regression plan
|
|
577
|
-
projscan start --intent "typecheck is failing" # Routes to a focused regression plan
|
|
578
|
-
projscan start --intent "npm install is failing" # Routes to a focused regression plan
|
|
579
|
-
projscan start --intent "debug this stack trace" # Routes to a focused regression plan
|
|
580
|
-
projscan start --intent "where is this stack trace from?" # Routes to a focused regression plan
|
|
581
|
-
projscan start --intent "database connection refused locally" # Routes to a focused regression plan
|
|
582
|
-
projscan start --intent "what command reproduces the flake?" # Routes to a focused regression plan
|
|
583
|
-
projscan start --intent "quarantine flaky test" # Routes to a focused regression plan
|
|
584
|
-
projscan start --intent "what tests should I run for my changes?" # Routes to verification proof planning
|
|
585
|
-
projscan start --intent "how can I speed up tests?" # Routes to a focused regression plan
|
|
586
|
-
projscan start --intent "what commands prove this works?" # Routes to focused proof commands
|
|
587
|
-
projscan start --intent "what commands benchmark this repo?" # Routes to focused proof commands
|
|
588
|
-
projscan start --intent "give me proof commands" # Routes to focused proof commands
|
|
589
|
-
projscan start --intent "what commands should I run before pushing?" # Routes to focused pre-push proof
|
|
590
|
-
projscan start --intent "what smoke checks should I run before commit?" # Routes to a smoke regression plan
|
|
591
|
-
projscan start --intent "what full regression should I run before merge?" # Routes to a full regression plan
|
|
592
|
-
projscan start --intent "what should I check before release?" # Routes to release readiness
|
|
593
|
-
projscan start --intent "can I deploy this?" # Routes to release readiness
|
|
594
|
-
projscan start --intent "what changed since last release?" # Routes to release readiness
|
|
595
|
-
projscan start --intent "write a release note for this change" # Routes to release readiness and changelog evidence
|
|
596
|
-
projscan start --intent "draft changelog entry" # Routes to release readiness and changelog evidence
|
|
597
|
-
projscan start --intent "show coordination status for parallel agents" # Routes to one-call swarm readiness
|
|
598
|
-
projscan start --intent "who else is working on this?" # Routes to one-call swarm readiness
|
|
599
|
-
projscan start --intent "am I going to collide with another agent?" # Routes to one-call swarm readiness
|
|
600
|
-
projscan start --intent "what worktrees are active?" # Routes to one-call swarm readiness
|
|
601
|
-
projscan start --intent "what should merge first?" # Routes to merge-risk ordering
|
|
602
|
-
projscan start --intent "show me overlapping changes" # Routes to collision detection
|
|
603
|
-
projscan start --intent "show active claims" # Routes to advisory claim listing
|
|
604
|
-
projscan start --intent "claim src/core/start.ts for me" # Routes to active-claim review + file claim action
|
|
605
|
-
projscan start --intent "where did I leave off?" # Routes to touched-file session context
|
|
606
|
-
projscan start --intent "what changed while I was away?" # Routes to touched-file session context
|
|
607
|
-
projscan start --intent "what changed while I was offline?" # Routes to touched-file session context
|
|
608
|
-
projscan start --intent "what changed while I was asleep?" # Routes to touched-file session context
|
|
609
|
-
projscan start --intent "what did the last agent touch?" # Routes to remembered touched-file session context
|
|
610
|
-
projscan start --intent "what did the last agent do?" # Routes to remembered touched-file session context
|
|
611
|
-
projscan start --intent "give the next agent a handoff" # Routes to a compact agent brief
|
|
612
|
-
projscan understand --view map # Cited repo map, flows, contracts, change readiness, and verification proof
|
|
613
|
-
projscan preflight --format json # Proceed/caution/block safety gate
|
|
614
|
-
projscan evidence-pack --pr-comment # Reviewer-ready PR evidence
|
|
615
|
-
```
|
|
94
|
+
`projscan start --intent "<goal>"` turns a plain-language goal into an execution plan:
|
|
616
95
|
|
|
617
|
-
|
|
96
|
+
- current command
|
|
97
|
+
- blocked inputs
|
|
98
|
+
- follow-up commands
|
|
99
|
+
- proof queue
|
|
100
|
+
- done criteria
|
|
101
|
+
- review gate
|
|
618
102
|
|
|
619
|
-
|
|
620
|
-
projscan first-run
|
|
621
|
-
projscan init mcp --client all
|
|
622
|
-
projscan mcp doctor --client codex
|
|
623
|
-
projscan mcp
|
|
624
|
-
```
|
|
625
|
-
|
|
626
|
-
For team rollout after the first local run is trusted:
|
|
627
|
-
|
|
628
|
-
```bash
|
|
629
|
-
projscan init team --team security
|
|
630
|
-
projscan telemetry explain
|
|
631
|
-
projscan feedback init --output .projscan-feedback.json
|
|
632
|
-
projscan dogfood --repo ../api --repo ../web --repo ../worker --feedback .projscan-feedback.json --format json
|
|
633
|
-
projscan trial --repo ../api --repo ../web --repo ../worker --feedback .projscan-feedback.json --format json
|
|
634
|
-
```
|
|
635
|
-
|
|
636
|
-
For copyable team recipes, see
|
|
637
|
-
[`docs/examples/swarm-coordination.md`](docs/examples/swarm-coordination.md)
|
|
638
|
-
and [`docs/examples/adoption-workflows.md`](docs/examples/adoption-workflows.md).
|
|
639
|
-
|
|
640
|
-
For maintainers changing trust-sensitive behavior:
|
|
103
|
+
Save a mission when work may pass between agents:
|
|
641
104
|
|
|
642
105
|
```bash
|
|
643
|
-
|
|
106
|
+
projscan start --save-mission .projscan/mission --intent "is it safe to commit this change?"
|
|
107
|
+
projscan mission-proof --mission .projscan/mission --format markdown
|
|
108
|
+
projscan start --mission .projscan/mission
|
|
644
109
|
```
|
|
645
110
|
|
|
646
|
-
|
|
111
|
+
<img src="docs/projscan-proof-router.png" alt="projscan proof workflow showing mission proof, MCP resume input, proof summary, and version review gate" width="760">
|
|
647
112
|
|
|
648
|
-
|
|
113
|
+
Mission bundles include a runbook, task card, handoff prompt, proof scripts, review gate JSON, reviewer replies, and proof logs. `mission-proof` summarizes passed proof, failed gates, reruns, reviewer decisions, and optional manual baseline data.
|
|
649
114
|
|
|
650
|
-
|
|
115
|
+
<details>
|
|
116
|
+
<summary><strong>Terminal demos</strong></summary>
|
|
651
117
|
|
|
652
|
-
|
|
118
|
+
<img src="docs/projscan-mission-control.gif" alt="projscan start printing shortcut commands for a safe-commit intent" width="760">
|
|
653
119
|
|
|
654
|
-
|
|
120
|
+
<img src="docs/projscan-mission-proof.gif" alt="projscan saving a mission, reporting proof status, and printing the review gate" width="760">
|
|
655
121
|
|
|
656
|
-
|
|
657
|
-
projscan understand --view map --format json
|
|
658
|
-
projscan understand --view flow --format json
|
|
659
|
-
projscan understand --view contracts --format json
|
|
660
|
-
projscan understand --view change --intent "rename auth token loader" --format json
|
|
661
|
-
projscan understand --view verify --format json
|
|
662
|
-
```
|
|
122
|
+
</details>
|
|
663
123
|
|
|
664
|
-
|
|
665
|
-
|
|
666
|
-
## Commands
|
|
667
|
-
|
|
668
|
-
| Command | Description |
|
|
669
|
-
| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
670
|
-
| `projscan analyze` | Full analysis - languages, frameworks, dependencies, issues |
|
|
671
|
-
| `projscan route` | Map a plain-language goal to the best projscan tool with weighted confidence and matched keywords |
|
|
672
|
-
| `projscan start` | First-60-seconds workflow orientation with daily workflows, setup diagnostics, Mission Control, top risks, and next commands. Add `--intent "<goal>"` to route a plain-language goal to route confidence, phased execution plan, ready actions, done criteria, and proof commands |
|
|
673
|
-
| `projscan mission-proof` | Summarize saved Mission Control proof, reviewer decisions, reruns, failed gates, and optional manual-baseline comparison |
|
|
674
|
-
| `projscan first-run` | First-run setup diagnostics plus the shared `firstTenMinutes` command path |
|
|
675
|
-
| `projscan init mcp` | Ready-to-paste MCP client configs for popular agent clients |
|
|
676
|
-
| `projscan mcp doctor` | Verify MCP setup and print paste-ready client config with checks |
|
|
677
|
-
| `projscan init policy` | Team policy starter kits for frontend, platform, security, and monorepo teams |
|
|
678
|
-
| `projscan init team` | Bootstrap policy, PR workflow, CODEOWNERS starter, baseline memory, start report, and first-PR onboarding checklist |
|
|
679
|
-
| `projscan init github-action` | GitHub Actions PR workflow that validates and posts projscan evidence comments, then fails only on preflight blocks |
|
|
680
|
-
| `projscan recipes` | Agent workflow recipes for team bootstrap, PR automation, before edit, bug hunt, approval, handoff, and pre-merge |
|
|
681
|
-
| `projscan workplan` | Agent execution plan - prioritized tasks with evidence, tools, verification, and handoff text |
|
|
682
|
-
| `projscan bug-hunt` | Prioritized bug-hunt action queue from doctor, preflight, and session evidence; manual sign-off-only queues print review wording while JSON verdict compatibility is preserved, and hotspot-only churn stays as a watchlist signal |
|
|
683
|
-
| `projscan agent-brief` | Compact next-agent context packet with focus items, coordination hints, guardrails, repo context, and next actions |
|
|
684
|
-
| `projscan quality-scorecard` | Dimensioned quality view with health, security, tests, maintainability, coordination, and top risks |
|
|
685
|
-
| `projscan understand` | Cited repo map, runtime flows, public contracts, change readiness, verification tiers, unknowns, and next commands |
|
|
686
|
-
| `projscan release-train` | Plan upcoming product lines with readiness evidence |
|
|
687
|
-
| `projscan evidence-pack` | Assemble approval evidence from planning, bug-hunt, workplan, preflight, trust calibration, First Fix, owner routing, and baseline trend memory |
|
|
688
|
-
| `projscan trial` | Produce one adoption-readiness report from onboarding, dogfood, feedback, trust signals, and website proof |
|
|
689
|
-
| `projscan feedback` | Capture measured reviewer feedback: minutes saved, prevented bad edits, false positives, and repeat PR use |
|
|
690
|
-
| `projscan privacy-check` | Verify the local trust boundary: telemetry, offline mode, scan root, .gitignore handling, ignored-file count, .env content scanning, and network-capable endpoints |
|
|
691
|
-
| `projscan telemetry` | Explicit default-off telemetry controls: status, enable, disable, and explain |
|
|
692
|
-
| `projscan dogfood` | Evaluate 1+ real repos for PR-comment readiness, repeat-use readiness, MCP readiness, and reviewer feedback prompts |
|
|
693
|
-
| `projscan regression-plan` | Build a smoke, focused, or full regression matrix from product risk signals |
|
|
694
|
-
| `projscan handoff` | Concise next-agent handoff from the current workplan |
|
|
695
|
-
| `projscan doctor` | Health check - missing tooling, architecture smells, security and supply-chain risks |
|
|
696
|
-
| `projscan preflight` | Agent safety gate - `proceed`, `caution`, or `block` with health, change, plugin, and supply-chain evidence |
|
|
697
|
-
| `projscan hotspots` | Rank files by risk - churn × complexity × issues × ownership |
|
|
698
|
-
| `projscan semantic-graph` | Stable v3 graph contract, plus targeted `--query importers/imports/exports/...` lookups |
|
|
699
|
-
| `projscan dataflow` | Focused direct, propagated, and bridge source-to-sink dataflow risks |
|
|
700
|
-
| `projscan search <query>` | **BM25-ranked search** - content + symbols + path, with excerpts |
|
|
701
|
-
| `projscan file <path>` | Drill into a file - purpose, risk, ownership, related issues |
|
|
702
|
-
| `projscan fix` | Auto-fix issues (ESLint, Prettier, Vitest, .editorconfig) |
|
|
703
|
-
| `projscan ci` | CI health gate - SARIF output, `--changed-only` PR-diff mode, exits 1 if score below threshold |
|
|
704
|
-
| `projscan diff` | Compare current health **and hotspot trends** against a baseline |
|
|
705
|
-
| `projscan diagram` | ASCII architecture diagram of your project |
|
|
706
|
-
| `projscan structure` | Directory tree with file counts |
|
|
707
|
-
| `projscan dependencies` | Dependency analysis - counts, license summary, risks, recommendations |
|
|
708
|
-
| `projscan outdated` | Declared-vs-installed drift check (offline) |
|
|
709
|
-
| `projscan audit` | `npm audit`-powered vulnerability report - SARIF-ready for Code Scanning |
|
|
710
|
-
| `projscan upgrade <pkg>` | Preview upgrade impact - npm CHANGELOG/importers or Python manifest, lockfile, and importer evidence, offline by default |
|
|
711
|
-
| `projscan coverage` | **Coverage × hotspots - rank the scariest untested files** (`--changed-only` for diff mode) |
|
|
712
|
-
| `projscan badge` | Generate a health score badge for your README |
|
|
713
|
-
| `projscan init` | _(1.6)_ Scaffold `.projscanrc.json` with sensible defaults |
|
|
714
|
-
| `projscan install-hook` | _(1.6)_ Install a `pre-commit` hook running `projscan ci --changed-only` |
|
|
715
|
-
| `projscan workspace` | _(1.6)_ Register sibling repos for cross-repo intelligence (`add` / `list` / `remove`) |
|
|
716
|
-
| `projscan apply-fix <id>` | _(1.6)_ Mechanically execute the safe fix templates with rollback (default dry-run) |
|
|
717
|
-
| `projscan taint` | _(1.6)_ Source-to-sink reachability over the call graph |
|
|
718
|
-
| `projscan plugin` | Discover, scaffold, validate, and test local analyzer/reporter plugins |
|
|
719
|
-
| `projscan mcp` | Run as an MCP server for AI coding agents (Claude Code, Codex, Cursor, Gemini, Windsurf, …) |
|
|
720
|
-
|
|
721
|
-
To see all commands and options, run:
|
|
124
|
+
Regenerate README media:
|
|
722
125
|
|
|
723
126
|
```bash
|
|
724
|
-
|
|
127
|
+
npm run docs:screenshots
|
|
128
|
+
npm run docs:demos
|
|
725
129
|
```
|
|
726
130
|
|
|
727
|
-
|
|
728
|
-
|
|
729
|
-
<details>
|
|
730
|
-
<summary><strong>projscan structure</strong> - Directory tree with file counts</summary>
|
|
731
|
-
|
|
732
|
-
<img src="https://raw.githubusercontent.com/abhiyoheswaran1/projscan/v4.3.1/docs/npx%20projscan%20structure.gif" alt="npx projscan structure" width="700">
|
|
733
|
-
</details>
|
|
734
|
-
|
|
735
|
-
<details>
|
|
736
|
-
<summary><strong>projscan diagram</strong> - Architecture visualization</summary>
|
|
737
|
-
|
|
738
|
-
<img src="https://raw.githubusercontent.com/abhiyoheswaran1/projscan/v4.3.1/docs/npx%20projscan%20diagram.gif" alt="npx projscan diagram" width="700">
|
|
739
|
-
</details>
|
|
131
|
+
## 4.9.3 Notes
|
|
740
132
|
|
|
741
|
-
|
|
742
|
-
<summary><strong>projscan dependencies</strong> - Dependency analysis</summary>
|
|
133
|
+
4.9.3 is a documentation and proof-media patch for the 4.9 trust release:
|
|
743
134
|
|
|
744
|
-
|
|
745
|
-
|
|
135
|
+
- README now starts with install, three daily workflows, MCP setup, command map, and the trust model.
|
|
136
|
+
- Mission Control screenshots and VHS demos were regenerated from current CLI output.
|
|
137
|
+
- The release keeps the 4.9.2 runtime fixes for TypeScript aliases, local package aliases, Next.js App Router entrypoints, explicit before-edit proof, compact reviewer feedback, caution triage, and parallel preflight gathering.
|
|
746
138
|
|
|
747
|
-
|
|
748
|
-
<summary><strong>projscan badge</strong> - Health badge generation</summary>
|
|
749
|
-
|
|
750
|
-
<img src="https://raw.githubusercontent.com/abhiyoheswaran1/projscan/v4.3.1/docs/npx%20projscan%20badge.gif" alt="npx projscan badge" width="700">
|
|
751
|
-
</details>
|
|
139
|
+
## MCP Setup
|
|
752
140
|
|
|
753
|
-
|
|
141
|
+
Use MCP when an agent should call projscan during a coding session.
|
|
754
142
|
|
|
755
|
-
|
|
143
|
+
Claude Code:
|
|
756
144
|
|
|
757
145
|
```bash
|
|
758
|
-
projscan
|
|
759
|
-
projscan analyze --format html # Self-contained HTML report
|
|
760
|
-
projscan doctor --format markdown # Markdown for docs/PRs
|
|
761
|
-
projscan mission-proof --format markdown # Mission proof report for handoffs
|
|
762
|
-
projscan mission-proof --write reports/mission-proof.md # Save Markdown proof
|
|
763
|
-
projscan ci --format sarif # SARIF 2.1.0 for GitHub Code Scanning
|
|
764
|
-
projscan analyze --report-scope src/api --redact-paths --format json # Scoped, redacted shareable evidence
|
|
765
|
-
projscan analyze --report-scope "src/api,packages/backend" --redact-paths --format json # Multi-scope partner evidence
|
|
766
|
-
projscan doctor --report-policy apiEvidence --format markdown # Reuse a configured evidence policy
|
|
146
|
+
claude mcp add projscan -- npx -y projscan mcp
|
|
767
147
|
```
|
|
768
148
|
|
|
769
|
-
|
|
770
|
-
|
|
771
|
-
`analyze`, `doctor`, and `ci` also accept `--report-policy <name>`,
|
|
772
|
-
`--report-scope <paths>`, and `--redact-paths` for shareable evidence artifacts.
|
|
773
|
-
Scope is comma-separated and repo-relative; redaction replaces file paths with
|
|
774
|
-
stable labels. JSON/SARIF include path-safe `reportControls` metadata, and
|
|
775
|
-
Markdown/HTML print path-safe controls banners. Direct `--report-scope` and
|
|
776
|
-
`--redact-paths` flags override the selected preset for a single run.
|
|
777
|
-
|
|
778
|
-
Run `projscan help` for the generated command-by-command support matrix.
|
|
779
|
-
|
|
780
|
-
### Plugin Platform
|
|
149
|
+
Codex CLI:
|
|
781
150
|
|
|
782
|
-
|
|
151
|
+
```toml
|
|
152
|
+
[mcp_servers.projscan]
|
|
153
|
+
command = "npx"
|
|
154
|
+
args = ["-y", "projscan", "mcp"]
|
|
155
|
+
```
|
|
783
156
|
|
|
784
|
-
|
|
157
|
+
Cursor, Windsurf, Cline, Continue, Zed, and other MCP clients can launch the same command:
|
|
785
158
|
|
|
786
159
|
```bash
|
|
787
|
-
projscan
|
|
788
|
-
projscan plugin validate .projscan-plugins/team-radar.projscan-plugin.json
|
|
789
|
-
projscan plugin test .projscan-plugins/team-radar.projscan-plugin.json
|
|
790
|
-
PROJSCAN_PLUGINS_PREVIEW=1 projscan plugin test .projscan-plugins/team-radar.projscan-plugin.json --execute
|
|
791
|
-
PROJSCAN_PLUGINS_PREVIEW=1 projscan doctor --reporter team-radar
|
|
792
|
-
PROJSCAN_PLUGINS_PREVIEW=1 projscan ci --reporter team-radar --min-score 80
|
|
160
|
+
npx -y projscan mcp
|
|
793
161
|
```
|
|
794
162
|
|
|
795
|
-
|
|
796
|
-
|
|
797
|
-
Reporter plugins are intentionally CLI-only. MCP tools keep returning structured JSON-compatible payloads so agents can reason over stable data, while humans can get a polished local report for their team. Custom presentation, team-branded summaries, and white-label reports belong in reporter plugins rather than new core HTML theming flags. See [Plugin Authoring](https://github.com/abhiyoheswaran1/projscan/blob/v4.3.1/docs/PLUGIN-AUTHORING.md) for manifest shape, `render(context)`, validation, and the trust model.
|
|
798
|
-
|
|
799
|
-
### Options
|
|
800
|
-
|
|
801
|
-
| Flag | Description |
|
|
802
|
-
| ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
|
|
803
|
-
| `--format <type>` | Output format: console, json, markdown, sarif, html (command-dependent) |
|
|
804
|
-
| `--config <path>` | Path to a `.projscanrc` config file |
|
|
805
|
-
| `--include-ignored` | Explicitly include files hidden by Git ignore rules |
|
|
806
|
-
| `--scan-env-values` | Explicitly read `.env*` contents during secret checks |
|
|
807
|
-
| `--offline` | Block projscan network-capable features for this run |
|
|
808
|
-
| `--shortcuts` | Print the Mission Control shortcut command index (`start`) |
|
|
809
|
-
| `--shortcuts-json` | Print the Mission Control shortcut command index as JSON (`start`) |
|
|
810
|
-
| `--handoff-prompt` | Print only the concise Mission Control handoff prompt (`start`) |
|
|
811
|
-
| `--next-command` | Print only the current Mission Control cursor command (`start`) |
|
|
812
|
-
| `--next-tool-call` | Print only the current Mission Control cursor MCP tool call as JSON (`start`) |
|
|
813
|
-
| `--ready-tool-calls` | Print the current cursor and remaining MCP-callable proof queue as JSON (`start`) |
|
|
814
|
-
| `--proof-commands` | Print only ready Mission Control proof commands (`start`) |
|
|
815
|
-
| `--checklist` | Print only the Mission Control resume checklist (`start`) |
|
|
816
|
-
| `--resume-json` | Print only the Mission Control resume object as JSON (`start`) |
|
|
817
|
-
| `--handoff-json` | Print only the Mission Control handoff object as JSON (`start`) |
|
|
818
|
-
| `--mission-script` | Print the Mission Control shell script (`start`) |
|
|
819
|
-
| `--save-mission <dir>` | Write the Mission Control bundle to a directory (`start`) |
|
|
820
|
-
| `--mission <dir>` | Read a saved Mission Control bundle and include proof outcome in `start`; repeatable mission selector for `mission-proof` |
|
|
821
|
-
| `--list` | List saved Mission Control bundles with status and update time (`mission-proof`) |
|
|
822
|
-
| `--needs-attention` | Filter `mission-proof --list` to bundles that are not passed |
|
|
823
|
-
| `--mission-status <status>` | Filter `mission-proof --list` by `passed`, `failed`, `running`, `not_run`, or `unknown` |
|
|
824
|
-
| `--latest` | Select the saved Mission Control bundle with the newest `proof-logs/summary.json` (`mission-proof`) |
|
|
825
|
-
| `--all` | Discover `.projscan/mission` and direct child bundles under `.projscan/missions/` (`mission-proof`) |
|
|
826
|
-
| `--baseline <path>` | Compare `mission-proof` with a local manual-run baseline JSON file |
|
|
827
|
-
| `--init-baseline <file>` | Write a local manual-run baseline JSON template (`mission-proof`) |
|
|
828
|
-
| `--add-baseline-run <file>` | Append one measured manual run to a local baseline JSON file (`mission-proof`) |
|
|
829
|
-
| `--check-baseline <file>` | Validate a local manual-run baseline JSON file (`mission-proof`) |
|
|
830
|
-
| `--id <id>` / `--status <status>` | Identify a run added with `--add-baseline-run` (`mission-proof`) |
|
|
831
|
-
| `--minutes-spent`, `--reruns`, `--failed-gates`, `--reviewer-approvals` | Numeric fields for `--add-baseline-run` (`mission-proof`) |
|
|
832
|
-
| `--write <file>` | Write a Markdown or JSON artifact (`mission-proof`, `handoff`) |
|
|
833
|
-
| `--require-passed` | Exit nonzero unless every selected mission bundle passed proof (`mission-proof`) |
|
|
834
|
-
| `--summary` | Print one compact Mission Proof status line (`mission-proof`) |
|
|
835
|
-
| `--task-card` | Print only the Mission Control Markdown task card (`start`) |
|
|
836
|
-
| `--review-gate` | Print only the Mission Control stop-and-review gate (`start`) |
|
|
837
|
-
| `--review-gate-json` | Print only the Mission Control review gate as JSON (`start`) |
|
|
838
|
-
| `--review-policy` | Print only the Mission Control review policy as JSON (`start`) |
|
|
839
|
-
| `--review-replies` | Print only copyable Mission Control reviewer replies (`start`) |
|
|
840
|
-
| `--runbook` | Print only the Mission Control Markdown runbook (`start`) |
|
|
841
|
-
| `--changed-only` | Scope to files changed vs base ref (ci/analyze/doctor) |
|
|
842
|
-
| `--base-ref <ref>` | Git base ref for `--changed-only` (default: origin/main) |
|
|
843
|
-
| `--report-policy <name>` | Use a named report policy preset from config (`analyze`, `doctor`, `ci`) |
|
|
844
|
-
| `--report-scope <paths>` | Comma-separated repo-relative paths to include in exported evidence (`analyze`, `doctor`, `ci`) |
|
|
845
|
-
| `--redact-paths` | Replace file paths in exported evidence with stable labels (`analyze`, `doctor`, `ci`) |
|
|
846
|
-
| `--reporter <name>` | Render `doctor`, `analyze`, or `ci` with a local reporter plugin |
|
|
847
|
-
| `--verbose` | Enable debug output |
|
|
848
|
-
| `--quiet` | Suppress non-essential output |
|
|
849
|
-
| `-V, --version` | Show version |
|
|
850
|
-
| `-h, --help` | Show help |
|
|
851
|
-
|
|
852
|
-
## Health Score
|
|
853
|
-
|
|
854
|
-
Every `projscan doctor` run calculates a health score (0–100) and letter grade:
|
|
855
|
-
|
|
856
|
-
| Grade | Score | Meaning |
|
|
857
|
-
| ----- | ------ | ------------------------------------------ |
|
|
858
|
-
| A | 90–100 | Excellent - project follows best practices |
|
|
859
|
-
| B | 80–89 | Good - minor improvements possible |
|
|
860
|
-
| C | 70–79 | Fair - several issues to address |
|
|
861
|
-
| D | 60–69 | Poor - significant issues found |
|
|
862
|
-
| F | < 60 | Critical - major issues need attention |
|
|
863
|
-
|
|
864
|
-
Generate a badge for your README:
|
|
163
|
+
Add `--watch` if the client supports `notifications/file_changed`:
|
|
865
164
|
|
|
866
165
|
```bash
|
|
867
|
-
projscan
|
|
166
|
+
npx -y projscan mcp --watch
|
|
868
167
|
```
|
|
869
168
|
|
|
870
|
-
|
|
871
|
-
|
|
872
|
-
|
|
873
|
-
|
|
874
|
-
|
|
875
|
-
|
|
876
|
-
|
|
877
|
-
|
|
878
|
-
|
|
879
|
-
|
|
880
|
-
|
|
881
|
-
|
|
882
|
-
|
|
883
|
-
|
|
884
|
-
|
|
885
|
-
|
|
886
|
-
|
|
887
|
-
|
|
888
|
-
|
|
889
|
-
|
|
890
|
-
|
|
891
|
-
`
|
|
892
|
-
|
|
893
|
-
|
|
894
|
-
|
|
895
|
-
|
|
896
|
-
|
|
897
|
-
|
|
898
|
-
|
|
899
|
-
|
|
900
|
-
|
|
901
|
-
|
|
902
|
-
|
|
903
|
-
|
|
904
|
-
`projscan
|
|
905
|
-
|
|
906
|
-
|
|
907
|
-
|
|
908
|
-
|
|
169
|
+
### Agent Questions
|
|
170
|
+
|
|
171
|
+
| Agent question | CLI or MCP route |
|
|
172
|
+
| -------------------------------------------- | -------------------------------------------------------------------------------- |
|
|
173
|
+
| Which files implement auth? | `projscan search "auth" --format json` |
|
|
174
|
+
| Who imports this file? | `projscan semantic-graph --query importers --file src/auth/jwt.ts --format json` |
|
|
175
|
+
| What breaks if I rename this symbol? | `projscan impact --symbol buildCodeGraph --format json` |
|
|
176
|
+
| What should I fix first? | `projscan bug-hunt --format json` |
|
|
177
|
+
| Which files have high risk and low coverage? | `projscan coverage --format json` |
|
|
178
|
+
| What should my agent do next? | `projscan workplan --format json` |
|
|
179
|
+
| Which proof belongs in this PR? | `projscan evidence-pack --pr-comment` |
|
|
180
|
+
| Is this branch ready to merge? | `projscan preflight --mode before_merge --format json` |
|
|
181
|
+
|
|
182
|
+
## Command Map
|
|
183
|
+
|
|
184
|
+
| Command | Use it when you need |
|
|
185
|
+
| ------------------------- | -------------------------------------------------------------------------- |
|
|
186
|
+
| `projscan start` | first-60-seconds orientation, routing, and Mission Control |
|
|
187
|
+
| `projscan understand` | cited repo map, runtime flows, public contracts, and change readiness |
|
|
188
|
+
| `projscan preflight` | proceed, caution, or block gate for edit, commit, or merge |
|
|
189
|
+
| `projscan evidence-pack` | PR-ready proof with risks, owners, and next commands |
|
|
190
|
+
| `projscan bug-hunt` | ranked fix queue from health, hotspots, session, and preflight evidence |
|
|
191
|
+
| `projscan workplan` | ordered agent tasks with proof and handoff text |
|
|
192
|
+
| `projscan doctor` | project health, tooling gaps, dead code, and supply-chain signals |
|
|
193
|
+
| `projscan review` | one-call PR review from structural diff, risk, cycles, functions, and deps |
|
|
194
|
+
| `projscan impact` | blast radius for a file or symbol before rename, delete, or upgrade |
|
|
195
|
+
| `projscan semantic-graph` | imports, exports, importers, symbol definitions, and package importers |
|
|
196
|
+
| `projscan dataflow` | framework-aware source-to-sink risks |
|
|
197
|
+
| `projscan hotspots` | churn, complexity, ownership, and coverage risk ranking |
|
|
198
|
+
| `projscan coverage` | high-risk files with weak test coverage |
|
|
199
|
+
| `projscan dependencies` | dependency inventory, license summary, and risk notes |
|
|
200
|
+
| `projscan upgrade <pkg>` | offline upgrade impact from changelog and importer evidence |
|
|
201
|
+
| `projscan audit` | normalized `npm audit` findings and SARIF |
|
|
202
|
+
| `projscan coordinate` | collisions, claims, and merge-risk across worktrees |
|
|
203
|
+
| `projscan plugin` | local analyzer and reporter plugin workflow |
|
|
204
|
+
| `projscan privacy-check` | local scan boundary, telemetry, ignore rules, and network-capable paths |
|
|
205
|
+
| `projscan mcp` | MCP server over stdio |
|
|
206
|
+
|
|
207
|
+
Run the generated command help when you need flags:
|
|
909
208
|
|
|
910
|
-
|
|
911
|
-
|
|
912
|
-
|
|
913
|
-
|
|
914
|
-
Detects npm/yarn workspaces, `pnpm-workspace.yaml`, Lerna, modern Nx (`nx.json#workspaceLayout` + `project.json` scan), legacy Nx (`workspace.json#projects`), and a `packages/*` + `apps/*` + `libs/*` fallback. `projscan workspaces` lists every package; `--package <name>` (or the `package` MCP arg) scopes most commands to a single workspace.
|
|
915
|
-
|
|
916
|
-
Cache version bumped 2 → 3 in 0.11 (CC stored per file). Existing v2 caches are discarded on first run and rebuilt automatically.
|
|
917
|
-
|
|
918
|
-
## Performance
|
|
919
|
-
|
|
920
|
-
Reference numbers from `npm run bench` on an Apple M3 Pro running Node 25 (cold / warm cache, milliseconds), refreshed for 1.5.0:
|
|
921
|
-
|
|
922
|
-
| Repo | Files | analyze | doctor | hotspots | coupling | search |
|
|
923
|
-
| ---------------- | ----- | --------- | --------- | --------- | --------- | --------- |
|
|
924
|
-
| projscan itself | ~120 | 650 / 576 | 659 / 574 | 794 / 622 | 405 / 186 | 485 / 277 |
|
|
925
|
-
| Synthetic medium | 500 | 284 / 257 | 277 / 255 | 300 / 278 | 224 / 177 | 239 / 196 |
|
|
926
|
-
|
|
927
|
-
For real-world numbers against larger codebases, `npm run bench:references` shallow-clones TypeScript, Django, and kubernetes/client-go into `.bench-cache/` (gitignored) and runs the same suite. First run is network-bound; later runs reuse the cache. Restrict to one target with `-- --only ts|django|k8s-client-go`.
|
|
928
|
-
|
|
929
|
-
Run `npm run bench` against your own machine to recalibrate.
|
|
930
|
-
|
|
931
|
-
- **Local by default** — core scans run without network; `audit`, registry checks, opt-in telemetry, and optional semantic embeddings are explicit network-capable paths
|
|
932
|
-
- **7 direct runtime dependencies** — grammar packages are build-time sources, not global-install dependencies
|
|
933
|
-
- **~21 MB of vendored tree-sitter WASM grammars**, broken down:
|
|
934
|
-
|
|
935
|
-
| Vendored file | Size | Languages |
|
|
936
|
-
| -------------------------- | ------: | ---------------------------------- |
|
|
937
|
-
| `web-tree-sitter.wasm` | ~190 KB | runtime, all tree-sitter languages |
|
|
938
|
-
| `tree-sitter-python.wasm` | ~450 KB | Python |
|
|
939
|
-
| `tree-sitter-go.wasm` | ~210 KB | Go |
|
|
940
|
-
| `tree-sitter-java.wasm` | ~405 KB | Java |
|
|
941
|
-
| `tree-sitter-ruby.wasm` | ~2.0 MB | Ruby |
|
|
942
|
-
| `tree-sitter-rust.wasm` | ~1.1 MB | Rust |
|
|
943
|
-
| `tree-sitter-php.wasm` | ~785 KB | PHP |
|
|
944
|
-
| `tree-sitter-c_sharp.wasm` | ~5.2 MB | C# |
|
|
945
|
-
| `tree-sitter-cpp.wasm` | ~3.3 MB | C, C++ |
|
|
946
|
-
| `tree-sitter-kotlin.wasm` | ~3.9 MB | Kotlin |
|
|
947
|
-
| `tree-sitter-swift.wasm` | ~3.6 MB | Swift |
|
|
948
|
-
|
|
949
|
-
JavaScript and TypeScript use the bundled `@babel/parser` instead of a tree-sitter grammar, so they don't appear in this table.
|
|
950
|
-
|
|
951
|
-
## Optional features
|
|
952
|
-
|
|
953
|
-
projscan keeps the install slim by default. One feature is gated behind an optional peer dependency:
|
|
954
|
-
|
|
955
|
-
- **Semantic search** uses local embeddings via `@xenova/transformers` (~25 MB quantized model, downloads on first use, then cached). Without it, `projscan search` falls back to BM25 lexical search and prints a one-line tip pointing here. Install when you want it:
|
|
956
|
-
|
|
957
|
-
```bash
|
|
958
|
-
npm install @xenova/transformers
|
|
959
|
-
projscan search "cache invalidation" --semantic
|
|
960
|
-
```
|
|
961
|
-
|
|
962
|
-
See [AI Agent Integration → Semantic search](#semantic-search-090-opt-in) for details.
|
|
963
|
-
|
|
964
|
-
## Security & trust
|
|
965
|
-
|
|
966
|
-
projscan reads your source code so it can be useful; it does not send your source code anywhere. This section explains exactly what's happening, because supply-chain scanners (Socket, Snyk, npm audit, etc.) will flag a few patterns in any tool that wraps `git` and `npm`, and we want you to be able to verify our claims rather than trust them.
|
|
967
|
-
|
|
968
|
-
### What projscan does NOT do
|
|
969
|
-
|
|
970
|
-
- **Send your source code off-machine.** File contents stay local; AST analysis runs in-process. The only projscan-owned network path is explicit opt-in telemetry, and those events are anonymous product-health buckets, not code or scan results.
|
|
971
|
-
- **Read environment variables for secrets.** `process.env` is forwarded to child processes (`git`, `npm`) so they can find their `PATH` — we never inspect `.env` values, API keys, or session tokens.
|
|
972
|
-
- **Execute command-line arguments as code.** Core CLI and MCP arguments are parsed as data, and projscan does not compose shell strings from user input. Local plugins are the explicit trust boundary: `projscan plugin test` is static by default, and projscan imports local modules declared in `.projscan-plugins/*.projscan-plugin.json` only when execution is explicitly requested with `--execute` and `PROJSCAN_PLUGINS_PREVIEW=1` is set.
|
|
973
|
-
- **Phone home silently.** Telemetry is off by default. If you explicitly opt in with `projscan telemetry enable` or the interactive `projscan init team` prompt, projscan sends only anonymous product-health events; it never sends source code, file paths, repo names, branch names, package names, usernames, raw findings, or secrets. See [TELEMETRY.md](TELEMETRY.md).
|
|
974
|
-
- **Modify your repo without an explicit command.** `projscan fix` is the only command that writes to source files, and only when invoked. The cache directory `.projscan-cache/` is local-only and gitignored.
|
|
975
|
-
|
|
976
|
-
### What projscan DOES do, and what it costs
|
|
977
|
-
|
|
978
|
-
| Action | When | Network? | Notes |
|
|
979
|
-
| ---------------------- | -------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
|
|
980
|
-
| Read source files | every command | no | parses with tree-sitter / Babel; results cached at `.projscan-cache/` |
|
|
981
|
-
| Spawn `git` | `hotspots`, `pr-diff`, `review`, `diff` | git itself may fetch if you run `git fetch` separately; **projscan never invokes `git fetch`** | `env: process.env` is passed so `git` can find its config |
|
|
982
|
-
| Spawn `npm audit` | `audit` only | yes — by `npm`, not by projscan | runs against your local lockfile |
|
|
983
|
-
| Scan supply-chain IOCs | `doctor`, `preflight`, release validation | no | checks manifests, lockfiles, hidden editor hooks, and suspicious install-time payloads against bundled indicators |
|
|
984
|
-
| Anonymous telemetry | only after `projscan telemetry enable` or accepting the `projscan init team` prompt | yes — projscan-owned, default off | sends product-health buckets only; see [TELEMETRY.md](TELEMETRY.md) |
|
|
985
|
-
| Load local plugins | only with `PROJSCAN_PLUGINS_PREVIEW=1` and an execution path such as `--execute`, `doctor`, `ci`, or `analyze` | no | imports local JS modules declared in `.projscan-plugins/`; only enable plugins you trust |
|
|
986
|
-
| Load wasm grammars | first parse of a non-JS file | no | served from `dist/grammars/` inside the package; no fetch |
|
|
987
|
-
| Build embeddings | semantic search opt-in only | yes — by `@xenova/transformers`, on first use | model cached locally after first download; remove the peer dep to remove this code path entirely |
|
|
988
|
-
|
|
989
|
-
### Patterns supply-chain scanners flag, and why they're benign here
|
|
990
|
-
|
|
991
|
-
projscan's [Socket report](https://socket.dev/npm/package/projscan) currently shows four supply-chain alerts. Each alert maps to one of these code paths:
|
|
992
|
-
|
|
993
|
-
- **"Network access"** — comes from `web-tree-sitter`'s internal API surface; we feed it local wasm files at `dist/grammars/`. No outbound traffic.
|
|
994
|
-
- **"Dynamic require" / runtime import** — optional dependencies lazy-load from literal module names; opt-in local plugins load validated manifest module paths under `.projscan-plugins/`. Plugin execution is local code execution by design, gated by `PROJSCAN_PLUGINS_PREVIEW=1`.
|
|
995
|
-
- **"Environment variable access"** — `env: process.env` is forwarded to child processes (`git`, `npm audit`). We don't read env contents.
|
|
996
|
-
- **"URL strings"** — the strings are documentation references (`github.com`, `registry.npmjs.org`) shown in error messages and CHANGELOGs, not runtime fetch targets.
|
|
997
|
-
|
|
998
|
-
### Audit it yourself
|
|
999
|
-
|
|
1000
|
-
- **Source is open** at [github.com/abhiyoheswaran1/projscan](https://github.com/abhiyoheswaran1/projscan). The npm tarball matches the `dist/` produced by `npm run build` at the matching tag.
|
|
1001
|
-
- **Public API surface is locked** by `scripts/check-stability.mjs`, which runs in CI on every PR and fails on any rename or removal of an MCP tool, CLI command, or exit code. See [`docs/STABILITY.md`](https://github.com/abhiyoheswaran1/projscan/blob/v4.3.1/docs/STABILITY.md).
|
|
1002
|
-
- **Run it offline:** `npm install -g projscan` followed by anything except `audit` and `--mode semantic` works without network.
|
|
1003
|
-
- **Drop privilege further:** in CI, run projscan in a sandbox that disallows network egress; everything except `audit` will pass.
|
|
1004
|
-
|
|
1005
|
-
## Dogfooding
|
|
1006
|
-
|
|
1007
|
-
projscan runs against itself in CI on every PR. The dogfood loop is the most direct evidence we can offer that the tool works on real code instead of synthetic fixtures alone.
|
|
1008
|
-
|
|
1009
|
-
```sh
|
|
1010
|
-
# .github/workflows/ci.yml — runs after the unit tests
|
|
1011
|
-
- run: node dist/cli/index.js ci --min-score 90
|
|
209
|
+
```bash
|
|
210
|
+
projscan help
|
|
211
|
+
projscan <command> --help
|
|
1012
212
|
```
|
|
1013
213
|
|
|
1014
|
-
|
|
1015
|
-
|
|
1016
|
-
| Metric | Value |
|
|
1017
|
-
| ----------------- | ------------------------------------------------------------------------------------------------ |
|
|
1018
|
-
| Health score | **A (100 / 100)** |
|
|
1019
|
-
| Open issues | 0 errors, 0 warnings, 0 info |
|
|
1020
|
-
| Circular imports | 0 |
|
|
1021
|
-
| Top hotspot | `src/reporters/consoleReporter.ts` (CC 288, 1108 lines) — known refactor candidate, not a defect |
|
|
1022
|
-
| Dogfood threshold | `--min-score 90` (CI fails below this) |
|
|
1023
|
-
|
|
1024
|
-
The `--min-score 90` threshold is deliberately tight: a regression that drops the score by more than ten points fails the build. The current ten-point margin (90 → 100) is for room to breathe, not slack.
|
|
214
|
+
## Output Formats
|
|
1025
215
|
|
|
1026
|
-
|
|
216
|
+
Commands support `console`, `json`, `markdown`, `sarif`, and `html` where those formats fit the command.
|
|
1027
217
|
|
|
1028
|
-
```
|
|
218
|
+
```bash
|
|
219
|
+
projscan analyze --format json
|
|
220
|
+
projscan doctor --format markdown
|
|
221
|
+
projscan ci --format sarif > projscan.sarif
|
|
1029
222
|
projscan evidence-pack --pr-comment
|
|
1030
|
-
projscan
|
|
1031
|
-
projscan feedback add --file .projscan-feedback.json --repo api --pr https://github.com/acme/api/pull/42 --reviewer @alice --useful true --minutes-saved 10 --owner-routing-clear true --next-command-clear true
|
|
1032
|
-
projscan feedback summary --file .projscan-feedback.json --format json
|
|
1033
|
-
projscan dogfood --repo ../api --repo ../web --repo ../worker --feedback .projscan-feedback.json --format json
|
|
1034
|
-
projscan trial --repo ../api --repo ../web --repo ../worker --feedback .projscan-feedback.json --format json
|
|
223
|
+
projscan mission-proof --write reports/mission-proof.md
|
|
1035
224
|
```
|
|
1036
225
|
|
|
1037
|
-
|
|
1038
|
-
|
|
1039
|
-
The hotspots projscan finds in itself are real signals — the reporters in particular have grown organically across releases and remain future refactor candidates in the roadmap. We choose to ship the signal honestly rather than tune the score to hide it.
|
|
1040
|
-
|
|
1041
|
-
## CI/CD Integration
|
|
1042
|
-
|
|
1043
|
-
Use `projscan ci` to gate your pipelines:
|
|
226
|
+
Use scoped and redacted reports when evidence leaves the repo:
|
|
1044
227
|
|
|
1045
228
|
```bash
|
|
1046
|
-
projscan
|
|
1047
|
-
projscan
|
|
1048
|
-
projscan
|
|
1049
|
-
projscan ci --format sarif > projscan.sarif # SARIF for Code Scanning
|
|
1050
|
-
```
|
|
1051
|
-
|
|
1052
|
-
<img src="https://raw.githubusercontent.com/abhiyoheswaran1/projscan/v4.3.1/docs/npx%20projscan%20ci%20--min-score%2070.gif" alt="npx projscan ci --min-score 70" width="700">
|
|
1053
|
-
|
|
1054
|
-
### GitHub Action (recommended)
|
|
1055
|
-
|
|
1056
|
-
projscan ships a first-party GitHub Action that installs, runs, and uploads SARIF to **GitHub Code Scanning** in one step:
|
|
1057
|
-
|
|
1058
|
-
```yaml
|
|
1059
|
-
# .github/workflows/projscan.yml
|
|
1060
|
-
name: ProjScan
|
|
1061
|
-
on:
|
|
1062
|
-
push: { branches: [main] }
|
|
1063
|
-
pull_request: { branches: [main] }
|
|
1064
|
-
|
|
1065
|
-
permissions:
|
|
1066
|
-
contents: read
|
|
1067
|
-
security-events: write # required for SARIF upload
|
|
1068
|
-
|
|
1069
|
-
jobs:
|
|
1070
|
-
scan:
|
|
1071
|
-
runs-on: ubuntu-latest
|
|
1072
|
-
steps:
|
|
1073
|
-
- uses: actions/checkout@v4
|
|
1074
|
-
with: { fetch-depth: 0 } # needed for --changed-only
|
|
1075
|
-
- uses: actions/setup-node@v4
|
|
1076
|
-
with: { node-version: 20 }
|
|
1077
|
-
- uses: abhiyoheswaran1/projscan@v1
|
|
1078
|
-
with:
|
|
1079
|
-
min-score: '70'
|
|
1080
|
-
changed-only: 'true'
|
|
229
|
+
projscan analyze --report-scope src/api --redact-paths --format json
|
|
230
|
+
projscan analyze --report-scope "src/api,packages/backend" --redact-paths --format json
|
|
231
|
+
projscan doctor --report-policy apiEvidence --format markdown
|
|
1081
232
|
```
|
|
1082
233
|
|
|
1083
|
-
|
|
1084
|
-
|
|
1085
|
-
Findings appear in the **Security → Code scanning** tab, annotated on files and lines. PRs get inline annotations on changed lines.
|
|
234
|
+
## Configuration
|
|
1086
235
|
|
|
1087
|
-
|
|
1088
|
-
|
|
1089
|
-
If you'd rather not upload SARIF, [`.github/projscan-ci.yml`](.github/projscan-ci.yml) is a drop-in workflow that runs projscan and posts a markdown health report as a PR comment.
|
|
1090
|
-
|
|
1091
|
-
## Configuration (`.projscanrc`)
|
|
1092
|
-
|
|
1093
|
-
Drop a `.projscanrc.json` at your repo root to set defaults - CLI flags always win over config. A `"projscan"` key in `package.json` and plain `.projscanrc` are also supported.
|
|
236
|
+
Create a `.projscanrc.json` when repo defaults should live in source control:
|
|
1094
237
|
|
|
1095
238
|
```json
|
|
1096
239
|
{
|
|
@@ -1102,7 +245,7 @@ Drop a `.projscanrc.json` at your repo root to set defaults - CLI flags always w
|
|
|
1102
245
|
"scanEnvValues": false,
|
|
1103
246
|
"offline": false
|
|
1104
247
|
},
|
|
1105
|
-
"disableRules": ["
|
|
248
|
+
"disableRules": ["large-*"],
|
|
1106
249
|
"severityOverrides": {
|
|
1107
250
|
"missing-prettier": "info"
|
|
1108
251
|
},
|
|
@@ -1111,426 +254,135 @@ Drop a `.projscanrc.json` at your repo root to set defaults - CLI flags always w
|
|
|
1111
254
|
"reportScope": ["src/api", "packages/backend"],
|
|
1112
255
|
"redactPaths": true
|
|
1113
256
|
}
|
|
1114
|
-
},
|
|
1115
|
-
"hotspots": {
|
|
1116
|
-
"limit": 20,
|
|
1117
|
-
"since": "6 months ago"
|
|
1118
257
|
}
|
|
1119
258
|
}
|
|
1120
259
|
```
|
|
1121
260
|
|
|
1122
|
-
|
|
1123
|
-
|
|
1124
|
-
- `minScore` - default `ci` threshold (0–100)
|
|
1125
|
-
- `baseRef` - default base ref for `--changed-only`
|
|
1126
|
-
- `ignore` - extra glob patterns added to the built-in ignore list
|
|
1127
|
-
- `scan.includeIgnored` - opt into scanning files hidden by Git ignore rules
|
|
1128
|
-
- `scan.scanEnvValues` - opt into reading `.env*` contents during secret checks
|
|
1129
|
-
- `scan.offline` - block projscan network-capable features by default
|
|
1130
|
-
- `disableRules` - silence rules by id; supports wildcard `prefix-*`
|
|
1131
|
-
- `severityOverrides` - remap a rule's severity (`info` / `warning` / `error`)
|
|
1132
|
-
- `reportPolicies.<name>` - reusable evidence export preset for `analyze`, `doctor`, and `ci`
|
|
1133
|
-
- `hotspots.limit` / `hotspots.since` - defaults for the `hotspots` command
|
|
1134
|
-
- `monorepo.importPolicy` - cross-package import allow/deny rules in monorepos _(0.14+)_
|
|
1135
|
-
|
|
1136
|
-
See [`docs/GUIDE.md` -> Configuration](https://github.com/abhiyoheswaran1/projscan/blob/v4.3.1/docs/GUIDE.md#configuration-projscanrc) for the full reference (field types, validation behavior, embedding config in `package.json`, monorepo `importPolicy` semantics).
|
|
1137
|
-
|
|
1138
|
-
## Tracking Health Over Time
|
|
1139
|
-
|
|
1140
|
-
Save a baseline and compare later:
|
|
1141
|
-
|
|
1142
|
-
```bash
|
|
1143
|
-
projscan diff --save-baseline # Save current score
|
|
1144
|
-
# ... make changes ...
|
|
1145
|
-
projscan diff # Compare against baseline
|
|
1146
|
-
projscan diff --format markdown # Markdown diff for PRs
|
|
1147
|
-
```
|
|
1148
|
-
|
|
1149
|
-
<img src="https://raw.githubusercontent.com/abhiyoheswaran1/projscan/v4.3.1/docs/npx%20projscan%20diff%20--save-baseline.gif" alt="npx projscan diff --save-baseline" width="700">
|
|
1150
|
-
|
|
1151
|
-
## Hotspots - Where to Fix First
|
|
1152
|
-
|
|
1153
|
-
A flat health score doesn't tell you what to do. **`projscan hotspots`** combines `git log` churn, file complexity, open issues, recency, and **ownership** into a single risk score per file, so you know where refactoring or review will pay off.
|
|
1154
|
-
|
|
1155
|
-
<img src="https://abhiyoheswaran.com/images/projscan/hotspots-poster.png" alt="projscan hotspots output ranking files by composite risk score" width="700">
|
|
261
|
+
Config docs live in [docs/GUIDE.md](docs/GUIDE.md#configuration-projscanrc).
|
|
1156
262
|
|
|
1157
|
-
|
|
1158
|
-
projscan hotspots # Top 10 hotspots
|
|
1159
|
-
projscan hotspots --limit 20
|
|
1160
|
-
projscan hotspots --since "6 months ago"
|
|
1161
|
-
projscan hotspots --format json # Machine-readable for dashboards
|
|
1162
|
-
projscan hotspots --format markdown # Drop into a PR or tech-debt ticket
|
|
1163
|
-
```
|
|
1164
|
-
|
|
1165
|
-
Hotspot ranking follows the classic Feathers "churn × complexity" heuristic with boosts for files that fail `projscan doctor`, changed recently, or show **bus factor 1** (single-author + high churn). Falls back gracefully outside a git repo.
|
|
263
|
+
## CI
|
|
1166
264
|
|
|
1167
|
-
|
|
265
|
+
Use `projscan ci` to gate pull requests:
|
|
1168
266
|
|
|
1169
267
|
```bash
|
|
1170
|
-
projscan
|
|
268
|
+
projscan ci --min-score 80
|
|
269
|
+
projscan ci --changed-only
|
|
270
|
+
projscan ci --format sarif > projscan.sarif
|
|
1171
271
|
```
|
|
1172
272
|
|
|
1173
|
-
|
|
273
|
+
GitHub Actions example:
|
|
1174
274
|
|
|
1175
|
-
|
|
1176
|
-
|
|
1177
|
-
|
|
1178
|
-
|
|
1179
|
-
|
|
1180
|
-
projscan diff # Shows which hotspots rose / fell
|
|
1181
|
-
```
|
|
1182
|
-
|
|
1183
|
-
The baseline file now captures top hotspots too, so `diff` surfaces files that are **getting worse** alongside new issues.
|
|
1184
|
-
|
|
1185
|
-
## Dependency Health
|
|
1186
|
-
|
|
1187
|
-
projscan ships focused commands for checking your dependency graph. Drift and upgrade previews run **offline** by default; `audit` wraps `npm audit` and can contact the npm registry.
|
|
1188
|
-
|
|
1189
|
-
```bash
|
|
1190
|
-
projscan outdated # Which declared deps drift from what's installed?
|
|
1191
|
-
projscan outdated --format json # Machine-readable drift report
|
|
1192
|
-
projscan audit # Wrap npm audit; normalized, SARIF-ready
|
|
1193
|
-
projscan audit --format sarif > a.sarif # Upload to GitHub Code Scanning
|
|
1194
|
-
projscan upgrade chalk # What breaks if I bump chalk? Who imports it?
|
|
1195
|
-
projscan upgrade chalk --format markdown # Paste-ready review comment
|
|
1196
|
-
```
|
|
1197
|
-
|
|
1198
|
-
### What each one tells you
|
|
1199
|
-
|
|
1200
|
-
- **`outdated`** - reads `package.json` and `node_modules/<pkg>/package.json` to classify drift (`major` / `minor` / `patch` / `same` / `unknown`). No network.
|
|
1201
|
-
- **`audit`** - wraps `npm audit --json`, normalizes the output, and emits SARIF with per-finding rules anchored to `package.json`. Graceful fallback message for yarn/pnpm projects.
|
|
1202
|
-
- **`upgrade <pkg>`** - reads `node_modules/<pkg>/CHANGELOG.md` for npm packages or Python manifests/lockfiles for Python packages, flags available breaking-change markers, and lists every file in your repo that imports the package. All offline unless `--check-registry` is passed for npm.
|
|
1203
|
-
|
|
1204
|
-
### Unused dependencies (automatic in `doctor`)
|
|
1205
|
-
|
|
1206
|
-
`projscan doctor` now flags declared dependencies that are never imported from source. Each finding is anchored to the **exact line in `package.json`** so GitHub Code Scanning PR annotations land in the right place.
|
|
1207
|
-
|
|
1208
|
-
Implicit-use packages (typescript, eslint/prettier plugins, `@types/*`, and anything invoked from a `package.json` script) are allowlisted. Override via `.projscanrc` → `disableRules` if projscan flags something that is used but not imported.
|
|
1209
|
-
|
|
1210
|
-
## Coverage × Hotspots - Scariest Untested Files
|
|
275
|
+
```yaml
|
|
276
|
+
name: ProjScan
|
|
277
|
+
on:
|
|
278
|
+
pull_request:
|
|
279
|
+
branches: [main]
|
|
1211
280
|
|
|
1212
|
-
|
|
281
|
+
permissions:
|
|
282
|
+
contents: read
|
|
283
|
+
security-events: write
|
|
1213
284
|
|
|
1214
|
-
|
|
1215
|
-
|
|
1216
|
-
|
|
1217
|
-
|
|
285
|
+
jobs:
|
|
286
|
+
scan:
|
|
287
|
+
runs-on: ubuntu-latest
|
|
288
|
+
steps:
|
|
289
|
+
- uses: actions/checkout@v4
|
|
290
|
+
with: { fetch-depth: 0 }
|
|
291
|
+
- uses: actions/setup-node@v4
|
|
292
|
+
with: { node-version: 24 }
|
|
293
|
+
- uses: abhiyoheswaran1/projscan@v1
|
|
294
|
+
with:
|
|
295
|
+
min-score: '80'
|
|
296
|
+
changed-only: 'true'
|
|
1218
297
|
```
|
|
1219
298
|
|
|
1220
|
-
|
|
1221
|
-
|
|
1222
|
-
**Which coverage files are supported:**
|
|
1223
|
-
|
|
1224
|
-
- `coverage/lcov.info` (lcov - Vitest, Jest, c8)
|
|
1225
|
-
- `coverage/coverage-final.json` (Istanbul per-file detail)
|
|
1226
|
-
- `coverage/coverage-summary.json` (Istanbul summary)
|
|
299
|
+
## Plugins
|
|
1227
300
|
|
|
1228
|
-
|
|
301
|
+
Local plugins let teams add project-specific analyzer rules and custom human reports without changing projscan core.
|
|
1229
302
|
|
|
1230
|
-
###
|
|
1231
|
-
|
|
1232
|
-
`projscan doctor` now flags source files whose exports nothing imports - dead code left over from refactors or utilities that were never wired up. Respects `package.json` public entry points (`main`, `exports`, `bin`, `types`), skips test files and barrel (`index`) files.
|
|
1233
|
-
|
|
1234
|
-
## AI Agent Integration (MCP)
|
|
1235
|
-
|
|
1236
|
-
Use MCP when an AI coding agent should call projscan directly. `projscan mcp` starts an [MCP](https://modelcontextprotocol.io) server over stdio and exposes the same local proof behind the daily workflows: repo context, impact, hotspots, review gates, and next commands.
|
|
1237
|
-
|
|
1238
|
-
<img src="https://raw.githubusercontent.com/abhiyoheswaran1/projscan/v4.3.1/docs/projscan-agent-demo.gif" alt="projscan answering two agent questions: what breaks if I rename buildCodeGraph (impact analysis with definitions, direct callers, transitive reach), and where should I fix first (ranked hotspots with cyclomatic complexity)" width="700">
|
|
1239
|
-
|
|
1240
|
-
Two common agent questions: _"What breaks if I rename `buildCodeGraph`?"_ → 31 direct callers, 97 files reachable. _"Where should I fix first?"_ → ranked hotspots with AST cyclomatic complexity, churn, and ownership signals.
|
|
1241
|
-
|
|
1242
|
-
### Claude Code
|
|
1243
|
-
|
|
1244
|
-
One-liner — adds projscan as an MCP server in the current project:
|
|
303
|
+
### Load local plugins
|
|
1245
304
|
|
|
1246
305
|
```bash
|
|
1247
|
-
|
|
1248
|
-
|
|
1249
|
-
|
|
1250
|
-
|
|
1251
|
-
|
|
1252
|
-
Add to `~/.codex/config.toml`:
|
|
1253
|
-
|
|
1254
|
-
```toml
|
|
1255
|
-
[mcp_servers.projscan]
|
|
1256
|
-
command = "npx"
|
|
1257
|
-
args = ["-y", "projscan", "mcp"]
|
|
1258
|
-
```
|
|
1259
|
-
|
|
1260
|
-
Restart `codex` and the tool surface (`projscan_semantic_graph`, `projscan_review`, …) appears alongside Codex's built-ins.
|
|
1261
|
-
|
|
1262
|
-
### Gemini CLI (Google)
|
|
1263
|
-
|
|
1264
|
-
Add to `~/.gemini/settings.json`:
|
|
1265
|
-
|
|
1266
|
-
```json
|
|
1267
|
-
{
|
|
1268
|
-
"mcpServers": {
|
|
1269
|
-
"projscan": {
|
|
1270
|
-
"command": "npx",
|
|
1271
|
-
"args": ["-y", "projscan", "mcp"]
|
|
1272
|
-
}
|
|
1273
|
-
}
|
|
1274
|
-
}
|
|
1275
|
-
```
|
|
1276
|
-
|
|
1277
|
-
### Cursor
|
|
1278
|
-
|
|
1279
|
-
Add to `~/.cursor/mcp.json` (global) or `.cursor/mcp.json` (per-project):
|
|
1280
|
-
|
|
1281
|
-
```json
|
|
1282
|
-
{
|
|
1283
|
-
"mcpServers": {
|
|
1284
|
-
"projscan": {
|
|
1285
|
-
"command": "npx",
|
|
1286
|
-
"args": ["-y", "projscan", "mcp"]
|
|
1287
|
-
}
|
|
1288
|
-
}
|
|
1289
|
-
}
|
|
1290
|
-
```
|
|
1291
|
-
|
|
1292
|
-
### Windsurf
|
|
1293
|
-
|
|
1294
|
-
Add to `~/.codeium/windsurf/mcp_config.json`:
|
|
1295
|
-
|
|
1296
|
-
```json
|
|
1297
|
-
{
|
|
1298
|
-
"mcpServers": {
|
|
1299
|
-
"projscan": {
|
|
1300
|
-
"command": "npx",
|
|
1301
|
-
"args": ["-y", "projscan", "mcp"]
|
|
1302
|
-
}
|
|
1303
|
-
}
|
|
1304
|
-
}
|
|
1305
|
-
```
|
|
1306
|
-
|
|
1307
|
-
### Cline (VS Code extension)
|
|
1308
|
-
|
|
1309
|
-
In Cline's MCP settings panel (or the underlying `cline_mcp_settings.json`):
|
|
1310
|
-
|
|
1311
|
-
```json
|
|
1312
|
-
{
|
|
1313
|
-
"mcpServers": {
|
|
1314
|
-
"projscan": {
|
|
1315
|
-
"command": "npx",
|
|
1316
|
-
"args": ["-y", "projscan", "mcp"]
|
|
1317
|
-
}
|
|
1318
|
-
}
|
|
1319
|
-
}
|
|
306
|
+
projscan plugin list
|
|
307
|
+
projscan plugin validate .projscan-plugins/team-radar.projscan-plugin.json
|
|
308
|
+
projscan plugin test .projscan-plugins/team-radar.projscan-plugin.json
|
|
309
|
+
PROJSCAN_PLUGINS_PREVIEW=1 projscan doctor --reporter team-radar
|
|
1320
310
|
```
|
|
1321
311
|
|
|
1322
|
-
|
|
312
|
+
Run `projscan help` for the generated command-by-command support matrix.
|
|
1323
313
|
|
|
1324
|
-
|
|
314
|
+
<img src="docs/projscan-reporter-plugin.png" alt="projscan reporter plugin rendering a team health report" width="760">
|
|
1325
315
|
|
|
1326
|
-
|
|
1327
|
-
mcpServers:
|
|
1328
|
-
- name: projscan
|
|
1329
|
-
command: npx
|
|
1330
|
-
args:
|
|
1331
|
-
- -y
|
|
1332
|
-
- projscan
|
|
1333
|
-
- mcp
|
|
1334
|
-
```
|
|
316
|
+
Plugin docs:
|
|
1335
317
|
|
|
1336
|
-
|
|
318
|
+
- [Plugin Authoring](docs/PLUGIN-AUTHORING.md)
|
|
319
|
+
- [Plugin Gallery](docs/PLUGIN-GALLERY.md)
|
|
320
|
+
- [2.0 Migration Guide](docs/2.0-MIGRATION.md)
|
|
321
|
+
- [Manifest Schema](docs/plugin.schema.json)
|
|
1337
322
|
|
|
1338
|
-
|
|
323
|
+
## Supported Repos
|
|
1339
324
|
|
|
1340
|
-
|
|
1341
|
-
{
|
|
1342
|
-
"context_servers": {
|
|
1343
|
-
"projscan": {
|
|
1344
|
-
"command": {
|
|
1345
|
-
"path": "npx",
|
|
1346
|
-
"args": ["-y", "projscan", "mcp"]
|
|
1347
|
-
}
|
|
1348
|
-
}
|
|
1349
|
-
}
|
|
1350
|
-
}
|
|
1351
|
-
```
|
|
325
|
+
projscan reads TypeScript, JavaScript, Python, Go, Java, Ruby, Rust, PHP, C#, Kotlin, Swift, C, and C++ with AST-aware adapters where available. It also detects file-level signals for Shell, CSS, HTML, SQL, Dart, Lua, Scala, R, and related project files.
|
|
1352
326
|
|
|
1353
|
-
|
|
327
|
+
Framework signals cover React, Next.js, Vue, Nuxt, Svelte, Angular, Express, Fastify, NestJS, Vite, Tailwind CSS, Prisma, Remix, SvelteKit, Astro, Hono, Koa, and common monorepo layouts.
|
|
1354
328
|
|
|
1355
|
-
|
|
329
|
+
JavaScript and TypeScript use `@babel/parser`. Non-JS languages use packaged tree-sitter WASM grammars. The published package has 7 direct runtime dependencies; optional semantic search uses the peer dependency `@xenova/transformers`.
|
|
1356
330
|
|
|
1357
|
-
|
|
1358
|
-
npx -y projscan mcp --watch
|
|
1359
|
-
```
|
|
331
|
+
## Trust Model
|
|
1360
332
|
|
|
1361
|
-
|
|
1362
|
-
|
|
1363
|
-
|
|
1364
|
-
|
|
1365
|
-
|
|
1366
|
-
|
|
1367
|
-
|
|
1368
|
-
|
|
1369
|
-
|
|
1370
|
-
- _"Where is `runAudit` defined?"_ → `projscan_semantic_graph { query: { direction: "symbol_defs", symbol: "runAudit" } }` or `projscan semantic-graph --query symbol_defs --symbol runAudit --format json`
|
|
1371
|
-
- _"Which files implement auth?"_ → `projscan_search { query: "auth", scope: "content" }`
|
|
1372
|
-
- _"Who should I ask about auth?"_ → `projscan_search { query: "auth" }`
|
|
1373
|
-
- _"Which tests cover auth?"_ → `projscan_search { query: "tests for auth" }`
|
|
1374
|
-
- _"What are the scariest untested files?"_ → `projscan_coverage`
|
|
1375
|
-
- _"Which files have no tests?"_ → `projscan_coverage`
|
|
1376
|
-
- _"What breaks if I bump chalk to 6?"_ → `projscan_upgrade { package: "chalk" }`
|
|
1377
|
-
- _"Show circular dependencies."_ → `projscan_coupling { direction: "cycles_only" }` or `projscan coupling --cycles-only --format json`
|
|
1378
|
-
- _"What modules are tightly coupled?"_ → `projscan_coupling` or `projscan coupling --format json`
|
|
1379
|
-
- _"Where should I refactor first?"_ → `projscan_hotspots`
|
|
1380
|
-
- _"What should my agent do first in this repo?"_ → `projscan_start { mode: "before_edit" }`
|
|
1381
|
-
- _"How do I understand the repo before editing?"_ → `projscan_understand { view: "map" }`
|
|
1382
|
-
- _"What should my agent do next?"_ → `projscan_workplan { mode: "bug_hunt" }`
|
|
1383
|
-
- _"Give the next agent a compact brief."_ → `projscan_agent_brief { intent: "bug_hunt" }`
|
|
1384
|
-
- _"Show the product quality picture."_ → `projscan_quality_scorecard`
|
|
1385
|
-
- _"What should I fix before a big release?"_ → `projscan_bug_hunt`
|
|
1386
|
-
- _"What evidence do I need before approval?"_ → `projscan_evidence_pack { website_prompt: true }`
|
|
1387
|
-
- _"Which checks prove this bigger product update?"_ → `projscan_regression_plan { level: "full" }`
|
|
1388
|
-
- _"How do I plan the next six product lines?"_ → `projscan_release_train`
|
|
1389
|
-
- _"How do I wire projscan into this MCP client?"_ → `projscan_adoption { action: "mcp_config", client: "codex" }`
|
|
1390
|
-
|
|
1391
|
-
### The 45 MCP tools
|
|
1392
|
-
|
|
1393
|
-
**Structural (0.6.0 / 0.11 / 0.13 / 0.14 / 0.15 - agent-native):**
|
|
1394
|
-
|
|
1395
|
-
- **`projscan_start`** _(3.0.4)_ - first-60-seconds repo orientation. Composes setup diagnostics, `firstTenMinutes`, workflow recipes, workplan, quality scorecard, top risks, adoption gaps, next commands, and optional handoff payload.
|
|
1396
|
-
- **`projscan_understand`** _(3.4)_ - cited repo-comprehension report with `map`, `flow`, `contracts`, `change`, and `verify` views, read-first files, unknowns, change readiness, verification tiers, and exact next commands.
|
|
1397
|
-
- **`projscan_semantic_graph`** _(3.0; query mode 4.0)_ - the code graph, two ways. With no `query`: the stable v3 semantic graph contract (file, function, package, and symbol nodes plus `defines`, `imports`, `imports_package`, `exports`, and `calls` edges). With `query: { direction, file?, symbol? }`: one cheap targeted lookup — `imports`, `exports`, `importers`, `symbol_defs`, `package_importers` — with millisecond responses on a warm cache. (Subsumes the former `projscan_graph`, removed in 4.0.)
|
|
1398
|
-
- **`projscan_dataflow`** _(3.0)_ - focused direct, propagated, and bridge source-to-sink dataflow risks. Next.js route body readers and URL reads plus Remix, SvelteKit, Astro, Hono, Express, Fastify, and Koa request sources are framework-aware, DB/write sinks are receiver-sensitive, and defaults suppress test-file paths, broad readFile/writeFile noise, JavaScript RegExp.exec false positives, and generated-code anxiety; opt into broader scans with `include_tests` / `include_broad_file_io` / `include_generated` or the matching CLI flags.
|
|
1399
|
-
- **`projscan_search`** - fast search across `symbols` (exported names), `files` (path substring), or `content` (source substring with line + excerpt). Sub-file mode (`sub_file: true`) embeds per-function for sharper semantic results _(0.15)_.
|
|
1400
|
-
- **`projscan_coupling`** _(0.11)_ - per-file fan-in / fan-out / instability + circular-import cycles (Tarjan SCC). Filter by `direction: cycles_only | high_fan_in | high_fan_out`.
|
|
1401
|
-
- **`projscan_pr_diff`** _(0.11)_ - structural diff between two git refs. Returns added/removed/modified files with explicit lists of exports, imports, and call sites that changed, plus ΔCC and Δfan-in.
|
|
1402
|
-
- **`projscan_review`** _(0.13)_ - one-call PR review. Composes `pr_diff` + per-changed-file risk + new/expanded import cycles + risky function additions + dependency changes + a verdict (`ok` / `review` / `block`).
|
|
1403
|
-
- **`projscan_workplan`** _(2.3)_ - agent mission-control plan. Composes preflight, review, session, hotspot, plugin, and supply-chain evidence into prioritized tasks with verification commands and handoff text.
|
|
1404
|
-
- **`projscan_bug_hunt`** _(2.3)_ - ranked bug-hunt action queue. Composes doctor issues, preflight, hotspots, and session coordination into ranked actions with verification commands.
|
|
1405
|
-
- **`projscan_release_train`** _(2.3)_ - product-line readiness planner. Reads version, scope, readiness evidence, and next actions.
|
|
1406
|
-
- **`projscan_evidence_pack`** _(2.3)_ - approval packet. Composes planning, bug-hunt, workplan, preflight, changelog, optional website prompt evidence, and PR comments with trust calibration, First Fix, owner routing, baseline trend memory, and exact next commands.
|
|
1407
|
-
- **`projscan_regression_plan`** _(2.3)_ - smoke/focused/full regression matrix. Turns bug-hunt, preflight, and product risk into deduplicated verification commands.
|
|
1408
|
-
- **`projscan_agent_brief`** _(2.3)_ - compact next-agent context packet with focus items, repo context, coordination hints, guardrails, and suggested next actions.
|
|
1409
|
-
- **`projscan_quality_scorecard`** _(2.3)_ - dimensioned quality view across health, security, tests, maintainability, coordination, top risks, and verification commands.
|
|
1410
|
-
- **`projscan_adoption`** _(2.9)_ - adoption helper for MCP config snippets, workflow recipes, and first-run diagnostics with the shared `firstTenMinutes` path.
|
|
1411
|
-
- **`projscan_fix_suggest`** _(0.14)_ - structured action prompt for any open issue: headline, why it matters, where, one-paragraph instruction, optional suggested test. Closes the diagnose → fix loop.
|
|
1412
|
-
- **`projscan_explain_issue`** _(0.14)_ - focused context for one issue: code excerpt, related issues in the same file, similar past commits via `git log --grep`, plus the structured FixSuggestion.
|
|
1413
|
-
- **`projscan_impact`** _(0.15)_ - transitive blast-radius for a file or symbol. BFS over reverse imports + symbol callsites. Use BEFORE renaming or deleting to see what breaks.
|
|
1414
|
-
- **`projscan_collision`** _(3.6)_ - detect change collisions across the repo's in-flight git worktrees (parallel agents). Flags same-file edits and dependency overlaps (one worktree edits a file another's change imports) before the branches merge. Local-first; needs ≥2 worktrees.
|
|
1415
|
-
- **`projscan_claim`** _(3.6)_ - advisory claims/leases over files, directories, or symbols, shared across the repo's worktrees. `add` returns contention when another agent already holds an overlapping target; `list` / `release` manage them. Local-first.
|
|
1416
|
-
- **`projscan_merge_risk`** _(3.6)_ - merge-risk preflight across in-flight worktrees: a safe integration order (merge the least-entangled branch first) plus conflict hotspots (files changed by 2+ worktrees). Builds on `projscan_collision`. Local-first.
|
|
1417
|
-
- **`projscan_route`** _(3.6)_ - map a stated goal (e.g. "what breaks if I rename X") to the right projscan tool with the exact call, or list the full capability catalog. A discovery entry point over the tool surface; deterministic, no LLM.
|
|
1418
|
-
- **`projscan_coordinate`** _(3.6)_ - one-call swarm coordination read: composes collisions, claims, and merge-risk into a `readiness` verdict (clear / caution / conflicted) with counts and the recommended integration order. The single entry point for the coordination arc. Local-first.
|
|
1419
|
-
- **`projscan_coordinate_watch`** _(3.7)_ - long-running coordination watch: polls the in-flight worktrees and emits a `notifications/projscan/coordination_changed` notification whenever the swarm state changes. Pairs with `projscan_coordinate`. `start` / `stop` / `list`.
|
|
1420
|
-
|
|
1421
|
-
**Analysis:**
|
|
1422
|
-
|
|
1423
|
-
- `projscan_analyze` - full project report
|
|
1424
|
-
- `projscan_doctor` - health score + issues (now includes `cycle-detected-N` for circular imports as of 0.13)
|
|
1425
|
-
- `projscan_hotspots` - risk-ranked files (churn × **AST cyclomatic complexity** × issues × ownership × coverage; falls back to LOC for non-AST languages). Pass `view: "functions"` _(0.13)_ for top-N risky individual functions.
|
|
1426
|
-
- `projscan_file` - per-file purpose, imports, exports, smells + risk + ownership + related issues + CC + fan-in/fan-out + per-function CC table _(0.13)_
|
|
1427
|
-
- `projscan_structure` - directory tree
|
|
1428
|
-
- `projscan_coverage` - scariest untested files (coverage × hotspots)
|
|
1429
|
-
|
|
1430
|
-
**Dependencies:**
|
|
1431
|
-
|
|
1432
|
-
- `projscan_dependencies` - declared deps, risks. In a monorepo: aggregated totals + `byWorkspace` breakdown; `package` arg scopes to one _(0.13)_.
|
|
1433
|
-
- `projscan_outdated` - declared-vs-installed drift (offline). Per-package `byWorkspace`; `package` arg.
|
|
1434
|
-
- `projscan_audit` - normalized `npm audit`. `package` arg scopes findings to one workspace's direct deps _(0.13)_.
|
|
1435
|
-
- `projscan_upgrade` - upgrade preview (CHANGELOG + importers, offline)
|
|
1436
|
-
|
|
1437
|
-
**Workspace (0.11):**
|
|
1438
|
-
|
|
1439
|
-
- `projscan_workspaces` - list monorepo packages (npm/yarn/pnpm/Nx/Turbo/Lerna). Use the `name` as the `package` arg on `projscan_hotspots` / `projscan_coupling` to scope.
|
|
1440
|
-
|
|
1441
|
-
**Session (1.4):**
|
|
1442
|
-
|
|
1443
|
-
- **`projscan_session`** _(1.4)_ - durable cross-invocation session. Subactions: `current` (id + counts), `touched` (files touched this session, sorted by recency, filterable by source: `tool-result` / `fs-watch` / `explicit`), `events` (chronological log), `reset` (start a fresh session). Auto-populated from every tool result and from `notifications/file_changed` push events when `--watch` is on. MCP resources and agent briefs add `coordinationHints` so agents can separate current worktree checks from remembered session context before parallel edits continue.
|
|
1444
|
-
|
|
1445
|
-
**Memory (1.5):**
|
|
1446
|
-
|
|
1447
|
-
- **`projscan_memory`** _(1.5)_ - durable, local-only feedback loop. Records, per analyzer rule id, how many runs surfaced it and how many fixed it. Subactions: `current` (aggregate counts), `stable` (rules surfaced across ≥ 3 runs over ≥ 7 days without ever being fixed — paired with a ready-to-paste `.projscanrc.json disableRules` snippet), `runs` (every tracked rule with full history), `forget` (drop a single rule). Stored at `.projscan-memory/memory.json`; never leaves the machine. Lets an agent ask "what is this project tolerating?" and propose quieting it.
|
|
1448
|
-
|
|
1449
|
-
**Operator (1.6):**
|
|
1450
|
-
|
|
1451
|
-
- **`projscan_workspace_graph`** _(1.6)_ - cross-repo intelligence over locally trusted sibling repos registered with `projscan workspace add` and stored under `.projscan-cache/workspace.json`. Subactions: `list` (registered repos + parsed-file + export counts), `graph` (every symbol exported by ≥ 2 repos — the candidate refactor / API contract surface), `file_importers` (given a file in one repo, every other repo whose graph imports it). Read-only.
|
|
1452
|
-
- **`projscan_apply_fix`** _(1.6)_ - mechanically execute the safe fix templates. Default is dry-run; pass `confirm: true` to write. Atomic writes, per-apply rollback record at `.projscan-cache/rollbacks/<id>.json`. Reverse with `action: "rollback", rollback_id: ...`. Six templates supported at this release: `unused-dependency-*`, `missing-test-framework`, `missing-eslint`, `missing-prettier`, `missing-editorconfig`, `missing-readme`.
|
|
1453
|
-
- **`projscan_taint`** _(1.6)_ - source-to-sink reachability over the per-function call graph. Built-in defaults cover common JS / Python sources (`process.env`, `req.body`, etc.) and sinks (`exec`, `eval`, `db.query`, etc.). Project-specific names go in `.projscanrc.json` `taint`. `projscan_review` automatically diffs taint flows between base and head and **blocks any PR that introduces a new flow**. In 3.0.2, review surfaces hardened `newDataflowRisks`, compact `graphEvidence`, and graph-readiness gates for safer handoff.
|
|
1454
|
-
|
|
1455
|
-
Analyzer plugins can optionally read graph/dataflow context through `check(rootPath, files, context)` while staying on manifest schema v1. The packaged `graph-context` example shows `context.getSemanticGraph()` and `context.getDataflow()` in a real analyzer. For analyzer and reporter plugin authoring, manifest validation, `--reporter <name>`, and the trust model, see [Plugin Authoring](https://github.com/abhiyoheswaran1/projscan/blob/v4.3.1/docs/PLUGIN-AUTHORING.md).
|
|
1456
|
-
|
|
1457
|
-
### Context-window budgeting
|
|
1458
|
-
|
|
1459
|
-
**Every MCP tool accepts an optional `max_tokens` argument.** Set it and projscan serializes the result, and - if over budget - truncates the largest array field record-by-record until it fits. Responses include a `_budget` sidecar when truncated so your agent knows it got a partial view.
|
|
333
|
+
| Area | projscan behavior |
|
|
334
|
+
| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
335
|
+
| Source code | Core scans read local files and keep results on your machine. |
|
|
336
|
+
| `.gitignore` | Ignored files stay out of scans unless you pass `--include-ignored`. |
|
|
337
|
+
| `.env` | projscan reports paths by default. It reads values after `--scan-env-values`. |
|
|
338
|
+
| Network | `audit`, registry checks, opt-in telemetry, and optional semantic model download can contact the network. |
|
|
339
|
+
| Telemetry | Off until you run `projscan telemetry enable` or accept the `init team` prompt. |
|
|
340
|
+
| Plugins | Local plugin code runs after `PROJSCAN_PLUGINS_PREVIEW=1` and an execution path such as `doctor`, `ci`, `analyze`, or `plugin test --execute`. |
|
|
341
|
+
| Repo writes | Source writes require explicit fix commands. Cache and mission proof files stay under local projscan directories. |
|
|
1460
342
|
|
|
1461
|
-
|
|
1462
|
-
{ "name": "projscan_hotspots", "arguments": { "limit": 100, "max_tokens": 800 } }
|
|
1463
|
-
```
|
|
1464
|
-
|
|
1465
|
-
### Semantic search (0.9.0+, opt-in)
|
|
1466
|
-
|
|
1467
|
-
projscan ships with BM25-ranked lexical search by default. To unlock **true semantic search** - embeddings over file content so queries like _"which file implements auth"_ hit files that don't literally contain the word "auth" - install the optional peer:
|
|
343
|
+
Audit helpers:
|
|
1468
344
|
|
|
1469
345
|
```bash
|
|
1470
|
-
|
|
1471
|
-
projscan
|
|
1472
|
-
|
|
1473
|
-
|
|
1474
|
-
Or via the MCP tool:
|
|
1475
|
-
|
|
1476
|
-
```json
|
|
1477
|
-
{
|
|
1478
|
-
"name": "projscan_search",
|
|
1479
|
-
"arguments": { "query": "verifying user credentials", "mode": "semantic" }
|
|
1480
|
-
}
|
|
346
|
+
projscan privacy-check
|
|
347
|
+
projscan telemetry status
|
|
348
|
+
projscan telemetry explain
|
|
349
|
+
projscan doctor --offline
|
|
1481
350
|
```
|
|
1482
351
|
|
|
1483
|
-
|
|
1484
|
-
|
|
1485
|
-
- `lexical` (default) - BM25 over content + symbol + path boosts. No peer needed.
|
|
1486
|
-
- `semantic` - cosine similarity on `Xenova/all-MiniLM-L6-v2` embeddings. Requires peer.
|
|
1487
|
-
- `hybrid` - both, fused via Reciprocal Rank Fusion. Requires peer.
|
|
1488
|
-
|
|
1489
|
-
Semantic embeddings are cached at `.projscan-cache/embeddings.bin` keyed by `(model, mtime, content hash)` - invalidates automatically on file change. All offline after the first-run model download (~25MB).
|
|
1490
|
-
|
|
1491
|
-
### Pagination, progress, and streaming (0.8.0+)
|
|
1492
|
-
|
|
1493
|
-
Large responses can be walked incrementally:
|
|
352
|
+
Supply-chain scanners may flag package strings or APIs used by `git`, `npm audit`, `web-tree-sitter`, optional plugins, and optional semantic search. The runtime paths above describe when those capabilities run.
|
|
1494
353
|
|
|
1495
|
-
|
|
1496
|
-
- **Progress notifications**: set `_meta.progressToken` on the tool-call request. The server emits `notifications/progress` at coarse milestones (scanning → analyzing → ranking → done) so your agent can display progress or cancel.
|
|
1497
|
-
- **Response chunking**: set `stream: true` in arguments to split large arrays into multiple `content` blocks (header + N chunks of ~20 records each).
|
|
354
|
+
## Install Notes
|
|
1498
355
|
|
|
1499
|
-
|
|
356
|
+
`projscan@4.9.3` has seven direct runtime dependencies:
|
|
1500
357
|
|
|
1501
|
-
|
|
358
|
+
- `@babel/parser`
|
|
359
|
+
- `@babel/types`
|
|
360
|
+
- `chalk`
|
|
361
|
+
- `commander`
|
|
362
|
+
- `fast-glob`
|
|
363
|
+
- `ora`
|
|
364
|
+
- `web-tree-sitter`
|
|
1502
365
|
|
|
1503
|
-
|
|
366
|
+
If npm prints `allow-scripts` warnings during a global install, check which package names it lists. projscan core does not need `node-gyp` grammar builds at runtime in 4.9.3. Open an issue with the warning text if npm reports install scripts from `projscan@latest`.
|
|
1504
367
|
|
|
1505
|
-
|
|
368
|
+
The grammar packages are build-time sources, not global-install dependencies. Published grammar assets include `tree-sitter-python.wasm` and `tree-sitter-c_sharp.wasm`.
|
|
1506
369
|
|
|
1507
|
-
|
|
1508
|
-
- `investigate_file` - senior-engineer brief for a specific file
|
|
1509
|
-
- **`refactor_hotspot`** _(1.5)_ - step-by-step refactor plan for one hotspot file
|
|
1510
|
-
- **`triage_doctor_issues`** _(1.5)_ - critical / important / backlog ordering of open issues
|
|
1511
|
-
- **`review_this_pr`** _(1.5)_ - PR-comment-ready review primed with the structural diff and verdict
|
|
1512
|
-
- **`safely_rename_symbol`** _(1.5)_ - ordered rename + verification checklist via `projscan_impact` blast radius
|
|
370
|
+
## Deeper Docs
|
|
1513
371
|
|
|
1514
|
-
|
|
1515
|
-
|
|
1516
|
-
-
|
|
1517
|
-
|
|
1518
|
-
|
|
1519
|
-
|
|
1520
|
-
-
|
|
1521
|
-
-
|
|
1522
|
-
- **Tech-debt prioritization**: Use `projscan hotspots` to decide what deserves refactoring time
|
|
1523
|
-
- **AI-assisted development**: Mount `projscan mcp` in your agent of choice for grounded edits
|
|
1524
|
-
- **CI/CD**: Use `projscan ci` to enforce health standards in your pipeline
|
|
1525
|
-
- **Security**: Catch committed secrets and `.env` files before they reach production
|
|
1526
|
-
- **Consulting**: Quickly assess client projects before diving in
|
|
1527
|
-
- **Maintenance**: Track health trends with `projscan diff` across releases
|
|
372
|
+
- [Full guide](docs/GUIDE.md)
|
|
373
|
+
- [First 10 minutes](docs/FIRST-10-MINUTES.md)
|
|
374
|
+
- [Roadmap](docs/ROADMAP.md)
|
|
375
|
+
- [Adoption workflows](docs/examples/adoption-workflows.md)
|
|
376
|
+
- [Swarm coordination](docs/examples/swarm-coordination.md)
|
|
377
|
+
- [Stability policy](docs/STABILITY.md)
|
|
378
|
+
- [Telemetry policy](TELEMETRY.md)
|
|
379
|
+
- [Security policy](SECURITY.md)
|
|
1528
380
|
|
|
1529
381
|
## Contributing
|
|
1530
382
|
|
|
1531
|
-
|
|
383
|
+
Read [CONTRIBUTING.md](CONTRIBUTING.md) before opening a PR. Contributions use the MIT License and the DCO 1.1 certification described there.
|
|
1532
384
|
|
|
1533
|
-
## Legal
|
|
385
|
+
## Legal
|
|
1534
386
|
|
|
1535
387
|
- License: [MIT](LICENSE)
|
|
1536
388
|
- Disclaimer: [DISCLAIMER.md](DISCLAIMER.md)
|
|
@@ -1540,8 +392,6 @@ Contributions are welcome. Please read [CONTRIBUTING.md](CONTRIBUTING.md) before
|
|
|
1540
392
|
- Trademark and brand policy: [TRADEMARKS.md](TRADEMARKS.md)
|
|
1541
393
|
- Third-party notices: [THIRD-PARTY-NOTICES.md](THIRD-PARTY-NOTICES.md)
|
|
1542
394
|
|
|
1543
|
-
projscan is free and open source. The CLI and MCP server are local-first and do not upload source code or scan results to a projscan service. Anonymous product telemetry is default-off and only runs after explicit opt-in.
|
|
1544
|
-
|
|
1545
395
|
<p align="center">
|
|
1546
396
|
<a href="https://www.baseframelabs.com" target="_blank" rel="noopener" title="Part of Baseframe Labs">
|
|
1547
397
|
<span>part of</span>
|