Dockerfile with trailing whitespace and no final newline reported as parse_partial

[maksymshiftlive]

Summary

A Dockerfile whose final instruction ends with trailing whitespace and no terminating newline is
reported as parse_partial, with the error range pointing at that last line. The instruction itself is
valid and Docker builds it fine.

Adding either a newline or removing the trailing space makes the file parse cleanly, so the trigger is
specifically <instruction><space><EOF> with no line terminator.

Minimal reproduction

Two files in an otherwise empty directory (plus any source file so the pipeline has something to index):

Dockerfile — note the single trailing space after ], and no trailing newline:

FROM scratch
ENTRYPOINT ["a"]·

Generate it exactly (· above is a literal space):

printf 'FROM scratch\nENTRYPOINT ["a"] ' > Dockerfile
printf 'public class A { public int B() => 1; }\n' > A.cs

Then:

codebase-memory-mcp cli index_repository --repo_path=. --mode=fast --name=repro

Expected

parse_partial count: 0

Actual

parse_partial count: 1
  FLAGGED: Dockerfile -> 2-2

Controls that isolate the trigger

Same two-line Dockerfile, only the final bytes differ. Each indexed as its own subdirectory in one run:

Final bytes of file	Last byte	Result
ENTRYPOINT ["a"] (space, no newline)	0x20	flagged 2-2
ENTRYPOINT ["a"] \n (space, then newline)	0x0a	clean
ENTRYPOINT ["a"] (no space, no newline)	0x5d	clean

So neither "missing trailing newline" nor "trailing whitespace" alone is enough — it takes both together.

The same pattern shows up in real-world files: in a repo of mine, the two Dockerfiles ending in ] + EOF
are both flagged at their final line, while a third Dockerfile that also lacks a trailing newline but has no
trailing space is not flagged. The originally-flagged files use CRLF line endings and the synthetic repro
above uses LF, so this appears independent of line-ending style.

Environment

• codebase-memory-mcp 0.10.8 (Windows x64 build)
• Windows 11 Pro 10.0.22631
• Reproduced via both the MCP index_repository tool and the cli index_repository one-shot path

Notes

• Likely upstream in the tree-sitter Dockerfile grammar's handling of a final unterminated line rather than
  in this project's own code — feel free to reclassify or forward.
• Low severity: the affected node is an ENTRYPOINT line, so little of graph value is lost. Filing it mainly
  because it produces parse_partial noise that makes the coverage report look worse than it is, and because
  trailing whitespace at EOF is common in checked-in Dockerfiles.