Move to DiGi-Organization: update owner links and workspace paths
The DiGi repositories were transferred from ZiolkowskiJakub to
DiGi-Organization (client projects to DigiProject-Organization) and the
local workspace folder was renamed from DigiProject to DiGi.
- Owner replaced in links, issue references and sync-wiki.yml
(old URLs keep redirecting).
- Workspace paths DigiProject/... -> DiGi/... in docs and comments.
- Regenerated .agents and the README guideline block, which also
carries the pending Coding - YOLO.md guideline updates.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ConsoleApp guide, Home and detector training: retire the regressor narrative
Step 5 is detector-only dating: the reference page's options, preflight,
exit codes and gotchas now describe the first-detection rule, the
detection-only feature guard and #28 clearing; the Home step list names
the dating rule; the model.pt rationale becomes the county rewrite
requirement (#23) rather than a paired regressor.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Feature-contract refusal: Years/Radiuses are now checked against the model, narrowed projections are refused (exit 1) (ZiolkowskiJakub/DiGi.GIS.ML#6)
Correct the recipe against a real run, and record the deployed layout (#7)
#7 §4 required Running-a-County to be re-read against what a run actually does
rather than amended in passing. Three runs over county 104106 - one from the
deployed tray application, two completing after the ModelPath fix - contradicted
five things this wiki asserted.
Building Data updated is 11076 on a combined run, not 5538. The published sample
could only have come from a run with one of the two write steps on: the counter
accumulates once for the detection columns and once for the predicted year built
column, so a run with both counts every building twice. Nothing but watching a
real run would have shown this.
"The committed template ships with all three write flags off" was true of the
combined template only. Score.json ships UpdateYearBuiltData and
UpdatePredictedYearBuilt both true, Detections.json ships UpdateDetections true,
and §6 hands both to the reader as recovery templates.
The runner's own folder is not the same place on a deployed machine - it is
extensions\DiGi.GIS.YOLO.UI.ConsoleApp inside the tray application - and
CopyUserFiles shadows the committed options file there with the build machine's
own, so the file beside a deployed runner is not the default it looks like.
A tray run has no options file, so the members absent from the dialog come from
the class defaults rather than from a file. That makes those defaults part of
the tray contract, which is why a null ModelPath broke a run rather than
inconveniencing one.
Trap 7 did not say what the tray application resolves a relative scratch path
against: its own folder, which on a deployed host is the deployment directory,
so a bare "scratch" exports tens of thousands of images into the installed
application and whatever syncs it. New trap 10 records that a machine holding
both a deployment and a checkout runs two tray applications with the same icon -
which cost two runs here before it was noticed.
Exit code 2 now names the detector weights alongside the interpreter and the
.mlnet model, all three refused before a single image is exported.
Home gains the two run surfaces and the opt-in extensions hosting, which no page
mentioned.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fix #9: the committed options defaults now carry their clean names
Rewrite the recipe around a single run, and document the cleanup
Running-a-County presented the detections and scoring passes as two runs whose
ordering was explicit by design. They are one run now: the scoring pass rebuilt
its building list from results.bbrf on disk rather than from the detection
columns already stored, so a scratch directory cleaned between them skipped the
county reporting exactly what a county with no detections reports.
Section 2 carries that reasoning, the order table drops to three steps, and the
split passes move to their own section as the manual recovery path - with the
warning that their templates set CleanScratchDirectory false, without which they
cannot hand off at all.
Section 5 states what the shipped template actually does: it carries every write
flag off, which on a fresh county is refused by the feature coverage guard, so it
is not the configuration that populates one. The exit code 5 row, trap 8 and the
Resume warning now say who gets cleaned - a county that completed, and a
cancelled one, but not a county that failed.
Using-the-ConsoleApp gains the option, the Resume interaction, and a gotcha for
the missing results file now being a failure rather than an empty county.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs: add the standing run recipe and correct the ConsoleApp guide
Running-a-County.md is the operator entry point: why the run order exists, the
county readiness check, the two console passes, verification and exit-code triage.
Corrections to Using-the-ConsoleApp.md that the feature-coverage guard invalidated:
a read-only dry run is the second pass, not the first, because scoring a county
whose detection columns were never written is now refused with exit code 4; Years
is a Range<int>, not a List<int>; Radiuses was undocumented.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
docs: add wiki landing page and ConsoleApp usage guide