@razdolbai/merls 0.1.0

package/.serena/memories/conventions.md

@@ -0,0 +1,6 @@
+- TDD is mandatory from the start; implementation tasks begin with a failing test or fixture.
+- Keep parser-based MVP; do not introduce external `merlin32` execution in the first implementation pass.
+- Separate parser, symbol-resolution, and LSP layers.
+- TypeScript naming: `camelCase` for values/functions, `PascalCase` for types/classes, kebab-case for config/example filenames.
+- Fixture convention: positive fixtures cover supported Merlin-style 6502 syntax; negative fixtures cover unsupported 65816 syntax and expected diagnostics.
+- Task completion rule: if behavior, structure, workflow, or contributor expectations change, update both `README.md` and `AGENTS.md`.

package/.serena/memories/core.md

@@ -0,0 +1,8 @@
+- Completed MVP repo; current durable docs are \README.md\, \PLAN.md\, \AGENTS.md\.
+- Purpose: standalone LSP server for Merlin-style 6502 assembly, primary editor target coc.nvim, stdio transport.
+- Scope invariant: 6502-only. 65816 syntax is out of scope and should be diagnosed as unsupported.
+- Implementation plan and phase breakdown live in \PLAN.md\. All planned tasks are completed.
+- Contributor rules and doc-maintenance requirement live in \AGENTS.md\.
+- For stack and workspace layout, read \mem:tech_stack\.
+- For code/test/doc conventions, read \mem:conventions\.
+- For done criteria and required verification/docs updates, read \mem:task_completion\.

package/.serena/memories/memory_maintenance.md

@@ -0,0 +1,33 @@
+# Memory Maintenance
+
+## Discovery Model
+
+- Core principle: progressive discovery through references, building a graph of memories.
+- Initially, agents are provided with the list of all memories (names only).
+- Agents should read `mem:core` as the top-level entry point (graph root).
+  This memory should contain references to other memories covering major project domains.
+  The referenced memories shall, in turn, shall contain references to even more specific memories, and so on.
+  The depth of the graph shall depend on the project complexity.
+- Use topics/folders to group related memories in order to make the content structure explicit.
+  Folders can mirror project structure (e.g. modules like frontend/backend) or topics like debugging, architecture, etc.
+- Memory references must use a mem: prefix inside backticks, e.g. `mem:frontend/core`.
+  The surrounding text should clearly indicate when to read the memory/which content to expect.
+  The text should provide more precise guidance than the memory name alone, 
+  i.e. avoid a reference like "frontend debugging: `mem:frontend/debugging` and instead make clear which aspects of frontend debugging are covered.
+- Memories themselves should not contain information about when to read them; this is the responsibility of the referring memory.
+
+## Style
+
+Dense agent notes, not prose docs. Prefer invariants, terse bullets. 
+Avoid obvious context, rationale, and examples unless they prevent likely mistakes. 
+Keep guidance durable and generalizable, not task-local.
+
+## Add/update threshold
+
+Add or update memories only with stable, non-obvious project conventions that avoid complex rediscovery in the future.
+Do not add: quick-read facts; generic language/framework knowledge; one-off task notes; volatile line-level details; behavior likely to change soon.
+
+## Maintenance Actions
+
+- Renaming memories: References are updated automatically if handled via Serena's memory rename tool.
+- Checking for stale memories (e.g. after deletion): Call `serena memories check` for a report.

package/.serena/memories/suggested_commands.md

@@ -0,0 +1,4 @@
+- Windows shell is PowerShell; use PowerShell forms when documenting local commands.
+- Current useful repo commands are read-only/doc-oriented: `Get-ChildItem`, `Get-Content README.md`, `Get-Content PLAN.md`, `Get-Content AGENTS.md`.
+- Planned commands after Phase 1 scaffolding: `npm install`, `npm run build`, `npm test`, `npm run dev` (or equivalent stdio server runner).
+- Do not assume npm scripts exist until `package.json` is added.

package/.serena/memories/task_completion.md

@@ -0,0 +1,7 @@
+- A coding task is not done until relevant tests/fixtures added first by TDD are passing under the repo's actual toolchain.
+- The project has a runnable build/test command (\
+pm run build\, \
+pm test\); use them.
+- Always review whether the task changed project behavior, structure, workflow, or contributor expectations.
+- If yes, update both \README.md\ and \AGENTS.md\ in the same task.
+- Preserve scope invariants: 6502 support only, 65816 rejection explicit, coc.nvim/stdio integration target unchanged unless the docs and plan are updated together.

package/.serena/memories/tech_stack.md

@@ -0,0 +1,6 @@
+- Node.js runtime, TypeScript implementation, \scode-languageserver\ for LSP.
+- Server model: standalone process over stdio; coc.nvim launches it via standard \languageserver\ config.
+- Workspace shape: \src/\ for implementation, \	est/\ for automated tests, \xamples/\ for coc.nvim config/examples, dedicated fixture directories for assembly corpora.
+- Built via \
+pm run build\ and tested via \
+pm test\.

package/.serena/project.yml

@@ -0,0 +1,132 @@
+# the name by which the project can be referenced within Serena
+project_name: "merls"
+
+
+# list of languages for which language servers are started; choose from:
+#   al                  angular             ansible             bash                clojure
+#   cpp                 cpp_ccls            crystal             csharp              csharp_omnisharp
+#   dart                elixir              elm                 erlang              fortran
+#   fsharp              go                  groovy              haskell             haxe
+#   hlsl                html                java                json                julia
+#   kotlin              lean4               lua                 luau                markdown
+#   matlab              msl                 nix                 ocaml               pascal
+#   perl                php                 php_phpactor        powershell          python
+#   python_jedi         python_ty           r                   rego                ruby
+#   ruby_solargraph     rust                scala               scss                solidity
+#   svelte              swift               systemverilog       terraform           toml
+#   typescript          typescript_vts      vue                 yaml                zig
+#   (This list may be outdated. For the current list, see values of Language enum here:
+#   https://github.com/oraios/serena/blob/main/src/solidlsp/ls_config.py
+#   For some languages, there are alternative language servers, e.g. csharp_omnisharp, ruby_solargraph.)
+# Note:
+#   - For C, use cpp
+#   - For JavaScript, use typescript
+#   - For Angular projects, use angular (subsumes typescript+html; requires `npm install` in the project root)
+#   - For Svelte projects, use svelte (subsumes typescript/javascript for .svelte projects; requires npm)
+#   - For SCSS / Sass / plain CSS, use scss (some-sass-language-server handles all three)
+#   - For Free Pascal/Lazarus, use pascal
+# Special requirements:
+#   Some languages require additional setup/installations.
+#   See here for details: https://oraios.github.io/serena/01-about/020_programming-languages.html#language-servers
+# When using multiple languages, the first language server that supports a given file will be used for that file.
+# The first language is the default language and the respective language server will be used as a fallback.
+# Note that when using the JetBrains backend, language servers are not used and this list is correspondingly ignored.
+languages: []
+
+# the encoding used by text files in the project
+# For a list of possible encodings, see https://docs.python.org/3.11/library/codecs.html#standard-encodings
+encoding: "utf-8"
+
+# line ending convention to use when writing source files.
+# Possible values: unset (use global setting), "lf", "crlf", or "native" (platform default)
+# This does not affect Serena's own files (e.g. memories and configuration files), which always use native line endings.
+line_ending:
+
+# The language backend to use for this project.
+# If not set, the global setting from serena_config.yml is used.
+# Valid values: LSP, JetBrains
+# Note: the backend is fixed at startup. If a project with a different backend
+# is activated post-init, an error will be returned.
+language_backend:
+
+# whether to use project's .gitignore files to ignore files
+ignore_all_files_in_gitignore: true
+
+# advanced configuration option allowing to configure language server-specific options.
+# Maps the language key to the options.
+# Have a look at the docstring of the constructors of the LS implementations within solidlsp (e.g., for C# or PHP) to see which options are available.
+# No documentation on options means no options are available.
+ls_specific_settings: {}
+
+# list of additional workspace folder paths for cross-package reference support (e.g. in monorepos).
+# Paths can be absolute or relative to the project root.
+# Each folder is registered as an LSP workspace folder, enabling language servers to discover
+# symbols and references across package boundaries.
+# Currently supported for: TypeScript.
+# Example:
+#   additional_workspace_folders:
+#     - ../sibling-package
+#     - ../shared-lib
+additional_workspace_folders: []
+
+# list of additional paths to ignore in this project.
+# Same syntax as gitignore, so you can use * and **.
+# Note: global ignored_paths from serena_config.yml are also applied additively.
+ignored_paths: []
+
+# whether the project is in read-only mode
+# If set to true, all editing tools will be disabled and attempts to use them will result in an error
+# Added on 2025-04-18
+read_only: false
+
+# list of tool names to exclude.
+# This extends the existing exclusions (e.g. from the global configuration)
+# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
+excluded_tools: []
+
+# list of tools to include that would otherwise be disabled (particularly optional tools that are disabled by default).
+# This extends the existing inclusions (e.g. from the global configuration).
+# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
+included_optional_tools: []
+
+# fixed set of tools to use as the base tool set (if non-empty), replacing Serena's default set of tools.
+# This cannot be combined with non-empty excluded_tools or included_optional_tools.
+# Find the list of tools here: https://oraios.github.io/serena/01-about/035_tools.html
+fixed_tools: []
+
+# list of mode names that are to be activated by default, overriding the setting in the global configuration.
+# The full set of modes to be activated is base_modes (from global config) + default_modes + added_modes.
+# If the setting is undefined/empty, the default_modes from the global configuration (serena_config.yml) apply.
+# Otherwise, this overrides the setting from the global configuration (serena_config.yml).
+# Therefore, you can set this to [] if you do not want the default modes defined in the global config to apply
+# for this project.
+# This setting can, in turn, be overridden by CLI parameters (--mode).
+# See https://oraios.github.io/serena/02-usage/050_configuration.html#modes
+default_modes:
+
+# list of mode names to be activated additionally for this project, e.g. ["query-projects"]
+# The full set of modes to be activated is base_modes (from global config) + default_modes + added_modes.
+# See https://oraios.github.io/serena/02-usage/050_configuration.html#modes
+added_modes:
+
+# initial prompt for the project. It will always be given to the LLM upon activating the project
+# (contrary to the memories, which are loaded on demand).
+initial_prompt: ""
+
+# time budget (seconds) per tool call for the retrieval of additional symbol information
+# such as docstrings or parameter information.
+# This overrides the corresponding setting in the global configuration; see the documentation there.
+# If null or missing, use the setting from the global configuration.
+symbol_info_budget:
+
+# list of regex patterns which, when matched, mark a memory entry as read‑only.
+# Extends the list from the global configuration, merging the two lists.
+read_only_memory_patterns: []
+
+# list of regex patterns for memories to completely ignore.
+# Matching memories will not appear in list_memories or activate_project output
+# and cannot be accessed via read_memory or write_memory.
+# To access ignored memory files, use the read_file tool on the raw file path.
+# Extends the list from the global configuration, merging the two lists.
+# Example: ["_archive/.*", "_episodes/.*"]
+ignored_memory_patterns: []

package/AGENTS.md

@@ -0,0 +1,63 @@
+# Repository Guidelines
+
+## Project Structure & Module Organization
+
+This repository is in the bootstrap stage. Today, the main documents are `README.md` for scope and `PLAN.md` for the implementation checklist. The planned runtime is Node.js with TypeScript and `vscode-languageserver`.
+
+When the workspace is scaffolded, keep code under `src/`, tests under `test/`, and editor integration examples under `examples/` such as `examples/coc-settings.json`. Store parser fixtures in a dedicated test-fixture area and separate valid 6502 cases from invalid 65816 cases.
+
+The current bootstrap server entrypoint is `src/server.ts`, and the packaged CLI entrypoint is `src/cli.ts`, which compiles to `dist/src/cli.js`.
+The repository now includes `examples/coc-settings.json` as the baseline coc.nvim launch example, targeting `dist/src/cli.js --stdio` with `.git` and `package.json` root markers.
+The initial positive fixture corpus now lives under `test/fixtures/valid/` and is transcribed from upstream Merlin32 sources.
+The initial negative fixture corpus now lives under `test/fixtures/invalid/` and captures unsupported 65816-only syntax.
+Shared 6502 opcode and Merlin directive metadata now lives under `src/asm/metadata.ts`.
+Shared token-kind and line-shape metadata now lives under `src/asm/syntax.ts`.
+The current lexer implementation now lives under `src/asm/lexer.ts` and is covered by fixture-driven unit tests.
+The current expression parser now lives under `src/asm/expression.ts` and is covered by unit tests for numeric forms, modifiers, arithmetic, and indexed operands.
+The current line parser now lives under `src/asm/parser.ts` and classifies equates, instructions, directives, data lines, and malformed input.
+The current document model now lives under `src/asm/document.ts` and preserves line-by-line structure while collecting malformed-line errors.
+The current symbol collector now lives under `src/asm/symbols.ts` and indexes labels, equates, and named storage/data definitions.
+The current local-label resolver now lives under `src/asm/local-labels.ts` and resolves Merlin `]local` and `:local` labels within the nearest global-label scope.
+The current workspace indexer now lives under `src/asm/workspace.ts` and follows `asm`/`put`/`use` directives across the local fixture corpus.
+The current diagnostics pass now lives under `src/asm/diagnostics.ts` and reports duplicate symbols, unresolved references, malformed lines, and unsupported 65816-only syntax.
+The current `textDocument/documentSymbol` provider is wired through `src/server.ts` and `src/lsp/document-symbols.ts`.
+The current `workspace/symbol` provider is wired through `src/server.ts` and `src/lsp/workspace-symbols.ts` over the open-document symbol set.
+The current `textDocument/definition` and `textDocument/references` handlers are wired through `src/server.ts` and `src/lsp/symbol-navigation.ts`.
+The current `textDocument/hover` handler is wired through `src/server.ts` and `src/lsp/hover.ts`.
+The current `textDocument/completion` handler is wired through `src/server.ts` and `src/lsp/completion.ts`.
+The current `textDocument/publishDiagnostics` path is wired through `src/server.ts` and `src/lsp/diagnostics.ts`, with full-document sync on open/change so editor clients receive live parser and resolver diagnostics.
+The current packaged CLI entrypoint lives under `src/cli.ts` and is covered by a compiled stdio launch-contract integration test.
+The coc.nvim smoke test now lives under `test/smoke/` with a headless Vim runner (`run-smoke.ps1`) and a minimal vimrc that isolates the test from the user's real Vim configuration.
+
+## Build, Test, and Development Commands
+
+The repository now includes the initial Node/TypeScript workspace scaffold:
+
+- `npm install`: install project dependencies.
+- `npm run build`: compile TypeScript sources to `dist/`.
+- `npm test`: build the project and run the current test suite.
+- `npm run dev`: run the TypeScript compiler in watch mode during bootstrap work.
+
+The supported stdio launch contract is now `merls --stdio`, with `node dist/src/cli.js --stdio` as the equivalent local-development invocation.
+
+## Coding Style & Naming Conventions
+
+Use TypeScript throughout the implementation. Prefer small modules with explicit types and single-purpose exports. Use `camelCase` for variables and functions, `PascalCase` for types and classes, and kebab-case for example/config file names.
+
+Keep parser, symbol, and LSP layers separate. Name tests and fixtures after the behavior they cover, for example `parser.labels.test.ts` or `fixtures/invalid/65816-long-a.asm`.
+
+## Testing Guidelines
+
+TDD is mandatory in this repository: add or extend a failing test or fixture before implementation. Positive fixtures must cover supported Merlin-style 6502 syntax. Negative fixtures must explicitly cover unsupported 65816 syntax and expected diagnostics.
+
+Prefer focused unit tests for lexer/parser behavior and integration tests for LSP requests such as `initialize`, hover, and definition.
+
+The current bootstrap test suite already includes compiled-stdio integration checks for the packaged CLI contract, `initialize`, and diagnostics publication.
+
+## Commit & Pull Request Guidelines
+
+This workspace does not currently include accessible git history, so no local commit convention can be inferred from prior commits. Use short, imperative commit subjects such as `Add lexer token fixtures`.
+
+Task completion includes documentation maintenance. When a change affects repository behavior, structure, workflow, or contributor expectations, update both `README.md` and `AGENTS.md` in the same task.
+
+PRs should describe the user-visible behavior change, list the tests added or updated, and include sample diagnostics or editor screenshots when LSP behavior changes. Keep PRs scoped to one phase task or one coherent feature.

package/README.md

@@ -0,0 +1,137 @@
+# merls
+
+`merls` is a planned language server for **Merlin-style 6502 assembly** with **coc.nvim** as the primary editor target.
+
+## Status
+
+This repository now has an initial Node.js and TypeScript workspace scaffold, a packaged stdio CLI contract, and the MVP LSP feature set. All planned tasks in `PLAN.md` are complete, including the coc.nvim smoke test.
+
+## Goals
+
+- provide a standalone LSP server over stdio
+- work cleanly with coc.nvim through standard language-server configuration
+- support Merlin-style 6502 source structure, symbols, directives, and expressions
+- deliver useful editing features before deeper assembler integration
+
+## Scope
+
+### In scope
+
+- 6502-only Merlin-style assembly
+- parser-based diagnostics for the MVP
+- core LSP features such as:
+  - diagnostics
+  - hover
+  - completion
+  - go to definition
+  - find references
+  - document symbols
+  - workspace symbols
+
+### Out of scope
+
+- 65816 support
+- assembler-backed diagnostics in the first implementation pass
+- coc.nvim-specific plugin code for the MVP
+
+## Planned implementation
+
+- **runtime:** Node.js
+- **language:** TypeScript
+- **LSP library:** `vscode-languageserver`
+- **process model:** standalone stdio server
+- **development style:** TDD from the start
+
+## Development workflow
+
+- `npm install`: install project dependencies
+- `npm run build`: compile the TypeScript sources into `dist/`
+- `npm test`: build the project and run the current test suite
+- `npm run dev`: run the TypeScript compiler in watch mode during bootstrap work
+- `pwsh test/smoke/run-smoke.ps1`: run the headless Vim + coc.nvim smoke test (requires Vim with coc.nvim installed via vim-plug)
+
+The packaged CLI entrypoint now lives at `dist/src/cli.js`.
+
+## CLI contract
+
+The supported stdio launch contract is `merls --stdio`.
+
+For local development from this checkout, the equivalent compiled command is `node dist/src/cli.js --stdio`.
+
+## Roadmap
+
+The current plan is organized into these phases:
+
+1. bootstrap the Node/TypeScript workspace
+2. define the 6502 Merlin syntax corpus and shared metadata
+3. implement the lexer, parser, and document model
+4. implement symbols, include handling, and diagnostics
+5. add the MVP LSP features
+6. package and verify coc.nvim integration
+
+See `PLAN.md` for the full checklist.
+
+## coc.nvim target
+
+The intended integration model is a standard `languageserver` entry in `coc-settings.json` that launches `merls` over stdio.
+
+An initial example lives in `examples/coc-settings.json`. The current bootstrap flow is:
+
+1. run `npm install`
+2. run `npm run build`
+3. point coc.nvim at `dist/src/cli.js --stdio`
+
+The bundled example uses `node` plus an absolute path to the packaged CLI, passes `--stdio`, uses `package.json` and `.git` as root markers, and currently targets the `asm` filetype.
+
+The intended `languageserver` shape is:
+
+```json
+{
+  "languageserver": {
+    "merls": {
+      "command": "node",
+      "args": [
+        "C:/path/to/merls/dist/src/cli.js",
+        "--stdio"
+      ],
+      "rootPatterns": [
+        ".git",
+        "package.json"
+      ],
+      "filetypes": [
+        "asm"
+      ]
+    }
+  }
+}
+```
+
+Replace the example path with the local checkout or installed package location on your machine.
+
+## Development notes
+
+- TDD is mandatory for implementation work in this repository.
+- Shared 6502 opcode and Merlin directive metadata now lives in `src/asm/metadata.ts`.
+- Shared token-kind and line-shape metadata now lives in `src/asm/syntax.ts`.
+- The current lexer implementation now lives in `src/asm/lexer.ts` and is exercised against the shared fixture corpus.
+- The current expression parser now lives in `src/asm/expression.ts` and covers numeric forms, unary modifiers, arithmetic, and indexed operand fragments.
+- The current line parser now lives in `src/asm/parser.ts` and classifies equates, instructions, directives, data lines, and malformed input.
+- The current document model now lives in `src/asm/document.ts` and preserves line-by-line structure while collecting malformed-line errors.
+- The current symbol collector now lives in `src/asm/symbols.ts` and indexes labels, equates, and named storage/data definitions.
+- The current local-label resolver now lives in `src/asm/local-labels.ts` and resolves Merlin `]local` and `:local` labels within the nearest global-label scope.
+- The current workspace indexer now lives in `src/asm/workspace.ts` and follows `asm`/`put`/`use` directives across the local fixture corpus.
+- The current diagnostics pass now lives in `src/asm/diagnostics.ts` and reports duplicate symbols, unresolved references, malformed lines, and unsupported 65816-only syntax.
+- The current `textDocument/documentSymbol` provider is wired through `src/server.ts` and `src/lsp/document-symbols.ts`.
+- The current `workspace/symbol` provider is wired through `src/server.ts` and `src/lsp/workspace-symbols.ts` over the open-document symbol set.
+- The current `textDocument/definition` and `textDocument/references` handlers are wired through `src/server.ts` and `src/lsp/symbol-navigation.ts`.
+- The current `textDocument/hover` handler is wired through `src/server.ts` and `src/lsp/hover.ts`.
+- The current `textDocument/completion` handler is wired through `src/server.ts` and `src/lsp/completion.ts`.
+- The current `textDocument/publishDiagnostics` path is wired through `src/server.ts` and `src/lsp/diagnostics.ts`, with full-document sync on open and change so coc.nvim receives live parser and resolver errors.
+- The packaged CLI entrypoint now lives in `src/cli.ts`, compiles to `dist/src/cli.js`, and supports the explicit stdio contract `merls --stdio`.
+- The checked-in coc.nvim example now targets `dist/src/cli.js --stdio` and includes root detection for `.git` and `package.json`.
+- The positive fixture corpus now starts with transcribed Merlin32 material under `test/fixtures/valid/`.
+- Positive fixtures should cover supported 6502 Merlin-style syntax.
+- The negative fixture corpus now starts with explicit 65816-only samples under `test/fixtures/invalid/`.
+- Negative fixtures should explicitly cover unsupported 65816 syntax.
+- The current bootstrap test harness is intentionally minimal and runs against compiled output to avoid depending on editor or browser tooling.
+- The current integration coverage reaches through stdio `initialize`, the packaged CLI contract, completion, hover, symbol navigation, and diagnostics publication.

package/dist/src/asm/diagnostics.js

@@ -0,0 +1,202 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.collectWorkspaceDiagnostics = collectWorkspaceDiagnostics;
+const local_labels_1 = require("./local-labels");
+const metadata_1 = require("./metadata");
+function collectWorkspaceDiagnostics(documents) {
+    const diagnostics = [];
+    const globalSymbols = new Set();
+    const symbolRecords = [];
+    for (const entry of documents) {
+        for (const symbol of collectGlobalDefinitions(entry.document, entry.filePath)) {
+            symbolRecords.push(symbol);
+            globalSymbols.add(symbol.name);
+        }
+    }
+    diagnostics.push(...collectDuplicateSymbolDiagnostics(symbolRecords));
+    for (const entry of documents) {
+        diagnostics.push(...collectMalformedDiagnostics(entry.filePath, entry.document), ...collectUnsupportedDiagnostics(entry.filePath, entry.document), ...collectUnresolvedDiagnostics(entry.filePath, entry.document, globalSymbols));
+    }
+    return diagnostics;
+}
+function collectDuplicateSymbolDiagnostics(symbolRecords) {
+    const firstDefinitionByName = new Map();
+    const diagnostics = [];
+    for (const symbol of symbolRecords) {
+        const firstDefinition = firstDefinitionByName.get(symbol.name);
+        if (firstDefinition === undefined) {
+            firstDefinitionByName.set(symbol.name, symbol);
+            continue;
+        }
+        diagnostics.push({
+            filePath: symbol.filePath,
+            line: symbol.line,
+            code: "duplicate-symbol",
+            message: `Duplicate symbol ${symbol.name}; first defined at line ${firstDefinition.line}`
+        });
+    }
+    return diagnostics;
+}
+function collectMalformedDiagnostics(filePath, document) {
+    return document.errors.map((error) => ({
+        filePath,
+        line: error.line,
+        code: "malformed-line",
+        message: error.message
+    }));
+}
+function collectUnsupportedDiagnostics(filePath, document) {
+    const diagnostics = [];
+    for (const line of document.lines) {
+        const unsupportedDirective = getUnsupportedDirective(line.node);
+        if (unsupportedDirective !== null) {
+            diagnostics.push({
+                filePath,
+                line: line.line,
+                code: "unsupported-65816",
+                message: `Unsupported 65816 directive: ${unsupportedDirective}`
+            });
+        }
+        const unsupportedText = getUnsupportedTextPattern(line.node.text);
+        if (unsupportedText !== null) {
+            diagnostics.push({
+                filePath,
+                line: line.line,
+                code: "unsupported-65816",
+                message: `Unsupported 65816 syntax: ${unsupportedText}`
+            });
+        }
+    }
+    return diagnostics;
+}
+function collectUnresolvedDiagnostics(filePath, document, globalSymbols) {
+    const diagnostics = [];
+    const localScope = (0, local_labels_1.resolveLocalLabels)(document);
+    for (const line of document.lines) {
+        for (const reference of findExpressionReferences(line.node)) {
+            if (reference.startsWith("]") || reference.startsWith(":")) {
+                const localKey = `${reference}@${line.line}`;
+                const localDefinitionKey = [...localScope.definitions.keys()].find((key) => key.startsWith(`${reference}@`));
+                if (!localScope.references.has(localKey) && localDefinitionKey === undefined) {
+                    diagnostics.push({
+                        filePath,
+                        line: line.line,
+                        code: "unresolved-reference",
+                        message: `Unresolved local reference ${reference}`
+                    });
+                }
+                continue;
+            }
+            if (!globalSymbols.has(reference)) {
+                diagnostics.push({
+                    filePath,
+                    line: line.line,
+                    code: "unresolved-reference",
+                    message: `Unresolved reference ${reference}`
+                });
+            }
+        }
+    }
+    return diagnostics;
+}
+function collectGlobalDefinitions(document, filePath) {
+    const symbols = [];
+    for (const line of document.lines) {
+        const name = getGlobalDefinitionName(line.node);
+        if (name === null) {
+            continue;
+        }
+        symbols.push({
+            name,
+            line: line.line,
+            filePath
+        });
+    }
+    return symbols;
+}
+function getGlobalDefinitionName(node) {
+    if (node.shape === "equate" && !isLocalLabel(node.label)) {
+        return node.label;
+    }
+    if (node.shape === "labelOnly" && !isLocalLabel(node.label)) {
+        return node.label;
+    }
+    if (node.shape === "instruction" && node.label !== null && !isLocalLabel(node.label)) {
+        return node.label;
+    }
+    if (node.shape === "directive" && node.label !== null && !isLocalLabel(node.label)) {
+        return node.label;
+    }
+    if (node.shape === "data" && node.label !== null && !isLocalLabel(node.label)) {
+        return node.label;
+    }
+    return null;
+}
+function findExpressionReferences(node) {
+    if (node.shape === "instruction" && node.operand !== null) {
+        return findReferencesInOperand(node.operand);
+    }
+    if (node.shape === "directive" && node.operand !== null) {
+        const directive = metadata_1.directiveTable.get(node.directive);
+        if (directive?.kind === "include" || directive?.kind === "build") {
+            if (node.directive === "typ") {
+                const knownAliases = new Set([
+                    "txt", "bin", "sys", "bas", "var", "rel",
+                    "lib", "s16", "rtl", "exe", "pif", "tif",
+                    "nda", "cda", "tol", "dvr", "ldf", "fst"
+                ]);
+                return findReferencesInExpression(node.operand).filter((ref) => !knownAliases.has(ref.toLowerCase()));
+            }
+            return [];
+        }
+        return findReferencesInExpression(node.operand);
+    }
+    if (node.shape === "equate") {
+        return findReferencesInExpression(node.expression);
+    }
+    return [];
+}
+function findReferencesInOperand(operand) {
+    return findReferencesInExpression(operand.expression);
+}
+function findReferencesInExpression(expression) {
+    switch (expression.kind) {
+        case "identifier":
+            return [expression.value];
+        case "modifier":
+            return findReferencesInExpression(expression.expression);
+        case "binary":
+            return [
+                ...findReferencesInExpression(expression.left),
+                ...findReferencesInExpression(expression.right)
+            ];
+        default:
+            return [];
+    }
+}
+function getUnsupportedDirective(node) {
+    if (node.shape !== "directive") {
+        return null;
+    }
+    const directive = metadata_1.directiveTable.get(node.directive);
+    if (directive?.supported === false) {
+        return node.directive;
+    }
+    return null;
+}
+function getUnsupportedTextPattern(text) {
+    const trimmed = text.trim().toLowerCase();
+    if (/^(pea|mvn|mvp)\b/.test(trimmed)) {
+        return trimmed.split(/\s+/, 1)[0] ?? trimmed;
+    }
+    if (trimmed.includes("^")) {
+        return "^";
+    }
+    if (trimmed.includes("|")) {
+        return "|";
+    }
+    return null;
+}
+function isLocalLabel(name) {
+    return name.startsWith("]") || name.startsWith(":");
+}

package/dist/src/asm/document.js

@@ -0,0 +1,26 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.parseDocument = parseDocument;
+const parser_1 = require("./parser");
+function parseDocument(source) {
+    const parsedLines = (0, parser_1.parseSourceLines)(source);
+    const lines = [];
+    const errors = [];
+    parsedLines.forEach((node, line) => {
+        lines.push({
+            line,
+            node
+        });
+        if (node.shape === "malformed") {
+            errors.push({
+                line,
+                text: node.text,
+                message: node.message
+            });
+        }
+    });
+    return {
+        lines,
+        errors
+    };
+}