jared/cc-os

Watch

Fork 0

Cap or split hub notes so one note cannot crowd out query results #1570

New issue

Closed

opened 2026-11-05 14:19:09 +00:00 by jared · 3 comments

jared commented

2026-11-05 14:19:09 +00:00

Owner

Problem

One long note can crowd other notes out of query results. reference/n8n-api-data-tables-403.md yields 91 nodes, 5.8% of the vault graph (1562 nodes).
Evidence: /tmp/claude-1000/-home-jared-Documents-SecondBrain/b10276a0-3582-48b5-b0fe-f13795bdcc75/scratchpad/vault-graph-weak-retrieval-evidence.md and /tmp/claude-1000/-home-jared-Documents-SecondBrain/8a73b51f-d8a3-4dfc-9de7-e72ea77eacac/scratchpad/graph-test-results.md (copied below; do not depend on the paths).

Observed

The note has 5,535 words and 58 headings. It exceeds the 20,000-character cap (llm.py:31, 700), so graphify slices it and sends several calls. The log shows "slice ... truncated at depth 0; splitting".
Top 5 notes hold 195 of 1562 nodes (12.5%): n8n-api-data-tables-403 91; herdr-setup 33; rubyllm-main-branch 25; pest-control per-group 23; ollama-systemone 23. Top 10 hold 18.5%.
Question 1 (n8n 429 backoff): 145 nodes matched, 51 shown, about 40 are noise from this note.
A path from email-triage to Graceful Rate Limits went through "n8n API Data Tables 403" (2 hops), a hub artifact.
God nodes by degree: n8n Data Tables API 49; Pest Control After-Hours SMS Lead Capture 37; RubyLLM Main Branch 24; Graphify 21; Morphing Fat Models into Roles 20.
The note's node count is fair: about 1.5 nodes per numbered gotcha. The harm is crowding, not extraction quality.

Reproduce

cd /home/jared/Documents/SecondBrain && graphify query "How should an n8n workflow back off and retry on a 429 rate limit?" --budget 2000

Approach

Choose one of two designs and state the reason. Either cap the nodes per source note in query output, or split hub notes into focused notes of one topic each. The split also helps notes that now get one node. Test with question 1 and the 12 vault questions.

Required work: none beyond the acceptance criteria.

Orchestrator work: apply the split or the cap, rebuild the vault graph, and re-run the 12 vault questions.

Acceptance criteria

Given question 1, when the query runs after the change, then at most a stated limit of its nodes come from n8n-api-data-tables-403.md (or from its split notes taken together).
Given the 12 vault questions, when they run after the change, then no question that passed before fails.

Non-goals

Facts in output (see the summaries ticket).

Origin

Trigger: vault graph test of 12 questions, 2026-11-04.
Improvised this session: none.
Chain: question 1 output is mostly noise ← one note yields 91 nodes ← slicing of a 5,535-word note, no per-note cap in query output ← UPSTREAM-TOOL (graphify 0.9.102, llm.py:31/700, serve.py).
Root candidate: none found; searched backlog terms for this ticket (VERDICT: CREATE)
Where: reference/n8n-api-data-tables-403.md; graphify serve.py output ordering
Session: b10276a0-3582-48b5-b0fe-f13795bdcc75
Transcript: /home/jared/.claude/projects/-home-jared-Documents-SecondBrain/b10276a0-3582-48b5-b0fe-f13795bdcc75.jsonl
Parent: #1540.

## Problem One long note can crowd other notes out of query results. `reference/n8n-api-data-tables-403.md` yields 91 nodes, 5.8% of the vault graph (1562 nodes). Evidence: /tmp/claude-1000/-home-jared-Documents-SecondBrain/b10276a0-3582-48b5-b0fe-f13795bdcc75/scratchpad/vault-graph-weak-retrieval-evidence.md and /tmp/claude-1000/-home-jared-Documents-SecondBrain/8a73b51f-d8a3-4dfc-9de7-e72ea77eacac/scratchpad/graph-test-results.md (copied below; do not depend on the paths). ## Observed - The note has 5,535 words and 58 headings. It exceeds the 20,000-character cap (`llm.py:31`, `700`), so graphify slices it and sends several calls. The log shows "slice ... truncated at depth 0; splitting". - Top 5 notes hold 195 of 1562 nodes (12.5%): n8n-api-data-tables-403 91; herdr-setup 33; rubyllm-main-branch 25; pest-control per-group 23; ollama-systemone 23. Top 10 hold 18.5%. - Question 1 (n8n 429 backoff): 145 nodes matched, 51 shown, about 40 are noise from this note. - A path from email-triage to Graceful Rate Limits went through "n8n API Data Tables 403" (2 hops), a hub artifact. - God nodes by degree: n8n Data Tables API 49; Pest Control After-Hours SMS Lead Capture 37; RubyLLM Main Branch 24; Graphify 21; Morphing Fat Models into Roles 20. - The note's node count is fair: about 1.5 nodes per numbered gotcha. The harm is crowding, not extraction quality. ## Reproduce ``` cd /home/jared/Documents/SecondBrain && graphify query "How should an n8n workflow back off and retry on a 429 rate limit?" --budget 2000 ``` ## Approach Choose one of two designs and state the reason. Either cap the nodes per source note in query output, or split hub notes into focused notes of one topic each. The split also helps notes that now get one node. Test with question 1 and the 12 vault questions. Required work: none beyond the acceptance criteria. Orchestrator work: apply the split or the cap, rebuild the vault graph, and re-run the 12 vault questions. ## Acceptance criteria 1. Given question 1, when the query runs after the change, then at most a stated limit of its nodes come from `n8n-api-data-tables-403.md` (or from its split notes taken together). 2. Given the 12 vault questions, when they run after the change, then no question that passed before fails. ## Non-goals Facts in output (see the summaries ticket). ## Origin - Trigger: vault graph test of 12 questions, 2026-11-04. - Improvised this session: none. - Chain: question 1 output is mostly noise ← one note yields 91 nodes ← slicing of a 5,535-word note, no per-note cap in query output ← UPSTREAM-TOOL (graphify 0.9.102, llm.py:31/700, serve.py). - Root candidate: none found; searched backlog terms for this ticket (VERDICT: CREATE) - Where: reference/n8n-api-data-tables-403.md; graphify serve.py output ordering - Session: b10276a0-3582-48b5-b0fe-f13795bdcc75 - Transcript: /home/jared/.claude/projects/-home-jared-Documents-SecondBrain/b10276a0-3582-48b5-b0fe-f13795bdcc75.jsonl - Parent: #1540.

jared added the

plugin/os-vault

filed-by/user

category/code-change

labels

2026-11-05 14:19:09 +00:00

jared referenced this issue

2026-11-05 15:56:57 +00:00

Revisit the vault-note process for retrieval and context cost #1574

jared commented

2026-11-05 15:59:25 +00:00

Author

Owner

The note-split half of this ticket moves to #1574 (revisit the vault-note process). This ticket keeps the query cap.

jared referenced this issue

2026-11-05 20:28:26 +00:00

Finish the vault graph rebuild after the graphify update #1540

jared referenced this issue

2026-11-06 14:30:06 +00:00

Add note summaries to graphify query output #1571

jared commented

2026-11-06 14:30:06 +00:00

Author

Owner

/os-backlog:ticket-decompose routed this to /os-sdlc:ticket-takedown because the owner is a new object.

One change: a per-source cap in query output. Owner: the same os-vault query wrapper proposed on #1571. Graphify has no per-file limit (serve.py:1168-1245). Measured: reference/n8n-api-data-tables-403.md holds 92 of 2524 nodes. The '40 noise nodes in Q1' claim is unverified; measure first, after #1568. A hub can be the right answer, so add a check that such a query still returns it.

/os-backlog:ticket-decompose routed this to `/os-sdlc:ticket-takedown` because the owner is a new object. One change: a per-source cap in query output. Owner: the same os-vault query wrapper proposed on #1571. Graphify has no per-file limit (`serve.py:1168-1245`). Measured: `reference/n8n-api-data-tables-403.md` holds 92 of 2524 nodes. The '40 noise nodes in Q1' claim is unverified; measure first, after #1568. A hub can be the right answer, so add a check that such a query still returns it.

jared referenced this issue

2026-11-06 20:09:51 +00:00

Run pytest targets in the diff-test gate #1625

jared referenced this issue

2026-11-06 20:27:05 +00:00

Run pytest targets in the diff-test gate #1625

jared commented

2026-11-06 21:30:53 +00:00

Author

Owner

Resolution

Done: Closed by measurement. No cap built.

Evidence: Q1 still has 45 of 48 nodes from reference/n8n-api-data-tables-403.md, so the crowding is real, but the NOTE block lists distinct notes and the expected note is third. No question in the set fails from crowding. P-Q7 reaches note rank 14 only at budget 40000, past the NOTE block limit, so a cap would not surface it. results-after-1571, rulings.tsv 70.

Follow-ups: none: note split stays on #1574

## Resolution **Done:** Closed by measurement. No cap built. **Evidence:** Q1 still has 45 of 48 nodes from reference/n8n-api-data-tables-403.md, so the crowding is real, but the NOTE block lists distinct notes and the expected note is third. No question in the set fails from crowding. P-Q7 reaches note rank 14 only at budget 40000, past the NOTE block limit, so a cap would not surface it. results-after-1571, rulings.tsv 70. **Follow-ups:** none: note split stays on #1574

jared closed this issue

2026-11-06 21:30:54 +00:00

jared referenced this issue from a commit

2026-11-06 21:33:05 +00:00

docs(os-vault): record the #1571 scores and the rulings on #1568, #1570, #1577