feat(harmony): disclose unclassified inventory files - #4968

feat(harmony): disclose unclassified inventory files

Summary

Report authenticated HarmonyOS files that have no component classification in unclassified_components. Related to #4489; this addresses its unclassified-entry request only.

authenticated inventory
  → existing components and App Pack children
  → remaining file/slice occurrences with exact identities

Problem and expected behavior

Files such as pkgContextInfo.json were present in the inventory but absent from every component category. A complete-inventory result did not disclose those unclassified files. The projection now lists them without interpreting their contents or implying incomplete traversal.

Change and scope

Compute the complement at the existing Harmony projection owner, reusing its classified component objects and child-package list. Keep unavailable content separate. This does not parse N-API declarations or resolve the rest of #4489.

2026-10-29 baseline refresh: merged current main (163 commits since the previous refresh) into this branch so the change sits on the upstream projection owner as it now stands. The PR-owned diff is still the same six files.

Upstream changes this branch now adopts rather than fights:

• classifyManifests() (7d6bccb86, fix(harmony): classify exact manifest names once #7206) owns manifest classification, recognises pack.info, and skips manifests on classified resource paths. pack.info therefore no longer appears in unclassified_components, and the packaging-model hint comes from manifests.packagingModel.
• #7886 changed unavailable from entries.flatMap to fileEntries.flatMap, so an unavailable child package no longer surfaces as an unavailable component.
• The acceptance test was refactored to harmonyFixture(), which returns { bytes, javascriptPaths } and adds an ets/current symlink entry. The resolution keeps both fixtures this PR adds (pkgContextInfo.json, .pages.info) and asserts unclassified_components and unavailable_components together. The symlink does not reach the new array, because projectedFileComponents emits only file/slice occurrences that carry a projected component.

The projection assertion was extracted into expectHarmonyProjection because upstream's refactor pushed the test function to 155 lines, past the 150-line limit; the helper keeps it under the limit without dropping any assertion.

Contract and boundary impact

• Semantic owner: Harmony inventory-to-application projection; shared CLI/MCP workflow.
• Maintainer scope decision: not applicable to this static change within the existing projection boundary; no new provider or execution authority.
• Inputs unchanged; output adds unclassified_components using the existing component row schema. Projection/Evidence IDs include the changed result; consumers pinned to the old strict output schema need the updated contract.
• Paths, hashes, occurrence order/multiplicity, source Evidence, unknown identities and coverage retain their existing meaning. App Pack children are not repeated as unclassified files.
• Ignored catalog/skill metadata was regenerated and checked; no generated outputs, dependency changes, native binaries or installation changes are in this diff.

Expected product effect:

• Read existing files or captured data.

Evidence

• Before: the new public-workflow assertion failed on 2c4338db1 because the two fixture metadata files had no unclassified_components output.
• After: actual CLI and stdio MCP agree for authored HAP/HSP/App Pack inputs and preserve package bytes. Controls cover same content under different paths, an overlapping resource/JavaScript classification, page reassembly, missing inventory data, encrypted metadata, tamper refusal, directories and App Pack children.
• Real pinned HAP 928a4c6718125328695d2c32297ef5dfba2e06d16fd501d507d4aa32423cbad6 reports ets/sourceMaps.map and pkgContextInfo.json as unclassified while keeping complete inventory coverage. Its package digest is unchanged.
• After the 2026-10-25 baseline refresh: the partial-inventory control now expects EvidenceIntegrityError for tampered Evidence, matching upstream's current classification of that failure instead of the older AnalysisInputError.

Validation performed

Local validation executed on 2026-10-18, Windows x64, Node 24.18.0/npm 11.16.0 (historical execution; not rerun on 2026-10-23):

• npm run test:focused -- tests/boundary/filesystem/harmony/application.test.ts tests/acceptance/harmonyArtifactJourney.test.ts tests/acceptance/applications/mobileDirectoryComponents.test.ts tests/boundary/mcp/mobileApplicationGraphMcp.test.ts — 36 tests pass across 4 files.
• After test-suite/fixture extraction: the Harmony filesystem and public lifecycle files pass again, 28/28 tests.
• npm run check — pass (typecheck, lint with 0 errors, format, knip, metadata, module boundaries and architecture guards).
• npm run docs:check — pass, including 5 README conformance checks.
• npm run verify:test-discovery — all 1,578 files discovered exactly once.
• npm run fixtures:harmony then REA_HARMONY_TEST_HAP=<pinned-hap> npm run verify:harmony — real static HAP CLI/MCP verification passes. The environment assignment is shown in portable notation; executed with process-scoped PowerShell environment variables.
• git diff --check — pass. Independent Standards and Spec source reviews: no actionable findings.

Baseline-refresh validation executed on 2026-10-25, Windows x64, Node 24.22.1/npm 11.19.1, against merged main 113679c9a:

• vitest run tests/boundary/filesystem/harmony/application.test.ts — 29 passed (27 upstream controls plus this PR's unclassified-inventory control).
• vitest run tests/acceptance/harmonyArtifactJourney.test.ts — 1 passed.
• vitest run tests/acceptance/applications/mobileDirectoryComponents.test.ts — 9 passed.
• npm run verify:test-discovery — 2,483 files discovered exactly once.
• npm run verify:module-boundaries — 3,059 source files checked.
• oxfmt --check . — all matched files use the correct format.
• oxlint over the six changed files — no new findings; the one reported warning is pre-existing on unmodified main.
• git merge-tree --write-tree origin/main HEAD — merges cleanly, so this branch has no conflict with current main.
• git diff against the merge base — still exactly the six files this PR owns; the merged upstream history is not part of this PR's diff.

Remote status rechecked on 2026-10-23: CI run 39099107665 completed successfully for the previously published head 921707a7cbe9e8cd2013c37ac5db97bdd2e2141d on 2026-10-18. Across reported checks, 16 succeeded and 16 unselected lanes were skipped. That run predates the baseline refresh above; remote CI for the refreshed head has not been executed yet.

Second baseline-refresh validation executed on 2026-10-29, Windows x64, Node 24.22.1/npm 11.19.1, against merged main d157560d4:

• vitest run tests/boundary/filesystem/harmony/application.test.ts tests/acceptance/harmonyArtifactJourney.test.ts — 36 passed (35 boundary controls including the six upstream added in 7d6bccb86, plus the public CLI/MCP lifecycle).
• vitest run tests/acceptance/applications/mobileDirectoryComponents.test.ts — 9 passed.
• vitest run tests/boundary/mcp/contractPresentation.test.ts tests/boundary/mcp/toolSchemaValidity.test.ts tests/boundary/mcp/mcpDoctor.test.ts — 49 passed. contractPresentation is the byte-for-byte gate on the advertised outputSchema this PR changes; mcpDoctor confirms the recorded catalog digests still agree.
• vitest run src/contracts/toolEffects.test.ts tests/boundary/mcp/deferredRuntime.test.ts — 38 passed.
• vitest run tests/boundary/mcp/mobileApplicationGraphMcp.test.ts tests/acceptance/tools/mobileGraphExamples.test.ts — 16 passed. These are the other two live consumers of the Harmony tool and prove the new field survives the MCP delivery envelope.
• npm run typecheck — clean. compile uses tsconfig.build.json, which excludes tests, so typecheck is the only command that covers the three edited test files.
• npm run verify:test-discovery — 2,802 files discovered exactly once.
• npm run verify:module-boundaries — 3,348 source files checked.
• oxfmt --check . and oxlint on the six changed files — clean.
• mutation check (5 mutations, 4 killed): claiming complete coverage for the
  partial inventory — killed; reporting the inventory as complete while it is
  not — killed; reporting the bridge projection as partial — killed; stopping
  manifest classification — killed; dropping the "Source inventory coverage is
  partial; absence is unknown." limitation — survives.
• npm run typecheck — clean.

Note on the surviving mutation. An earlier revision of the partial-inventory
control asserted that limitation sentence verbatim. That assertion was removed:
docs/testing.md asserts structured limit facts instead of freezing
explanatory sentences, and the same section puts documentation wording in
review. The structured replacement is the pair of assertions added alongside
coverage, which pin the two independent causes of a partial projection
(unavailable_components is empty, bridge_candidate_coverage is complete with
zero candidates) so that status: "partial" is attributable to the missing
occurrence alone rather than to some other cause. The prose limitation is
therefore no longer covered by a substring assertion; that is a deliberate
trade under the rule above, not a lost regression.

One assertion was also removed from the unclassified-paths control: the
artifact_id comparison was tautological, because that fixture's four files all
carry the same bytes, the preceding assertion already pins the shared digest,
and artifact_id is derived from the digest. Distinct paths sharing content
remain covered by the path array and the independent digest expectations.

The documentation sentence about where a nested .hap/.hsp member of a HAP or
HSP root is disclosed now names unclassified_components explicitly instead of
using a back-reference to the preceding app_pack_children mention.

Note on deferredRuntime: running all five flagged files in one process makes its 8-second catalog test time out under load. Run separately it passes. That is a local concurrency artifact, not a defect in this change.

Compatibility, safety, and release

The baseline's matching 6.6.0 Windows controls were restored from official CI run 39094414381 at the exact base SHA, with manifest/PE/SHA-256 validation; the files remain ignored. The npm 6.6.0 tarball was unavailable at verification time. No version/digest checks were relaxed.

This is static archive inspection, not device/runtime execution. Local Linux/macOS execution, actual duplicate same-path ZIPs and a new symlink-specific control were not verified. Remote selected CI lanes passed as recorded above; this does not mean every optional provider lane executed. Additional rows cost output bytes; no token, elapsed-time, CPU or memory improvement is claimed, and whole-task resource costs are unmeasured. Real Ghidra, IDA and Hopper lanes were not executed on this host; the projection itself performs no target execution. Windows native controls are absent here (native/windows/build/manifest.json ENOENT), which is unrelated to this change.

Merge Danger

Door: two-way. Revert the result field and classification complement together.

Blast Radius: Harmony projection output and its schema identity.

Author readiness

Human owner: @z2Ace0107

• I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
• I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
• I declare this PR ready for initial maintainer review.

Before merge

• One focused outcome linked to its source issue; relevant owning contracts and documentation updated.
• Actual observable behavior, negative controls and proof gaps recorded.
• Human owner completes Author readiness.
• Published-revision CI runs passed on both published heads; initial human readiness remains separate.