Understand complicated SQL without tracing every branch by hand.

---

proc>flow is a local-first SQL logic and dependency visualiser for database administrators, SQL report engineers, developers, analysts, and reviewers. Paste SQL or import a group of SQL files to see:

• how a procedure, function, trigger, view, or query works internally; and
• how database objects read, write, and call one another.

There is no installation, database connection, backend service, or sign-in. The application runs entirely in a browser and works from the local filesystem.

Important

ProcFlow uses a heuristic parser rather than a database engine's compiler. Treat diagrams as investigation aids. Check important findings against the source SQL and the target database.

For the first stable release, see RELEASE_NOTE_v1.0.0.md. For the v1.1.0 release, see RELEASE_NOTE_1.1.0.md. For the v1.2.0 release, see RELEASE_NOTE_1.2.0.md. For the v1.3.0 release, see RELEASE_NOTE_1.3.0.md. For the v1.4.0 release, see RELEASE_NOTE_v1.4.0.md. For the v1.5.0 release, see RELEASE_NOTE_v1.5.0.md. For the v1.6.0 release, see RELEASE_NOTE_v1.6.0.md. For the v1.7.0 release, see RELEASE_NOTE_v1.7.0.md. For the v1.8.0 release, see RELEASE_NOTE_v1.8.0.md. For the v1.9.0 release, see RELEASE_NOTE_v1.9.0.md. For the v1.10.0 release, see RELEASE_NOTE_v1.10.0.md.

Start here

I want to…	Go to
Open ProcFlow and try it now	60-second quick start
Review a stored procedure, function, or trigger	Workflow for DBAs
Understand a report or dataset query	Workflow for SQL report engineers
Understand confidence, coverage, and warnings	Reading the analysis safely
Check privacy or prepare a security review	Security and privacy
Build, test, or change the project	Developer guide
Prepare a release	Release checklist

60-second quick start

1. Download the v1.10.0 archive from GitHub Releases or clone this repository.
2. Extract the complete archive. Keep index.html, styles.css, dist/, and vendor/ together.
3. Open index.html in a recent Chrome, Edge, Firefox, or Chromium browser.
4. Choose one input:
   • press Load sample;
   • paste SQL into SQL source; or
   • press Import SQL files and select one or more files.
5. Press Refresh or use Ctrl+Enter (Cmd+Enter on macOS).

No npm install, local server, database, or internet connection is required for normal use.

If the page opens but the diagram does not render, first confirm that the whole archive was extracted. Opening a copied index.html without its sibling dist/ and vendor/ directories will not work.

Workflow for database administrators

Use ProcFlow to shorten the first pass through unfamiliar routines and change reviews.

1. Import the relevant .sql, .ddl, or .txt files.
2. Set Scope to Object dependencies to see routine calls and table reads/writes across the imported files.
3. Select a known object in the diagram or use the Object selector.
4. Set Scope to Internal logic.
5. Use View → Control flow for branches, loops, transactions, exits, and error paths.
6. Check Confidence, Coverage, and Diagnostics before relying on the chart.
7. Click a source-aware diagram node to select its SQL in the editor.
8. Use Export to save SVG or editable draw.io XML when the diagram is ready to share.

Useful DBA review questions include:

• Which tables are read or changed?
• Which routines are called?
• Can execution exit before a commit or final result?
• Where can an exception or error be handled, rethrown, or terminate work?
• Does transaction state affect the available recovery path?
• Is any dynamic SQL hiding behavior from static analysis?

When automatic dialect detection is uncertain, select the dialect explicitly and refresh the analysis.

Workflow for SQL report engineers

Use ProcFlow to understand report datasets, extracts, views, and large SELECT statements.

1. Paste the dataset query or import its SQL file.
2. Leave View on Auto, or choose Query structure explicitly.
3. Review CTEs, source tables, explicit joins, unions, subqueries, filtering, and grouping.
4. Turn Source tables on or off to adjust the amount of detail.
5. For several views or queries, use Object dependencies to see shared sources and upstream objects.
6. Check Coverage and Diagnostics, especially for vendor-specific table expressions or comma-separated sources.
7. Export the result as SVG or draw.io when documenting a report or handing analysis to another engineer.

ProcFlow imports SQL text, not report-definition files. SSRS/RDL import is on the roadmap; for v1.10.0, paste or export the dataset SQL itself.

What ProcFlow can show

Internal control flow

• IF, ELSE, and CASE decisions
• loops, loop exits, and early returns
• labelled loop-control and GOTO, with source span selection and explicit "Unresolved label" nodes for missing targets
• cursor operations and the query behind a cursor
• statements and result sets
• procedure and function calls
• table reads and writes
• temporary-table transformations, with producer→consumer data-flow edges on provably linear paths
• transactions and savepoints
• exception handling and T-SQL TRY/CATCH
• dynamic SQL as an explicit opaque step

Query structure

• common table expressions (including recursive CTEs, marked and annotated)
• source tables and views, including comma-separated FROM lists
• CROSS/OUTER APPLY and tabular functions (UNNEST, XMLTABLE, JSON_TABLE, GENERATE_SERIES) as source references
• derived-table/subquery inner sources
• MERGE … USING and DELETE … USING read sources
• explicit joins
• unions
• subqueries
• filtering
• grouping

Object dependencies

• procedure or function → called routine
• view or query → source object
• object → table read
• object → table write

Known imported objects are linked. Selecting one can open its internal logic. With a catalogue loaded, unmatched references the catalogue proves — an exact full-name match, or an explicit synonym — resolve to their canonical identity instead of a conservative label. Unmatched three-/four-part names keep their complete identity as external: [server].[database].[schema].[object] nodes rather than collapsing to a bare last-part match.

Reading the analysis safely

The analysis panel provides four release-safety signals:

• Confidence is a single headline number from a versioned formula (v1.6.0) built on per-region signals: dialect certainty × the token-weighted quality of each statement region (resolved / approximate / opaque / error) × a coverage factor. The health band (high/medium/low) is derived from the same formula, so it can never disagree with the percentage. Coverage alone never raises confidence: an object whose tokens all land in opaque dynamic-SQL regions stays at 40 % even at 100 % coverage.
• Coverage is the percentage of body tokens consumed by the parser.
• Diagnostics reports uncertain dialects, balance errors, missing block terminators, unconsumed input, invalid actions, opaque dynamic SQL, opaque table expressions, heuristic APPLY targets, ambiguous and opaque column references (v1.10.0), and catalogue problems (malformed or conflicting catalogue data, and unproven partial matches reported at the exact reference). Informational annotations (for example a correctly resolved recursive CTE) are displayed separately and never inflate the findings count. Document-scoped findings such as dialect ambiguity carry no fabricated source span.
• Constructs reports how many branches, loops, handlers, CTEs, source references, and temp-flow links were detected, resolved, or left opaque.

Use this rule of thumb:

• High confidence and complete coverage: review the chart, then verify material findings in the SQL.
• Reduced confidence: select the dialect manually and inspect the diagnostics.
• Incomplete coverage: treat the unresolved source region as a review item.
• Dynamic SQL warning: review the generated SQL separately; its internal reads, writes, calls, and branches cannot be inferred safely.

Input the parser cannot consume is represented as an unresolved node rather than silently disappearing from the diagram.

Supported SQL

ProcFlow v1.10.0 recognises:

• Microsoft T-SQL
• IBM DB2 SQL PL
• PostgreSQL PL/pgSQL
• SQLite

Supported inputs include procedures, functions, triggers, views, plain SQL statements, report dataset queries, and multi-object scripts where those object types apply to the selected dialect.

Dialect-specific v1.10.0 coverage includes:

• T-SQL: mixed one-line and block IF/WHILE control flow (single statement and BEGIN/END bodies in one AST), labelled GOTO and labels with source spans plus a goto_unresolved diagnostic and explicit "Unresolved label" node, cursor queries (DECLARE … CURSOR FOR) in the query graph, concise GRANT/WAITFOR/KILL/cursor-operation labels, semicolon-free statements with grammar-driven boundaries, TRY/CATCH, THROW, RAISERROR severity, XACT_STATE(), @@TRANCOUNT, nested transaction depth, savepoints (including savepoint-only recovery declared in TRY and rolled back in CATCH), SET XACT_ABORT (annotated when set inside a CATCH), invalid transaction-action termination, and temporary-table producer→consumer data-flow edges with conservative branch merges.
• DB2 SQL PL: mixed THEN and BEGIN/END IF forms, BEGIN ATOMIC rollback scope, labelled loop control and LEAVE/ITERATE target validation, FOR … CURSOR FOR queries in the query graph, scoped handlers, and NOT FOUND flow.
• PL/pgSQL: EXCEPTION condition matching, transactional exception scopes, rethrow propagation, and labelled loop-control target validation.
• SQLite: trigger RAISE actions, termination behavior, trigger WHEN, conditional WHERE, and searched CASE paths.

Across dialects, Query structure view reports every read source: a comma-separated FROM list, an APPLY or tabular function, a MERGE…USING / DELETE…USING source, a recursive CTE, and a derived-table inner table all appear as source nodes.

Since v1.10.0, each query-bearing SELECT statement also gets column-level analysis (README roadmap item 6 foundations): qualified references, aliases, projections, CTE and derived-table scopes, and catalogue-backed wildcard expansion produce exact input→output column bindings with source spans. An unqualified reference that matches several sources is reported as ambiguous and never invents a binding, and unsupported expressions (for example a scalar subquery) become opaque with a region-scoped diagnostic. Multi-statement temporary-table column flow and inter-object column flow remain on the roadmap (v1.11.0).

Detection is automatic and can be overridden from the Dialect selector. When detection is uncertain and several dialects score equally, an explicit dialect_ambiguous diagnostic is reported along with the usual low-confidence warning.

Catalogue resolution (README item 5, delivered in v1.9.0) applies across dialects: when a catalogue is loaded, object references the catalogue proves are shown as verified identity instead of external labels. See Working with a catalogue.

Importing SQL

Import SQL files accepts multiple .sql, .ddl, and .txt files. Files are read into memory by the current browser tab; they are not uploaded and are not persisted automatically.

Multi-object scripts are split into selectable objects. If the split cannot be made confidently, ProcFlow keeps the input as one script and reports the uncertainty.

Working with a catalogue

The Catalogue menu imports table/view/column metadata so ProcFlow can resolve object references to their exact identity instead of a conservative external: label.

• Paste or import. Type a catalogue into the textarea (or press Import file) and press Apply catalogue. Two formats are accepted:
  • JSON — {"objects":[{"name":"dbo.Student","kind":"TABLE", "synonyms":["student"]}], "columns":[{"table":"dbo.Student","name":"Id"}]} (a bare array of objects or names also works);
  • simple line format — one object per line: name KIND syn1, syn2 plus COL table.column column lines; # lines are comments.
• Verified resolution. Only exact full-name matches and explicit synonyms count as verified. In Object dependencies scope and the Query structure view, a verified reference renders as its canonical object name (no external: prefix) and carries the resolution as metadata on draw.io exports.
• Conservative when uncertain. A reference that only partially matches (for example a server prefix over a catalogued object) stays external and gets a region-scoped catalogue_partial diagnostic naming the unproven candidate. Duplicate or colliding catalogue entries produce a catalogue_conflict diagnostic and never invent a verification.
• Clear removes the catalogue; applying a different catalogue re-runs the current analysis. The catalogue is an analysis input, so a saved workspace captures it and Restore reproduces an identical analysis.

Workspace

The Workspace menu keeps your work usable across sessions, entirely on your terms:

• Save to this browser persists the current workspace (files, analysis options, and any applied catalogue text) to this browser's localStorage. This is strictly opt-in — nothing is written or restored on load.
• Restore saved workspace replays the saved files, options, and catalogue into an identical analysis.
• Export workspace file / Import workspace file transfer a workspace as portable JSON.
• Forget saved workspace removes the local copy explicitly.

Saved workspaces are versioned (so future releases can migrate them) and, if corrupt or unreadable, are recovered by starting fresh rather than crashing.

Dependency filtering

In Object dependencies scope, the Filter dependencies menu offers presentation-only filters over the estate diagram: show/hide Reads, Writes, and Calls edges; show/hide External objects and Temp tables nodes; and a Focus box that keeps an object and its direct neighbours. Filtering derives a filtered view at render time and never changes the underlying analysis graph, so confidence, coverage, diagnostics, and the reported stats stay exactly as analysed.

Exporting and sharing

The Export menu provides:

• Copy Mermaid — copy the generated Mermaid definition.
• Copy narration prompt — copy a prompt containing diagram structure and source SQL.
• Save SVG — download the rendered diagram.
• Save draw.io — download editable native .drawio XML, placed by a deterministic, data-flow-aware layered layout. Exporting the same SQL always produces the same coordinates, with temp-table data-flow edges routed in a dedicated lane.

The narration prompt is never submitted automatically. It reaches another system only if a user pastes it there. Review organisational policy before sharing confidential SQL.

draw.io is a trademark of draw.io AG. ProcFlow is not affiliated with or endorsed by draw.io.

Security and privacy

Quick answers

Question	ProcFlow v1.10.0 behavior
Is SQL uploaded?	No. Analysis and rendering happen in the browser tab.
Does it connect to a database?	No. There is no driver, connection string, or query execution.
Is there a backend or API?	No. It is a static HTML, CSS, and JavaScript application.
Is there analytics or telemetry?	No.
Is internet access required?	No for local or internally hosted use.
Are imported files uploaded?	No. The browser File API reads them into the current tab.
Is SQL retained after closing the tab?	No by default. ProcFlow does not use cookies, sessionStorage, or IndexedDB, and does not write to localStorage on load. A workspace is kept across sessions only when you explicitly choose Save to this browser in the Workspace menu.
Is a saved workspace stored on this computer?	Only if you choose Save to this browser. It is written to this browser's localStorage, is local-only, versioned, exportable to a JSON file, and removed by Forget saved workspace or by clearing browser site data.
Does ProcFlow write to the clipboard automatically?	No. Clipboard writes follow an explicit copy action.
Are exports local?	Yes. SVG and draw.io files are generated in memory and downloaded by the browser.
Does it call an AI service?	No. It can copy a narration prompt but never submits it.

Runtime files

The runtime application consists of:

index.html
styles.css
dist/src/tokenizer.js
dist/src/catalogue.js
dist/src/dialects.js
dist/src/lineage.js
dist/src/ir.js
dist/src/columns.js
dist/src/exporters.js
dist/src/workspace.js
dist/src/app.js
vendor/mermaid/mermaid.min.js

There is no application fetch, XMLHttpRequest, WebSocket, beacon, or other network-submission code. The only bundled third-party runtime is the pinned Mermaid 10.9.1 renderer. Its MIT licence is stored at vendor/mermaid/LICENSE.

The opt-in persistence module (dist/src/workspace.js) is the only runtime that touches browser storage, and it does so only through explicit Workspace menu actions (Save / Restore / Forget) — never on load. Its import/export uses the browser download API, which also requires an explicit action. The catalogue module (dist/src/catalogue.js) parses pasted or imported metadata in memory only; it never reads or writes storage.

The SHA-256 of vendor/mermaid/mermaid.min.js in v1.10.0 is:

61B335A46DF05A7CE1C98378F60E5F3E77A7FB608A1056997E8A649304A936D6

The repository's .gitattributes preserves this vendored file byte-for-byte so the release checksum remains reproducible across operating systems.

Guidance for security review

1. Review and pin the v1.10.0 tag or its exact commit.
2. Verify the vendored Mermaid checksum.
3. Review the runtime files listed above.
4. Open the reviewed files locally or serve them from an approved internal static host.
5. Keep browser extensions and developer tools within organisational policy.
6. Re-review runtime and dependency changes before upgrading.
7. Apply the organisation's Content Security Policy at the hosting layer when serving ProcFlow over HTTP.

If ProcFlow is served through GitHub Pages or another host, that host receives ordinary web-request metadata while serving the static files. ProcFlow still does not place entered SQL in those requests. Organisations that do not permit public hosting should use the release files locally or on an internal static server.

The primary deliberate data-release action is Copy narration prompt. It places SQL and diagram structure on the clipboard. Users remain responsible for where that information is pasted or saved.

No browser application can guarantee the security of the host computer, browser, installed extensions, modified source files, or external destination. ProcFlow's boundary is that its own application code performs analysis locally and contains no automatic data-submission path.

Known limitations

• Parsing is heuristic and does not provide the guarantees of the target database engine's parser.
• Dynamic SQL is opaque.
• Statement boundaries no longer depend on newline position: semicolons are authoritative and omitted semicolons are split by control keywords and statement grammar. Exceptionally malformed batches can still produce imperfect splits.
• Query lineage is object-level; since v1.10.0 a single query statement also reports column-level scopes and bindings, while multi-statement temporary-table and inter-object column flow remain on the roadmap (v1.11.0).
• Some vendor-specific table expressions might not be detected.
• Temporary-table data flow is shown within one object; cross-object temp flow remains unresolved.
• Catalogue resolution is deliberately conservative: only exact full-name and explicit-synonym matches are verified. Suffix-only matches, unqualified names without a catalogue synonym, and unknown linked-server layouts stay external (with a catalogue_partial diagnostic where a plausible but unproven candidate exists) until the catalogue proves them.
• Columns are parsed and validated by the catalogue import and, since v1.10.0, drive wildcard expansion and column bindings inside a single statement. Column flow across statements, objects, and CTE/view boundaries is scheduled for v1.11.0.
• SSRS/RDL files are not imported in v1.9.0.
• draw.io layout is deterministic for the documented graph classes at documented size limits; very large or non-planar graphs are laid out without overlapping boxes and reported honestly rather than claimed crossing-free.

Always confirm critical dependencies, execution paths, transaction behavior, and security conclusions against the original SQL and target database.

Developer guide

Prerequisites

• Node.js 22 is recommended and is the CI baseline.
• npm, included with Node.js.
• A recent Chrome, Edge, or Chromium browser for the local-file smoke test.
• Python 3 is optional and is used only for the simple manual test server shown below.

First checkout

git clone https://github.com/ikelaiah/ProcFlow.git
cd ProcFlow
npm ci
npm run typecheck
npm run build
npm run test:file

npm run test:file opens the real index.html through a file:// URL in a headless Chromium browser and verifies that the page and all local runtime scripts initialise. The runner automatically looks for Chrome, Edge, or Chromium. If the browser is installed in a non-standard location, set CHROME_PATH to its executable.

Source and generated files

Make source changes in src/ or tests/. npm run build compiles TypeScript into browser-ready JavaScript and source maps under dist/.

dist/ is committed deliberately so an end user can open index.html without installing a toolchain. After source changes:

npm run typecheck
npm run build
git status --short

Commit the matching generated dist/ files with their TypeScript sources.

Full browser suites

Start a local static server from the repository root:

python -m http.server 8000

Then open:

• http://127.0.0.1:8000/tests/index.html — golden parser, graph, dependency, and exporter tests
• http://127.0.0.1:8000/tests/fuzz.html — deterministic mutation and invariant tests
• http://127.0.0.1:8000/tests/ui.html — browser interaction and local-runtime tests

The v1.10.0 baseline is:

• 209 golden and boundary assertions
• 400 deterministic mutation cases
• 22 browser interaction tests
• 20 export-parity checks (10 fixtures × TD + LR), 11 layout-budget fixtures, and 100 % export-traceability on the export fixtures
• 13 workspace-persistence and dependency-filtering fixtures (save→reload identity, schema migration, corrupt recovery, explicit clear, non-mutating filters)
• 13 catalogue fixtures (JSON and line import, synonym / linked-server / cross-database verification, conservative conflict and partial diagnostics, export metadata, workspace round-trip)
• 18 column-lineage fixtures (qualified references, aliases, projections, CTE and derived-table scopes, catalogue-backed wildcard expansion, ambiguous and opaque column references with exact spans)

Fixture-corpus accuracy metrics (attribution, unresolved-token, tail-unconsumed, fallback, opaque-dynamic, semantic-edge coverage, provenance, region-diagnostic-to-span, export-parity, export-traceability, layout-budget, workspace, catalogue, and column pass-rate ratios) are published from the checked-in golden corpus in docs/metrics-v1.10.0.json. Generation is deterministic and fixture-only — no user inputs or runtime telemetry are collected — and CI refuses to merge when the snapshot is stale. Regenerate with npm run metrics:write.

GitHub Actions installs dependencies, type-checks, builds, verifies generated files, runs the local-file smoke test (including the opt-in workspace assertion), checks that the runtime remains local-only (no external URLs or network APIs, and browser storage confined to the opt-in persistence module), verifies the metric snapshot, and runs all three served browser suites on every push and pull request.

Project structure

index.html
styles.css
README.md
ROADMAP.md
package.json
package-lock.json
tsconfig.json
.gitattributes
.github/
└── workflows/
    └── correctness.yml
assets/
└── procflow-logo.svg  # adaptive light/dark README wordmark
docs/
├── PR_NOTE_1.1.0.md
├── PR_NOTE_1.2.0.md
├── PR_NOTE_1.3.0.md
├── PR_NOTE_1.4.0.md
├── PR_NOTE_1.5.0.md
├── PR_NOTE_1.6.0.md
├── PR_NOTE_1.7.0.md
├── PR_NOTE_1.8.0.md
├── PR_NOTE_1.9.0.md
├── PR_NOTE_1.10.0.md
├── RELEASE_NOTE_1.1.0.md
├── RELEASE_NOTE_1.2.0.md
├── RELEASE_NOTE_1.3.0.md
├── RELEASE_NOTE_v1.0.0.md
├── RELEASE_NOTE_v1.1.0.md
├── RELEASE_NOTE_v1.2.0.md
├── RELEASE_NOTE_v1.3.0.md
├── RELEASE_NOTE_v1.4.0.md
├── RELEASE_NOTE_v1.5.0.md
├── RELEASE_NOTE_v1.6.0.md
├── RELEASE_NOTE_v1.7.0.md
├── RELEASE_NOTE_v1.8.0.md
├── RELEASE_NOTE_v1.9.0.md
├── RELEASE_NOTE_v1.10.0.md
└── metrics-v1.10.0.json   # deterministic fixture-only accuracy metrics snapshot
examples/
├── dbo.v110_demo.sql    # per-release outcome demos
├── dbo.v120_demo.sql
├── dbo.v130_demo.sql
├── dbo.v140_demo.sql
├── dbo.v150_demo.sql
├── dbo.v160_demo.sql
├── dbo.v170_demo.sql    # v1.7.0: clear deterministic exports demo
├── dbo.v180_demo.sql    # v1.8.0: usable local workspace demo
├── dbo.v190_demo.sql    # v1.9.0: resolve by catalogue demo
└── dbo.v1100_demo.sql   # v1.10.0: column lineage foundations demo
scripts/
├── file-smoke.mjs    # dependency-free local-file release smoke test
└── metrics.mjs       # generate/verify the fixture-corpus metric snapshot
src/
├── types.d.ts        # shared tokens, AST, graphs, diagnostics, and contracts
├── tokenizer.ts      # lexical analysis, escaping, balance checks, source spans
├── catalogue.ts      # catalogue import (JSON + line) and object resolution
├── dialects.ts       # dialect detection and procedural parsing
├── lineage.ts        # CTE and query dependency extraction
├── ir.ts             # graphs, diagnostics, confidence, and estate analysis
├── columns.ts        # v1.10.0: single-statement column scopes and bindings
├── exporters.ts      # Mermaid, draw.io, and narration output
├── workspace.ts      # opt-in persistence + presentation-only dependency filtering
└── app.ts            # browser UI and workspace interaction
dist/                 # generated JavaScript and source maps
├── src/
└── tests/
tests/
├── index.html
├── fuzz.html
├── ui.html
├── metrics.html
├── fixtures.ts
├── tsql-fixtures.ts
├── boundary.ts
├── parity.ts
├── workspace.ts
├── catalogue.ts
├── columns.ts        # v1.10.0: column lineage foundations fixtures
├── tests.ts
├── fuzz.ts
├── ui-tests.ts
├── metrics.ts
└── dialects/
    ├── db2.ts
    ├── tsql.ts
    ├── plpgsql.ts
    └── sqlite.ts
vendor/
└── mermaid/
    ├── mermaid.min.js
    └── LICENSE

The shared model uses a discriminated TypeScript AST and records source spans, branches, loops, scoped handlers, reads, writes, calls, result sets, diagnostics, and graph structures.

Release checklist

Run the following from a clean checkout before tagging a release:

npm ci
npm run typecheck
npm run build
npm run test:file
git status --short

Then verify:

1. The three served browser suites pass.
2. git status --short shows only the intended release changes.
3. Generated dist/ files match their TypeScript sources.
4. The Mermaid SHA-256 matches the value in this README and the workflow.
5. npm run metrics reports the metric snapshot is current.
6. RELEASE_NOTE_v1.10.0.md matches the final tag contents.
7. The complete archive opens locally with index.html, and the local-file smoke test reports the opt-in workspace assertion.
8. The tag is named v1.10.0.

The release can then be created manually from the v1.10.0 tag using RELEASE_NOTE_v1.10.0.md.

Roadmap after v1.0.0

1. Expand the anonymised golden SQL fixture corpus.
2. Improve table-function, APPLY, comma-source, and DML lineage.
3. Model more multi-statement and temporary-table transformations.
4. Import SSRS/RDL definitions and link reports to datasets.
5. Accept database catalogue metadata for more accurate object resolution. Delivered in v1.9.0.
6. Add column-level lineage where it can be resolved safely. Foundations delivered in v1.10.0 (column scopes, bindings, projections, CTE/derived-table scopes, and catalogue-backed wildcard expansion within one statement); full column-flow pipelines through temp tables and object boundaries are scheduled for v1.11.0.
7. Add optional local workspace persistence and dependency filtering. Delivered in v1.8.0.
8. Separate graph, transaction, and estate-analysis internals while preserving the v1.0.0 behavior through golden tests. Delivered in v1.1.0.

Contributing and reporting problems

A useful bug report includes:

• the selected and detected dialect;
• a minimal anonymised SQL example;
• the generated Mermaid source;
• the expected control flow or dependency;
• the reported confidence, coverage, and diagnostics; and
• the browser and version.

For parser changes, add a focused fixture that fails before the change and passes afterward. Run type-checking, the build, the local-file smoke test, and the relevant browser suites before opening a pull request.

Never include production credentials, confidential data, or SQL that cannot be shared safely in a public issue.