The initially written 27th document contained many object and structure descriptions, making it difficult to trace how the input actually flows
Then I readjusted the document direction based on PR feedback
Modified it to explicitly state, for each expanded input line # <relative path>, which file and line go into the AST Parser
Using actual line ranges such as E020‑E034 in player.gd, I organized the flow where that portion of the text leads to Retriever search and LLM judgment
File paths are for tracing only; the Retriever search receives only the chunkText of the code/text fragment, which I fixed as a rule again
docs_chunks, api_mapping, label_prototypes are searched in the same way without special treatment, and the search candidates are re‑validated by the LLM
Today’s work aimed to lock down, in documentation, how input and output connect at each point before actual implementation, so that the AI does not arbitrarily change ranges or drift into abstract structural explanations
Implemented a Source Flow Debugger web tool to verify the documented flow
Ran it locally at http://127.0.0.1:8010/ to directly inspect Godot project input
Split the project input expanded by # <relative path> back into file units; .gd files become AST‑type chunks, while .godot and .tscn become direct chunks
Confirmed that a small Godot project is broken down into 5 files, 14 chunks, AST 9, Direct 5
Excluded documentation files such as README.md from source‑analysis mode, and displayed the exclusion fact and reason on screen
Added debugging UI per chunk
Placed docs_chunks search, api_mapping search, label_prototypes search, Validate JSONL buttons under each chunk
Instead of a global table checkbox, the search is performed for each table right below the current chunk
Retriever input shows only { "chunkText": "..." } after removing file path, line number, and prompt
Qwen verification is used only in the prompt + chunkText + retrieved JSONL step
Fixed issues discovered while actually using the web debugger
Removed the problem where sample Godot code was automatically inserted on page load
Even when the same file/folder is re‑uploaded, cleared the upload input value on click so the browser change event fires again
Added cache-control: no-store to static file responses to prevent old JS from persisting during development
Guarded client.end() calls so that cleanup works safely even if client creation/connection fails in the PostgreSQL search path
Recorded the implementation results in a separate document with screenshots
As of now, I consider the chunk‑level decomposition reasonably successful and set the next focus on how to actually perform DB searches
Need to verify, using only chunkText, which JSONL candidates return from docs_chunks, api_mapping, label_prototypes
Need to determine in the Qwen verification step how to judge whether the retrieved JSONL is relevant to the current chunk and whether to discard it
Before adding DB search, I used GPT to create demo Godot chunks and related/unrelated JSONL to experiment with matching prompts
Initially I asked “Does this JSONL contain content that corresponds to the source code? Answer only yes/no,” and both related and unrelated JSONL returned “yes,” which was a problem
Then I restricted it so that one of source_api, source_pattern, match_terms, required_when_seen_in_code, before_code must directly match the actual SOURCE_CODE string/API call for a “yes” answer
By avoiding broad word similarity or LLM’s prior Godot knowledge and looking only at the string evidence written in the JSONL, related JSONL returned “yes” and unrelated JSONL returned “no” as expected
This experiment gave the criterion that the Qwen verification after DB search should first decide whether the retrieved JSONL contains a string evidence that directly matches the current chunk, rather than relying on “plausible semantic similarity”
Tomorrow I will create several demo sets of related/unrelated JSONL for Godot chunks and repeatedly test how Qwen derives “yes”/“no” based on the evidence
