@pmelab/gtd 6.9.1 → 6.10.0

package/README.md

@@ -144,14 +144,16 @@ importantly: gitignore everything your scripts write.
 
 Editor integration: `gtd lsp` starts an LSP server over stdio for `.gtd/`
 steering files — symbols and check/uncheck actions over a `review`-mode file's
-chunks, symbols over a `qa`-mode file's open questions, diagnostics for both
-(live as you edit), and a `gtd.openSteeringFile` command that jumps to the
-current state's steering file. Config-driven via each state's `file:`/`mode:`
-(see [CLI reference](docs/cli.md#gtd-lsp)) — falls back to basename dispatch
-(`TODO.md`/`REVIEW.md`) with no config in sight. Those two formats are gtd's
-built-in steering-file MODES — validators, not formatters: a mode's `format:`
-and `validate:` are shell commands a workflow (or a project's `.gtdrc`) declares
-for itself, so you bring your own formatter and your own checkers (see
+chunks, go-to-definition from a `review`-mode hunk line into the file it points
+at (at its `#line`), symbols over a `qa`-mode file's open questions, diagnostics
+for both (live as you edit), and a `gtd.openSteeringFile` command that jumps to
+the current state's steering file. Config-driven via each state's
+`file:`/`mode:` (see [CLI reference](docs/cli.md#gtd-lsp)) — falls back to
+basename dispatch (`TODO.md`/`REVIEW.md`) with no config in sight. Those two
+formats are gtd's built-in steering-file MODES — validators, not formatters: a
+mode's `format:` and `validate:` are shell commands a workflow (or a project's
+`.gtdrc`) declares for itself, so you bring your own formatter and your own
+checkers (see
 [Configuration](docs/configuration.md#modes--pluggable-steering-file-modes)).
 Both halves are enforced by `gtd validate` and the `gtd step` gate.
 

package/dist/gtd.bundle.mjs

@@ -203725,11 +203725,22 @@ const parseReviewDoc = (content) => {
 /**
 * LSP server for `.gtd/` steering files — document symbols for a `qa`-mode
 * file's open questions and a `review`-mode file's review chunks/hunks, code
-* actions to check/uncheck a hunk or a whole chunk, and diagnostics publishing
-* the same parsers' `errors` the `gtd validate` CLI command reports (see
-* `src/OpenQuestions.ts` / `src/ReviewDoc.ts`'s module docs — those parsers
-* are each format's single source of truth, shared by this server and the
-* command).
+* actions to check/uncheck a hunk or a whole chunk, go-to-definition from a
+* `review`-mode hunk line into the file it points at, and diagnostics
+* publishing the same parsers' `errors` the `gtd validate` CLI command reports
+* (see `src/OpenQuestions.ts` / `src/ReviewDoc.ts`'s module docs — those
+* parsers are each format's single source of truth, shared by this server and
+* the command).
+*
+* GO-TO-DEFINITION (`textDocument/definition`, `review`-mode only): the cursor
+* on a hunk pointer line (`- [ ] ./src/foo.ts#42`) jumps to `./src/foo.ts` at
+* line 42 (`hunkDefinitionLocation`). The `./`-relative path resolves against
+* the git toplevel of the file's own directory (`tryGitTopLevel`), falling
+* back to the workspace root — never the document's own `.gtd/` directory — so
+* a repo-root-relative diff path lands correctly even with no workspace folder
+* open; no target is returned when neither anchor resolves. The `#line` is
+* 1-based (a bare `./path` lands at the top of the file); the target file is
+* not stat-ed, so a stale pointer still jumps and the editor reports the miss.
 *
 * CONFIG-DRIVEN (see `docs/design/state-file-association.md` §3): the server
 * locates the active gtd config the SAME way the CLI does (`ConfigService`'s
@@ -203941,6 +203952,40 @@ const reviewCodeActions = (uri, content, range) => {
 	});
 	return actions;
 };
+/**
+* Go-to-definition target for a `.gtd/REVIEW.md` hunk line: the file the hunk
+* pointer at `line` (0-based, `params.position.line`) points into. `root` is
+* the repo the `./`-relative hunk paths were authored against (the git
+* toplevel of REVIEW.md's directory — see `resolveDefinitionRoot`). Returns
+* `undefined` when `line` isn't a parsed hunk pointer (a heading, prose, or a
+* malformed line has no `sourceLine`), so the provider yields no target there.
+*
+* The `#line` in a pointer is 1-based (git/human line numbers); LSP positions
+* are 0-based, so it maps to `line - 1`. A bare `./path` with no `#line` lands
+* at the top of the file (line 0). The range is collapsed (a cursor, not a
+* selection) and the target file is NOT stat-ed — a stale/deleted/`../`-escaping
+* path still returns a Location and the editor reports the miss itself. Pure —
+* no git, no protocol, unit-testable directly.
+*/
+const hunkDefinitionLocation = (content, line, root) => {
+	const { changesets } = parseReviewDoc(content);
+	const hunk = changesets.flatMap((chunk) => chunk.files).find((file) => file.sourceLine === line);
+	if (!hunk) return void 0;
+	const targetLine = hunk.line !== void 0 ? hunk.line - 1 : 0;
+	return {
+		uri: pathToFileURL(resolve(root, hunk.path)).toString(),
+		range: {
+			start: {
+				line: targetLine,
+				character: 0
+			},
+			end: {
+				line: targetLine,
+				character: 0
+			}
+		}
+	};
+};
 /** The basename dispatch this server has always had — the fallback for any path the active workflow's `file:` map doesn't cover (or when no config resolves at all). */
 const basenameFallbackMode = (name) => {
 	if (name === "TODO.md") return "qa";
@@ -204057,6 +204102,21 @@ const loadModeMap = async (root, onWarn) => {
 	}
 };
 /**
+* The git working-tree root of `dir` (`git rev-parse --show-toplevel`), or
+* `undefined` when `dir` is outside any repository. This is the anchor a
+* hunk's `./`-relative path resolves against — the repo the review diff's
+* paths were authored against (`GitService.topLevel()`, the same op the CLI
+* uses). Any failure resolves to `undefined` so the caller can fall back to
+* the workspace root.
+*/
+const tryGitTopLevel = async (dir) => {
+	try {
+		return await runPromise(GitService.pipe(flatMap$4((git) => git.topLevel()), provide$1(gitLayerForRoot(dir))));
+	} catch {
+		return;
+	}
+};
+/**
 * Resolve the CURRENT state/actor and its `file:` (rendered), exactly like
 * the CLI (`resolveRest`/`computeProcessRun`/`buildTemplateContext` — the
 * same `src/Edge.ts` helpers `gtd status`/`gtd next` call), scoped to `root`.
@@ -204098,6 +204158,7 @@ const startLspServer = () => gen(function* () {
 			textDocumentSync: import_main.TextDocumentSyncKind.Incremental,
 			documentSymbolProvider: true,
 			codeActionProvider: true,
+			definitionProvider: true,
 			executeCommandProvider: { commands: [OPEN_STEERING_FILE_COMMAND] }
 		} };
 	});
@@ -204118,6 +204179,15 @@ const startLspServer = () => gen(function* () {
 		if (modeForDocument(document.uri, map) !== "review") return [];
 		return reviewCodeActions(document.uri, document.getText(), params.range);
 	});
+	connection.onDefinition(async (params) => {
+		const document = documents.get(params.textDocument.uri);
+		if (!document) return [];
+		const map = await loadModeMap(rootFor(document.uri), warn);
+		if (modeForDocument(document.uri, map) !== "review") return [];
+		const root = await tryGitTopLevel(dirname(fileURLToPath(document.uri))) ?? workspaceRoot;
+		if (root === void 0) return [];
+		return hunkDefinitionLocation(document.getText(), params.position.line, root) ?? [];
+	});
 	connection.onExecuteCommand(async (params) => {
 		if (params.command !== OPEN_STEERING_FILE_COMMAND) return null;
 		const root = workspaceRoot ?? process.cwd();

package/docs/cli.md

@@ -391,9 +391,12 @@ are rejected).
 
 Starts an LSP server over stdio for `.gtd/` steering files — document symbols
 for a `qa`-mode file's open questions and a `review`-mode file's review
-chunks/hunks, code actions to check/uncheck a hunk or a whole chunk, and
-diagnostics publishing the same parser findings `gtd validate` reports (see
-`src/OpenQuestions.ts` / `src/ReviewDoc.ts` and
+chunks/hunks, code actions to check/uncheck a hunk or a whole chunk,
+go-to-definition (`textDocument/definition`) from a `review`-mode hunk pointer
+line into the file it points at (at its 1-based `#line`, or the top of the file
+for a bare `./path`; the `./`-relative path resolves against the repo's git
+toplevel), and diagnostics publishing the same parser findings `gtd validate`
+reports (see `src/OpenQuestions.ts` / `src/ReviewDoc.ts` and
 [STATES.md §12](../STATES.md#12-steering-file-validation-gtd-validate)).
 
 **Config-driven** (see

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pmelab/gtd",
-  "version": "6.9.1",
+  "version": "6.10.0",
   "private": false,
   "description": "Git-aware CLI that emits the next prompt for an autonomous coding agent based on the current repository state",
   "bin": {