thincoder 0.12.35 → 0.12.36

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "thincoder",
-  "version": "0.12.35",
+  "version": "0.12.36",
   "description": "Thin coding agent - zero dependencies, no build step, Node.js native. Sharp code, zero bloat.",
   "keywords": [
     "ai",

package/src/advisor/messages.mjs

@@ -185,13 +185,27 @@ export function buildAdvisorUserMessage(agent, prior, reviewType, designToken =
       } catch { /* file doesn't exist — skip */ }
     }
 
+    // Document map (docs/design/README.md) — inject when the discovered
+    // project root has one: the reviewer checks document ownership against it
+    // (a change for an existing section must amend that section's document,
+    // not spawn a new file for it). Absent map → skip (nothing to check against).
+    try {
+      const mapPath = resolve(guideRoot ?? agent.cwd, "docs", "design", "README.md")
+      if (existsSync(mapPath)) {
+        parts.push("## Document Map")
+        parts.push("The document map below registers which document files exist per section. Use it for the Document ownership criterion: a change for an existing section must amend that section's document, not create a new file.")
+        parts.push(readFileSync(mapPath, "utf8"))
+        parts.push("")
+      }
+    } catch { /* file doesn't exist or is unreadable — skip */ }
+
     parts.push("## Instructions")
     if (docList.length > 0) {
       parts.push("1. Read every document in the Documents to Review list in full — review ONLY those files. Read METHODOLOGY.md to understand the project's standards.")
     } else {
       parts.push("1. Read the design document fully. Read METHODOLOGY.md to understand the project's standards.")
     }
-    parts.push("2. Review against: completeness (all requirements covered?), feasibility (can this be built?), clarity (specific enough?), acceptance criteria (verifiable?), scope (appropriate?).")
+    parts.push("2. Review against: completeness (all requirements covered?), feasibility (can this be built?), methodology compliance (does it follow the project's METHODOLOGY.md?), clarity (specific enough?), acceptance criteria (verifiable?), scope (appropriate?).")
     parts.push("3. If the ## Project Guide (AGENTS.md) section above is present, also check requirement fit: does the design match what the requirements documents it points to actually ask for?")
     parts.push("4. Do NOT run git diff or look for code changes — there are none at this stage.")
     parts.push("5. If you find issues, produce your review table with the format: | # | Category | Severity | Issue | Suggestion |. If the design passes, no table is needed.")

package/src/advisor.mjs

@@ -72,14 +72,11 @@ const ADVISOR_ROUND1 = loadPrompt("advisor-round1.md", "advisor-round1.md")
 // buildAdvisorSystemPrompt when _advisorRound > 0.
 const ADVISOR_ROUND2 = loadPrompt("advisor-round2.md", "advisor-round2.md")
 const ADVISOR_ROUND3 = loadPrompt("advisor-round3.md", "advisor-round3.md")
-// Fallback when advisor-design.md is missing — keep in sync with the real
-// file (table format + workflow steps).
-const ADVISOR_DESIGN_FALLBACK = `You are an independent design reviewer for an engineering-mode project. Review the design document in the changes below. Evaluate: completeness, feasibility, clarity, scope, acceptance criteria. Read METHODOLOGY.md if provided. Produce a review table with | # | Category | Severity | Issue | Suggestion | format.`
-let ADVISOR_DESIGN = ""
-// Design review is OPTIONAL (engineering mode only) — silent fallback to the
-// in-code constant is intentional, unlike the mandatory round prompts which
-// must exist for every review (loadPrompt throws a descriptive error there).
-try { ADVISOR_DESIGN = readFileSync(join(__dirname, "prompts", "advisor-design.md"), "utf8") } catch { /* fallback below */ }
+// Design-review prompt — hard-loaded like the round prompts (decision
+// 2026-08-21): a missing file means a broken installation, and silently
+// degrading to a lesser in-code prompt would quietly strip the approval-signal
+// and citation rules, disabling design approval entirely. loadPrompt throws.
+const ADVISOR_DESIGN = loadPrompt("advisor-design.md", "advisor-design.md")
 
 // ────────────────────────────────────────
 // System prompt building
@@ -109,7 +106,7 @@ export function buildAdvisorSystemPrompt(agent, prior, reviewType) {
   // approval token); rounds 2+ converge like code reviews (verify agent fix claims).
   if (reviewType === "design") {
     if (!hasPrior) {
-      return ADVISOR_DESIGN || ADVISOR_DESIGN_FALLBACK
+      return ADVISOR_DESIGN
     }
     const round = (agent._advisorRound || 0) + 1
     if (round === 2) return ADVISOR_ROUND2

package/src/prompts/advisor-design.md

@@ -12,6 +12,7 @@ Evaluate the design against these dimensions:
 4. **Clarity** — Is the design specific enough to implement? Are the affected files identified?
 5. **Acceptance criteria** — Are they verifiable? Do they cover normal paths, edge cases, and error conditions?
 6. **Scope** — Is the scope appropriate? Are there opportunities to simplify? Is there scope creep?
+7. **Document ownership** — Does the change amend the design document that already owns its topic (per the document map in `docs/design/README.md`), or does it fragment by creating a new file for an existing section? Does the wording duplicate or contradict existing documents?
 
 ## Output Format
 
@@ -27,6 +28,14 @@ Severity levels:
 - 🟡 Advisory — design could be improved; NOT a blocker for approval
 - 🔵 Note — optional observation; NOT a blocker
 
+Document ownership severity:
+- Wording that CONTRADICTS an existing document (same mechanism described differently in two places) → 🔴
+- Creating a new file for an existing section, or duplicating a description that already exists elsewhere → 🟡
+
+## Citation Discipline
+
+When you cite design-document text, use the exact `file:line` format (e.g. `docs/design/AGENT-LOOP.md:180`) — host-side verification will check the citation against the current disk state. If you have not read/verified the cited content, mark it `unverified` instead of presenting it as fact.
+
 ## Approval Signal
 
 The user message contains an exact token in an `## Approval Signal` section (format `[DESIGN-TOKEN:...]`).

package/src/prompts/system.md

@@ -8,6 +8,7 @@ Programming is collaborative labor between you and the human. The human decides
 
 **How you work — before you write any code:**
 - **Read design docs first.** Use `doc_search` to find relevant design docs, AGENTS.md, and architecture decisions. Code without design context is guesswork. If docs conflict with code, docs are right. If the user's instruction conflicts with the docs, tell the user first — discuss, update the docs, then code.
+- **Document ownership — find the doc that owns the topic before writing.** Before writing to `docs/design/`, check the `docs/design/README.md` document map (no map → check AGENTS.md and the docs directory) to locate the document that owns the topic — if it exists, update it; never create a new file for an existing section. Create a new file only when no section owns the topic, and register it in the map. Describe each mechanism in detail in exactly ONE place (the authoritative source); other documents reference it, never copy it.
 - **Check existing code.** Search for existing functions, helpers, patterns before writing new ones. Duplicates are technical debt.
 - **Understand intent.** Ask why this change is needed — the "why" reveals scope the literal request hides.
 - **Confirm understanding.** State what you believe the user asked for and what you plan to deliver, including the most important acceptance criteria. Wait for confirmation. No task is too small — a wrong assumption always costs more than the round-trip. Once confirmed, deliver exactly what was agreed — no simplifying, no substituting, no taking shortcuts after the fact. Simplifying a confirmed requirement frustrates the user and wastes time; they will just tell you to do it right anyway.