Align standalone scope contracts, legacy fixtures, and generated examples

[Yuri-bara]

Follow-up to the standalone-root migration.

The validator now runs far enough for npm test to expose remaining test-contract, fixture, snapshot, and generated-artifact assumptions from the former nested host-repository layout. This issue aligns those expectations with the standalone validator repository without reopening the completed root-layout migration.

Scope model to preserve

The scope concepts remain distinct:

• repo means the complete repository under validation.
• validator means the validator-owned area.

When the validator is embedded in a host repository, those scopes differ:

repo      = complete host repository
validator = validator-owned area within that host repository

In this standalone calculogic-validator repository, the validator-owned area is the repository root. Therefore:

repo scope      = repository root
validator scope = repository root

They must select the same effective standalone root set here while remaining distinct scope names and concepts.

Do not implement a future host-repository installation, configuration, or integration model in this issue.

Required work

1. Align standalone scope contracts

Update builtin scope behavior, scope-contract tests, and related fixtures so that:

• --scope=repo and --scope=validator select the same effective candidate set in this standalone repository;
• app, docs, and system remain deliberate narrower scopes;
• validator scope no longer assumes a physical nested calculogic-validator/ directory;
• root files and root folders are selected intentionally and consistently;
• tests do not use invalid assertions such as pathname.startsWith('') to mean “outside validator scope.”

Do not hard-code a speculative future install location such as validator/.

2. Rebaseline stale migration-era fixtures and snapshots

Review and update expectations that still encode the removed nested layout, including:

• Naming semantic-family package-root expectations;
• Tree structural-home registry expectations;
• Tree folder-kind, occurrence address, lineage, depth, and prepared-evidence snapshots;
• Tree target-narrowing and outside-active-scope expectations;
• candidate-collection deterministic ordering expectations;
• test fixtures that still expect calculogic-validator or calculogic-doc-engine as active top-level structural homes.

Do not re-add retired calculogic-validator or calculogic-doc-engine structural-home policy merely to satisfy historical assertions.

3. Triage behavior failures before changing assertions

Do not treat every failed test as stale.

For each affected failure, determine whether the expectation is outdated or whether the standalone migration introduced an actual runtime regression.

Explicitly verify:

• normal standalone repository shape does not produce unintended Tree findings;
• structural-home evidence does not duplicate entries such as src;
• directory target narrowing remains correct;
• outside-active-scope target behavior remains intentional;
• occurrence-derived file reasoning still executes once per runtime run;
• owned-slice boundary-drift behavior under src/** remains correct;
• semantic package-root classification/staging remains consistent with the current Tree model.

Add focused regression coverage for any actual runtime fix.

4. Regenerate checked-in report examples

After scope selection is correct:

• regenerate checked-in report examples through the existing generator;
• update example snapshot expectations and registry digests through generated output;
• do not hand-edit generated JSON merely to satisfy tests.

The system-scope example must reflect the intended current root-file coverage.

Non-goals

Do not:

• move repository files again;
• recreate a nested calculogic-validator/ compatibility folder;
• redesign Tree, Naming, Addressing, suite-core, or report envelopes;
• rename public package bins;
• change dependency or workspace strategy;
• change finding identifiers, report JSON format, CLI flag semantics, or strictness behavior;
• implement host-repository integration/configuration;
• modify HCAToolkit/Calculogic_React_App.

Acceptance criteria

• npm test passes from a fresh standalone validator checkout.

• repo and validator select the same effective standalone root set while reports preserve their selected scope names.

• app, docs, and system remain narrower intentional contracts.

• Tree tests no longer depend on retired nested-layout roots or a removed calculogic-validator path segment.

• Actual runtime regressions found during triage are fixed with focused tests.

• Checked-in generated examples match generator output.

• The PR summary includes a concise failure-to-resolution map grouped as:

  • scope contracts;
  • candidate collection and report examples;
  • Tree fixtures and snapshots;
  • actual runtime fixes.

Verification

npm test
npm run validate:naming -- --scope=repo
npm run validate:naming -- --scope=validator
npm run validate:tree -- --scope=repo
npm run validate:tree -- --scope=validator
npm run health:validator