–
User stories (Jira)
–
Converted to test cases
–
Test cases (md)
–
Automation specs
User stories by epic
All
Ready
Story only
Specs only
Missing
Loading user stories…
Pick a module on the left to see its stories.
Step 3 — Prime a module's ground truth
Priming walks the app's frontend source and re-derives the three files the author reads as ground truth, in dependency order:
harvest → frontend-info/<module>/knowledge.json, then build:skb → selectors/<module>.skb.json,
then gen:fact-pack → docs/pilot/fact-packs/<module>.md.
Authoring (step 4) reads the fact-pack; specs resolve selectors from the SKB at runtime. Prime before you author — a spec authored against a stale fact-pack
is a spec built on facts the app no longer has.
One module at a time, never fleet-wide:
"Fresh" means the SKB and fact-pack were written after the last harvest. It cannot mean "matches the running app" — nothing on disk proves that, so re-prime whenever the frontend changed.
harvest and build:skb both default to the whole fleet
when --module is omitted, and a blanket re-derive changes every fact-pack's content hash — which re-LLMs specs that were already verified green.
"Fresh" means the SKB and fact-pack were written after the last harvest. It cannot mean "matches the running app" — nothing on disk proves that, so re-prime whenever the frontend changed.
Loading…
–
Release readiness
Pass-rate trend (last 20 runs)
–
Last run
–
Passed (last run)
–
Failed (last run)
Allure
Open full report →
Healing Proposals — failed selectors mapped to SKB roles; review and apply, nothing is automatic
No open proposals.
Recent Runs
| Time | Suite | Module | Passed | Failed | Gate | Defect |
|---|
Probe verdict
Routed reds — NSD diagnoses grouped by owner; each probe-checked before routing (P1–P3). Fix the source, never the spec.
| Module · TC | Layer | Owner | Probe | Hits | Reason | Action |
|---|
Autonomy loop
— the unattended tick: Watch A frontend drift · B md changes · C canary re-verify · D routing drain.
Loading…
| Run | Mode | Drift | Test cases | Canary | Queue | Status |
|---|
Source:
artifacts/tick-log.md — one line per run, the only durable per-run record the tick keeps (its lockfile is deleted on exit).
Task state is read with schtasks /Query only; this dashboard never enables, disables or runs a scheduled task.
App source
— the frontend checkout this project's harvested data & specs were built on.
Loading…
Drift
— has the app's source moved away from the truth the specs were built on?
A verdict is a structural diff of the last drift scan (
artifacts/harvest-scratch/<module>.knowledge.json, written by
npm run detect:frontend) against the committed frontend-info/<module>/knowledge.json, over the seven sections the engine treats as
spec-affecting: routes, forms, grids, modals, toasts, constants, uiCandidates.
unknown is a real answer, not a failure — it means no scan exists, or the scan is older than the harvest that followed it
(its findings were absorbed, so a diff taken now would compare a new baseline against an old scan). Re-scan to get a verdict; nothing is inferred.
“Scan for drift” only LOOKS. It re-walks the frontend dev checkout and compares it with each module's committed harvest, writing nothing except its scratch comparison files under
artifacts/harvest-scratch/. No committed knowledge.json, SKB, fact-pack or spec is modified, no model is called and no tests are run. Modules read unknown until they have been scanned at least once. It scans every module in one pass — the underlying tool has no per-module cost worth splitting, and being read-only there is nothing to scope down.
Engine Health
Static gates
— check:pilot-lint + check:engine-types, run on demand (never on page load).
Not run yet — press "Re-run gates".
Harness-owned open reds
— failures whose root cause is the engine's harness, grouped by cluster (diagnosed-cache).
Loading…
Last dashboard run per module
Loading…
Harness Editor
edits LIVE engine code
KB Packs — per-module feature context for the author
Hand-authored context — purpose · workflows · domain vocabulary · gotchas — the build-time author reads so plain-English test cases translate correctly. This is context, not a selector source (selectors live in the fact pack). Editing a KB does not re-author; it flips the module's chip to re-author eligible, and re-author stays a deliberate action from Automation Specs.
| Module | KB status | Authored specs |
|---|
SKB Inventory read-only
The Selector Knowledge Base resolves each role to runtime selector candidates. Selectors resolve at runtime from here, so a label change is a one-line SKB edit and zero re-author.
_handPinned roles are protected hand edits the builder will not clobber.| Role | Candidate selectors | Provenance |
|---|
Changed Files
…Commit Message
Commits go to a new
navimate/<you>/<task> branch and open a pull request — never directly to the working branch.Recent Commits
| Hash | Message |
|---|
Configured Projects
Users
Sign-in accounts for this dashboard. Passwords are hashed (bcrypt) and never shown.