v1.16.0

[1.16.0] - 2026-09-03

New Features

• Module-level variables are now part of the graph, so shared state can be traced to the procedures that read and write it. (#251)
• A form's own lifecycle handlers — what runs when it opens, loads or closes — now connect to the form in the graph, the same way a button's click handler already did. (#247)
• VBA procedures now carry their real shape in the graph — whether something is a Sub, a Function or a property getter or setter, what it returns, and which parameters it takes, are optional or are passed by reference. (#250)
• SQL that creates, alters or drops a table now counts as a write to that table, and a query pointed at another Access database file with IN "…" now shows that file in the graph, so cross-backend access is finally visible. (#256)
• Access code that runs a macro, opens a table, exports a spreadsheet or emails a report now records which object it names, so those relationships show up in the graph instead of disappearing. (#254)
• Closing a form or report from code is now part of the graph, so a form's full lifecycle — who opens it and who closes it — is visible in one place. (#246)
• Opening a recordset or a query definition by its saved-query name now links the calling procedure to that query, so you can follow a procedure through the query it runs all the way to the tables it touches. (#253)
• Every parameter a VBA procedure declares is now its own symbol in the graph, linked to the procedure that owns it and to the class it is typed as, so you can ask which procedures take a given class and follow it from there. (#257)
• SQL that a form or control is bound to at runtime — assigned to RowSource, RecordSource, ControlSource, Filter or OrderBy — now shows the tables it reads, whether the statement is written inline or built up in a variable first. (#252)
• Access domain functions such as DLookup and DCount now record the table or saved query they read, so a procedure that touches data only through them no longer looks like it touches no data at all. (#255)
• Procedures now record how they handle errors — whether they have a handler, silently suppress errors, or have no protection at all — so unguarded code paths can be found without reading every module. (#259)
• An Access project that ships a generated structure export of its backend now gets real tables in the graph, with their columns, and linked tables point at the external database file they actually live in — so a table found from a query is the same table that carries its fields. (#257)
• Work a procedure does only when something goes wrong is now marked as such, and each error handler records whether it records the message, shows it to the user, re-raises it, or does more than one of those — so a procedure's failure path can be told apart from its normal one. (#260)
• Each error handler in Access code is now its own symbol you can search for and jump to, linked to the procedure that routes errors to it, so a handler can be found and followed directly instead of only asking whether a procedure has one. (#263)
• The variables this kind of Access project uses to pass error messages between objects are now recognised as such, so an error can be followed from where it happened to where the user sees it. (#261)
• New guidance shows how to find Access code that runs without error handling, including procedures with more than five executable statements that touch SQL tables, DoCmd targets, filesystem functions, or exact Kill/Open/Close statements, plus suppression scopes left open, missing handler labels, and where errors reach the user. (#262)

Changed

• Project-scoped CodeGraph resources can now be released non-interactively through the CLI or the opt-in MCP tool before deleting a worktree, without stopping unrelated projects. (#234)
• VBA extractor comments now describe the behavior they guard, and the rule-table invariant also validates the procedure pre-walk so future drift fails loudly. (#215)
• VBA classifiers now share one rule dispatcher with consistent scan modes, structural gates, counting, and declarative terminal behavior, preventing future rule tables from silently bypassing their documented preconditions. (#216)
• VBA extraction now exposes only the classifier factories used by the shared source walker, removing obsolete compatibility entry points and other unused public helpers. (#217)

Tests

• Removed documentation-prose and tautological assertions while retaining behavioral rule-table validation. (#214)

Fixes

• Initializing or indexing a project now reliably releases its database and parser workers after both successful runs and unexpected failures, preventing stale Windows file locks from blocking worktree removal. (#241)
• A VBA module that declares its own variable named Error no longer reports every On Error GoTo line as a read of it, so error-handling statements stop showing up as data access. (#292)
• VBA: a call written with the Call keyword, or with an argument list, is now reported as a call rather than as an ambiguous bare-identifier read, so a genuinely missing procedure is no longer filtered out by the constant-lookup rules meant for plain identifier reads. A bare name with no Call keyword and no arguments still counts as an identifier read, because it really can be a constant. (#265)
• A form or report whose file was saved under a different name than the module itself carries now gets its event handlers and control references wired up, instead of quietly coming through with none of them. (#249)
• VBA projects that reach their database through a named accessor — one per backend, for example — no longer lose the tables those queries touch, and recordsets opened with parentheses are now tracked like every other query. Projects whose accessors follow their own naming can list them in the project configuration. (#244)
• Calls into Access and VBA built-ins no longer create thousands of phantom symbols that show up in search results and node counts. (#245)
• Class setup and teardown routines in Access class modules are now recognised; the previous check looked for a constructor spelling that only exists in VB.NET, so it never matched real VBA code. (#248)
• VBA references mentioned only inside messages, logs, and other string literals no longer create false form, query, or temporary-variable relationships. (#209)
• VBA SQL extraction now ignores reserved words exposed by dynamic table-name concatenation instead of emitting misleading table references. (#203)
• VBA continued statements are now parsed as one logical line while retaining their original source locations, restoring class references, qualified calls, procedure headers, and API declarations split with line continuations. (#202)
• VBA SQL variables now stay within their procedure while module-level SQL remains available as a fallback, preventing same-named variables in separate procedures from creating false table references. (#204)
• VBA: colon-separated single-line procedures now close their scope on the same physical line and scan calls in their inline body, preventing later module constants from being misclassified and making procedure tracking consistent regardless of header placement. (#208)
• VBA: a local variable declared with Dim inside a procedure now keeps that procedure's type for the lifetime of the procedure instead of being silently overwritten by the last Dim of the same name anywhere in the file, so a item.Guardar call inside Sub AltaProducto (where Dim item As Producto was declared) no longer resolves to the Cliente class declared in Sub AltaCliente later in the same file. (#205)
• VBA conditional-compilation directives no longer silently delete a branch: an unterminated #If now emits a warning and restores the affected lines, and expressions the lexer cannot handle (string literals, floating-point, unknown syntax) are treated as could-not-evaluate and kept active by default. (#206)
• VBA Me.Name and Me!Field references inside comparisons, MsgBox arguments, and IIf expressions are now classified as reads (property-get / bang-get) instead of writes, while statement-form assignments such as Me.Name = "X" and Me!Field = 0 still classify as writes; all three reference-classification branches now share one direct-assignment predicate. (#211)
• VBA extraction no longer returns a graph fragment with a dangling edge when a .bas / .cls parse throws: malformed source still produces a parse_error and a valid (possibly partial) result, but edges that were being held pending module/class attribution are now dropped on the throw path instead of leaking into the returned graph. (#213)
• VBA Declare, Event, Enum, and Type header lines no longer leak phantom parameter-type references into the graph or pollute the qualified-call gate with parameter names, so the symbols these headers describe (real project classes, Win32 APIs, custom events, UDTs) keep their declared shape instead of being mistaken for project-local variables. (#207)