A manifest is not always at the repository root

[schneiderjoseph]

First run of devia init on a real project rather than a scratch fixture: a Next.js app whose manifest lives in apps/web/. Five gates reported "SKIP no package.json" to a repository that has one, with a lockfile, a lint script and thirteen dependencies.

The letter of AGT-006 was kept -- nothing was rounded up to PASS -- but the reason printed was false, which is worse than silence: the reader believes the tool looked. "I did not look there" was rendered as "you have none".

check

• Reads every package.json in the repository, nearest the root first, and takes the union of their dependencies. "Does this project use X" is not a question about one directory
• Looks for a lockfile next to each manifest, not only at the root
• Finds a migrations directory at any depth
• SKIP now reads "no package.json anywhere in the repository", and findings name the file they came from: "no npm test script in apps/web/package.json"

init

• Detects the profile from the nearest manifest instead of falling back to the default. The answer was right by accident before; it is now right by evidence
• Records the directories holding manifests in code.paths, which is the tree doctor watches for staleness. It saw src and missed apps

Measured on that project: six SKIPs became two, four gates turned into real findings, and the lockfile went from invisible to PASS apps/web/package-lock.json.

Also fixed: the separator class in the scan filter matched only "/", so with git unavailable on Windows a nested apps/web/node_modules was walked instead of skipped. Both separators now.

Registries

• G1 closed and reframed: the blind spot was never the ecosystem, it was the root assumption. Ecosystem-specific gates stay out of scope
• D9 opened: pyproject.toml, go.mod and Cargo.toml are still read at the root only, so a Python or Go package one directory down is still invisible
• G7 opened: what devia should do when a repository already carries an ad-hoc memory of its own

Version: package 0.4.0, standard unchanged at 0.1.0.

Verified: 34 tests with and without FORCE_COLOR, including one that builds a repository whose only manifest is in apps/web and asserts the lockfile is found, the finding names its file, and the profile follows the evidence.

Summary

Type

Devia compliance

• Rules touched (IDs):
• New rule? source cited, severity, priority, validation method:
• Breaking for adopters? (rule id, .devia/ layout, CLI contract):
• CHANGELOG.md updated:
• Generated files rebuilt (npm run build:index):

Checks

• npm run validate passes
• npm test passes
• node bin/devia.mjs check --root . passes
• devia init still produces a valid project (devia validate clean in a scratch repo)

Not verified