Challenge 04: Same name, different layer, different meaning

Prompt for the dispatched agent

Open this challenge in a fresh-context Claude / LLM session, paste the URL, and say “research this challenge.” The reading list below is layered for progressive disclosure — start at level 1 if you’re new to the project, jump deeper if you already know the context.

The question in one sentence: when the same syntactic folder name (Auth/, 10 - Projects/, Projects/) appears at different depths or under different parents, how should the system disambiguate and produce scope-correct tags — without forcing the user to author N rules per (org-system × entity × position) combination?

Reading order (level 1 → level 4)

1. Foundations (orient first if new to the project):
   • Terminology — plain-English glossary; especially polyhierarchy, axis, pre/post-coordination
   • Philosophy — the typed-model layers; folder-strict-hierarchy vs tag-polyhierarchy diagram
2. Core concepts for this question:
   • SEACOW axes — the six classification dimensions; relevant because entity is one of them and this challenge is partly about per-entity scope partitioning
   • Folder classifiers — enumerative, hierarchical, authority-root, etc.; the same folder name can be in different schemes
   • Bijection and loss — collision vs. lossy distinction is load-bearing here
3. Direct context (the research that frames this challenge):
   • Path abstractions, part 1 — anchor as syntax-vs-semantics; how templates make layer explicit
   • Path abstractions, part 2 — slot-overlap-based resolution; relevant for parameterized anchors
   • Specificity + groups research — the recommended Phase 2.5 design; complements this challenge’s solutions
   • Challenge 05 and Challenge 06 — sibling challenges in the layering/composition cluster; the three solutions overlap
4. Reference (optional):
   • Rule schema — exact field definitions for folderAnchor, folderEntryPoint

Deliverable

Short report at agent-context/zz-log/YYYY-MM-DD-challenge-04-findings.md (~1500–2500 words). Required sections: your framing of the problem (does the original case cover all the variants?), prior-art mapping (what would FTSync look like under each prior-art approach?), evaluation of candidate solutions A–E (or sketch of a Solution F we missed), recommended primary approach with migration sketch, open questions left unresolved.

Tone

Treat existing recommendations as hypotheses to test, not conclusions to defend. Fresh-agent context-skepticism is the point.

---

Assumption under test

Today, a rule’s identity is its pattern. The JD pack ships with folderPattern: '^\\d{2} - [^/]+(?:/|$)' and (after Phase G) optional folderAnchor. The pattern says what shape of folder name to match. The anchor says where in the path to match. Both are static.

This implies that two folders with the same leaf name — say 10 - Projects at vault root and Entity/Cybersader/10 - Projects deep in the tree — are matched by the same rule and produce the same tag (#10-projects/... either way).

Is that the right semantics?

SAME NAME, DIFFERENT POSITION · the bidirectional ambiguity

FORWARD · collision

Vault/
├─ 10 - Projects/Q4-roadmap/note.md
├─ Entity/Cybersader/10 - Projects/x/note.md
└─ Projects/Subprojects/Projects/note.md
       ↓
       any-segment rule fires on all
       ↓
       #10-projects/...  (or similar)

Three distinct scopes collapse to one tag namespace. The user's mental model said these were separate (Cybersader's projects vs Bob's vs the global bucket); the rule's pattern doesn't capture the parent context.

INVERSE · ambiguous

user adds #10-projects/something
       ↓
       which destination?
       ↓
├─ 10 - Projects/something/        ?
├─ Entity/Cybersader/10 - Projects/  ?
└─ Entity/Bob/10 - Projects/         ?

One tag, multiple plausible homes. Today's engine picks first-by-priority silently. See tag→folder resolution research for the broader survey.

Why it might not be

A folder name is syntactically the same string but semantically different at different positions. Three concrete cases:

Case 1 — Same name, different scope

10 - Projects/                     ← global JD: "the projects bucket"
  Q4-roadmap/

Entity/
  Cybersader/
    10 - Projects/                 ← Cybersader's private projects
      side-business/
  Bob/
    10 - Projects/                 ← Bob's private projects (different entity!)
      thesis/

The same JD numbering is being applied independently in three places. The user’s mental model: the content of Entity/Cybersader/10 - Projects/side-business is not in the same Project bucket as Entity/Bob/10 - Projects/thesis. They share a shape but not a namespace.

If a single JD rule fires on all three, every project-named folder under any entity gets thrown into the same #10-projects/* tag namespace. That’s data corruption from a knowledge-organization standpoint.

Case 2 — Same name, different parent organizational system

Projects/                          ← PARA top-level
  Web/
    10 - Backend/                  ← JD-flavored sub-area inside PARA Web
      auth-rewrite/
  Mobile/
    10 - iOS/                      ← JD-flavored sub-area inside PARA Mobile
      onboarding/

Here the user has applied JD nested inside PARA buckets. The 10 - Backend and 10 - iOS folders share the JD shape but they’re scoped differently — #10-backend should arguably live under #projects/web/, not at the root of the tag namespace.

Case 3 — Recursive same-name nesting

Projects/
  Subprojects/
    Projects/                      ← user really did name this 'Projects' too
      this-thing/

Pathological but legal. Phase G’s any-segment anchor matches all three Projects segments. Which tag does Projects/Subprojects/Projects/this-thing get?

Where the abstraction leaks today

• Phase G handles position partially. folderAnchor: 'root' vs 'any-segment' vs { under: 'X' } controls where a rule fires, but the choice is fixed at rule-authoring time. A user applying JD to both root and per-entity can’t express that with one rule.
• Detection’s scopedUnder is gating-only. It tells the system “PARA only applies if SEACOW-outer is also present” — but it doesn’t tell the rules to automatically anchor under the parent pack’s location. The user still has to author that.
• Tag side is unparameterized. A rule’s tag template is a fixed string. There’s no slot for “whatever entity I matched under” to flow into the tag namespace.

Research brief

Hand this challenge to a fresh agent with the knowledge base mounted (docs/src/content/docs/). The agent should:

1. Survey prior art for “same name, different context” disambiguation:

   • Filesystem path resolution — how do shells, file managers, IDEs distinguish ./foo/bar from /etc/foo/bar? (Absolute vs relative paths, working directory, $PATH lookup precedence — the OS-level scoping rules.)
   • CSS specificity — selectors like .card .title vs .modal .title distinguish “title in card context” from “title in modal context”. The cascading specificity algorithm (CSS’s rule for which selector wins when several match the same element) is exactly this problem.
   • XPath / JSONPath / XQuery (query languages for tree-shaped data — XML and JSON respectively) — //div[@class='foo'] matches anywhere; /root/div[@class='foo'] is rooted. The path-axis vocabulary (descendant::, child::, parent::) gives precise position addressing.
   • ARIA roles + DOM hierarchy — a role="button" inside role="menubar" is different from a top-level button. Accessibility tools navigate this routinely.
   • Kubernetes resource names — namespaced (default/my-pod, kube-system/my-pod) — same name, different namespace, different object.
   • AWS ARN format (Amazon Resource Names — globally-unique identifier strings for cloud resources) — arn:aws:iam::123456:role/admin vs arn:aws:iam::789012:role/admin — same role name, different account boundaries.
   • Programming-language scoping — how do nested namespaces / modules / classes resolve identifiers? Lexical scoping (the variable refers to the binding closest in source-code structure), ADL (argument-dependent lookup, mostly C++), hoisting (JavaScript’s “declarations float to the top of their scope”), etc.
   • Library Subject Headings (LCSH = Library of Congress Subject Headings) — English literature -- 19th century -- History vs American literature -- 19th century -- History. The -- subdivision separator (LCSH’s convention for chaining specifying terms) is an explicit context marker.

2. Map each prior-art approach onto folder-tag-sync:

   • For each, sketch what the corresponding rule abstraction would look like
   • What does the rule pack JSON shape become?
   • Concretely: how would the JD rule express “match \d{2} - X at root AND at Entity/<entityname>/, producing scope-correct tags in each case”?

3. Stress-test the existing Phase G anchors against Case 1, Case 2, Case 3:

   • For each case, write the minimal set of rules that gives semantically correct tags
   • Count: how many rules does the user have to hand-author per (org system × entity × position) combination?
   • Identify the explosion point — at what scale does manual rule authoring become untenable?

4. Evaluate parameterized anchors as a candidate solution:

   • Phase G has { under: 'Entity/Cybersader' } (literal). Could it be { under: 'Entity/{entityName}' } (parameterized)?
   • What’s the syntax? { under: { template: 'Entity/{entityName}' } } or just inline { under: 'Entity/{*}' }?
   • How would entityName flow into the tag template? #--{entityName}/10-projects/...?
   • Does parameterized-under introduce a new ambiguity (multiple matches because the slot is polymorphic)?

5. Evaluate scope-pinning as an alternative:

   • Each rule explicitly declares its scope as a path prefix
   • Tags are auto-prefixed with a scope-derived namespace
   • Trade-off: more verbose rule authoring, but no ambiguity

6. Evaluate pack-replication at install time:

   • When the user “applies JD pack to this vault,” the loader could detect N entities and emit N pre-anchored copies of the JD rules
   • Pros: no parameterization complexity in the rule abstraction itself
   • Cons: rule list bloat; user sees 4×N rules; updates have to ripple through copies

Candidate solution directions to evaluate

The agent should weigh at least these:

Solution A — Parameterized anchors with slot capture. Anchor becomes a template: { under: 'Entity/{entityName}' }. The captured slot flows into the tag template: #--{entityName | kebab}/10-projects/.... One rule handles all entities. Cost: the under field becomes a mini-DSL of its own; pattern semantics get more complex.

Solution B — Scoped rule packs (pack instance per scope). At install time, the user picks a “scope” (a path or path glob) for the pack. The loader generates one anchored copy of each rule per matched scope. Cost: rule count grows linearly with scope count; updates via re-install.

Solution C — Tag-side namespace slots. Rules express the tag template with namespace slots: #{scope-prefix}/10-projects/{rest}. The scope prefix is computed from the matched folder path’s prefix relative to the rule’s anchor. Cost: requires anchor + path-relative computation in the engine.

Solution D — Explicit context-aware rule pairs. Replace one rule with N — one per scope context. User authors JD-at-root, JD-under-cybersader, JD-under-bob separately. Cost: N×M explosion; user UX poor; no DRY.

Solution E — Tree-pattern matching (XPath-flavored). Rules are tree patterns, not path regex: Entity/*/10 - Projects/** with explicit captures. Engine walks the tree, not the flat path string. Cost: bigger engine rewrite; new mental model.

For each candidate: rate authoring cost, expressive power, hybrid-coexistence with current regex rules, engine complexity, UX clarity. Pick a winner; explain why; sketch the migration.

Deliverable

Short report (~1500-2500 words) at zz-log/YYYY-MM-DD-challenge-04-findings.md:

• The agent’s own framing of the problem (does the original case the user posed cover all the variants? are there others worth naming?)
• For each prior-art approach: what would folder-tag-sync look like if it adopted that approach?
• Verdict on candidate solutions A–E (or sketch of a Solution F we missed)
• Recommendation for Phase H+ — should this be a same-phase concern or a future phase?
• Open questions left unresolved

Hand-off note

This challenge sits adjacent to the path templates research log entries (Parts 1 + 2). The path-template work answers how to author one bidirectional rule — this challenge asks how the system handles when one rule’s matches mean different things at different positions. They’re orthogonal and both need answers before Phase H ships its UI.