feat(graph+supervisor): layout dependency edges and graph-backed dependencies in validate_code#68
Open
fklosowski wants to merge 20 commits into
Open
feat(graph+supervisor): layout dependency edges and graph-backed dependencies in validate_code#68fklosowski wants to merge 20 commits into
fklosowski wants to merge 20 commits into
Conversation
…re adapter - Re-export `getPosition` utility for reuse in sibling modules. - Update `assembleResult` to accept and handle dependencies. - Implement `runStructure` to resolve outgoing dependencies using platformos-graph. - Add integration tests for dependency mapping in structure adapter. - Ensure linting and dependency resolution run concurrently in `validate_code`.
fklosowski
changed the title
…from GraphQL queries - Implemented extractGraphqlTable function to extract platformOS model table names from GraphQL operations. - Added unit tests for extractGraphqlTable covering various scenarios including shorthand and nested table filters. - Introduced GraphQL table extraction in the build process for schema modules. - Enhanced AppGraph and AppModule types to include schema and table properties. - Created fixtures for testing GraphQL queries with and without table filters. - Updated traversal logic to handle schema nodes and their associated table names.
- Updated index.ts to export `extractStructural` alongside `extractFileReferences`. - Introduced `GraphBuildOptions` in types.ts to control structural fact inclusion during builds. - Created adapter-input.ts to standardize input for lint and structure adapters. - Refactored lint.ts to utilize the new AdapterInput interface. - Enhanced assembleResult to include structural snapshots in the result. - Updated structure.ts to derive both dependencies and structural data from the same parse. - Added tests for validate-code to ensure lint and structure orchestration works as expected. - Improved error handling in validate-code to log structure resolution failures without dropping lint diagnostics.
- Updated DocumentsLocator to support canonical asset paths for both app and module assets. - Added tests to verify asset resolution under app/assets and module public/assets. - Introduced new asset edge handling in graph traversal and query logic. - Refactored asset module retrieval to use resolved URIs directly. - Improved integration tests to reflect changes in asset path resolution.
- Removed the `ValidateCodeDependency` and `ValidateCodeStructuralSnapshot` types and their associated logic. - Introduced `ValidateCodeImpact` type to represent cross-file blast radius. - Updated `assembleResult` function to accept and process impact data instead of dependencies and structural snapshots. - Modified `runStructure` to be removed, and its functionality replaced with impact analysis. - Adjusted `runValidateCode` to orchestrate linting and impact analysis, ensuring lint failures take precedence. - Updated tests to reflect changes in the impact analysis and ensure correct behavior. - Removed obsolete structure tests and integrated impact tests into the validation flow.
…hance GraphCache for fresh serving
- Add `deserializeAppGraph` function to reconstruct an in-memory AppGraph from its serialized form, ensuring round-trip identity and incremental readiness. - Introduce unit tests for `deserializeAppGraph` to validate serialization and deserialization processes, including edge cases for dangling edges and entry points. - Create a new module for graph cache persistence, including encoding and decoding cache files with versioning to handle corrupt or incompatible caches. - Enhance `GraphCache` to support loading from a persisted cache on cold starts, allowing for faster initialization and incremental updates. - Update server initialization to utilize the new cache path for improved performance and reliability.
…rove signature risk reporting
Second-round supervisor review of the supervisor-graph-integration branch
(division-of-responsibility + test hygiene). Additive/no-break except the
intended GraphQL table-shape widening; validate_code output is unchanged.
- Move extractGraphqlTable + extractSchemaTable (impl + specs) from
platformos-check-common to platformos-common: neutral platform-fact parsers
with no lint/offense use, so they belong beside frontmatter/RouteTable/
DocumentsLocator. Add browser-safe `graphql` dep to common; graph imports
from common; check-common drops the re-exports. Lossless move
(check-common 1057->1034 tests, common +23).
- Widen GraphQL table extraction: extractGraphqlTable (scalar, first-wins) ->
extractGraphqlTables returning every distinct table in document order as
string[] — across multiple records(...) blocks, aliased queries, and
record_create/mutation inputs; dedup; empty for none/dynamic/unparseable.
GraphQLModule.table?: string -> tables: string[] (required, always-present);
SchemaModule stays scalar. Factory + deserialize seed tables: []; graph
write-sites and specs updated. No supervisor/LSP/serialize reads .table(s).
- Convert graph incremental.spec + deserialize.spec from on-disk temp projects
(mkdtemp/NodeFileSystem) to the in-memory MockFileSystem (backing-object
mutation for add/modify/delete); replace [...].join('\n') line-arrays with
template literals. All 17 scenarios preserved; faster, no disk I/O.
- Document AppCache placement in check-node (JSDoc): why it lives there
(getApp globs disk = Node-only) and that no pre-existing mechanism
duplicates it (LSP DocumentManager / supervisor GraphCache are different
runtimes/payloads). No code moved.
- Update SUPERVISOR-GRAPH-INTEGRATION.md current-state refs (package
responsibilities, GraphQLModule shape, doubt #4 resolved).
…nsumer (TASK-9.17)
The supervisor's GraphCache hardcoded three pieces of graph-domain knowledge
(SOURCE_ROOTS, isEdgeSource, enumerateEdgeSources) that ADR 003 says belong in
platformos-graph. Nothing forced them to agree with the file-type classifier, so
a new source root / partial location added to the classifier would silently
diverge -> the fingerprint scan omits real edge sources -> incomplete entry
points -> dependentsOf under-reports -> a wrong "0 dependents, safe to change".
- Add platformos-graph/src/graph/edge-sources.ts exporting isEdgeSource and
enumerateEdgeSources (scoped SOURCE_ROOTS walk), moved verbatim from the
supervisor. isEdgeSource derives from the classifier (isLayout/isPage/
isPartial), so "which files" has one source of truth.
- graph-cache.ts drops its local copies + now-unused imports and consumes the
graph primitive; still owns fingerprint/cache/persistence/reconcile.
- Guardrail edge-sources.spec.ts (MockFileSystem): the scoped walk must equal a
whole-tree walk filtered by isEdgeSource, over a fixture spanning every source
root + a bundled react-app/ sibling -> drift fails the build.
getModule resolved a partial entry point via getPartialModule(graph, path.basename(uri, '.liquid')), which rebuilds the path as app/views/partials/<basename>.liquid — dropping the file's directory and forcing the app/views/partials location. Every lib/ or nested partial (e.g. app/lib/commands/execute.liquid, app/lib/can/payment_request.liquid) was mis-keyed to a phantom app/views/partials/<basename> node (exists:false, no edges), split from the SAME file resolved as an edge target (which correctly uses getPartialModuleByUri). Layout/page/asset entry points already key by full URI; partials were the odd one out (assets were fixed in d09ab82, partials left behind). Pre-existing on master; latent until tested against a real project whose lib/ layer holds commands/queries/permission helpers. Impact: the full build dropped these partials' real edges and materialized a phantom exists:false node; incremental applyFileChange re-materialized the real node, so incremental DIVERGED from a full build (a never-stale violation). Dependents/blast-radius/dead-code for the entire lib/ layer were wrong — the tool could report "safe to change" on heavily-depended-on files. Fix: getModule's partial branch keys by the file's own resolved URI via getPartialModuleByUri(graph, uri), consistent with the other factories. Flat app/views/partials/* partials are byte-identical (no behavior change); only lib/nested partials are corrected. Name-based getPartialModule retained (test factory). Added getModule regression tests to module.spec.ts.
…anch
Follow-up cleanup to TASK-9.23 (the lib-partial mis-keying fix), removing the
rest of the same fragile-assumption class.
- Delete getModule's unreachable `relativePath.startsWith('assets') ||
startsWith('modules')` branch (and its now-unused relativePath). Both callers
(buildAppGraph entry points, incremental applyFileChange) only ever pass
edge-source URIs, caught by the isLayout/isPage/isPartial cases above; the
branch was dead, and startsWith('assets') was already false for real
app/assets/ paths anyway.
- Delete the name-based getPartialModule factory, which rebuilt every partial
path as app/views/partials/<name>.liquid — the exact hardcoded-path
assumption behind TASK-9.23. It was internal and only used by two test specs.
- Migrate serialize.spec / query.spec to getPartialModuleByUri with explicit
URIs (identical node keys; assertions unchanged).
- Fix the dangling {@link getPartialModule} references in
getPartialModuleByUri's docs.
getModule now keys every entry point (layout/page/partial) by its own resolved
URI — one rule, no path reconstruction.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.