Adjacent project + question on the Tier model design

[vdalhambra]

Hi Jack,

Saw obsidian-mcp-tools — the bidirectional Markdown conversion + the way you handled batch ops is clean. Stole a structure idea for my own memory layer (it's in mem-refs-mcp inside the bundle below).

I open-sourced the bigger thing today: 7 PreToolUse hooks + 6 skills + 6 subagents for Claude Code, all wrapped with a memory tiering scheme. Apache 2.0:

👉 https://github.com/vdalhambra/axiom-reflex

Show HN is Tuesday. Two questions where I'd value your read:

1. Does the Tier 0–6 model (identity → projects → skills → daily → patterns → refs) feel like it'd work for the way you organize your own Claude Code state, or am I over-engineering the layering?

2. obsidian-mcp-tools is read/write-symmetric on a vault. axiom-reflex is more biased toward write-prevention (blocking bad calls before they ship). Have you considered a write-side enforcement layer in your tools, or is that explicitly out of scope?

Either reply pulls weight. No marketing intent — comparing notes between adjacent solo builders.

Thanks.
— Víctor (vdalhambra)

[istefox]

Hi @vdalhambra — Jack hasn't replied because upstream is officially unmaintained per #79 (declared 2026-04-24); the active continuation is the community fork istefox/obsidian-mcp-connector (0.4.0 released 2026-05-04). Stepping in as fork maintainer since the design questions are exactly what I sit in front of.

Q1 — Tier 0–6 (identity → projects → skills → daily → patterns → refs). obsidian-mcp-tools/the fork has no explicit tiering — the surface is vault-scoped, the agent decides what to read/write inside, and the closest analog is the user's own folder structure plus the Obsidian metadata cache (tags, links, frontmatter) that every tool transparently sees. Whether your 0–6 is over-engineered depends on differential access frequency, not bucket count: if Tier 3 (daily) churns 100x more than Tier 4 (patterns), the layering pays for itself; if all tiers churn similarly, you're carrying schema overhead for no caching/precedence win. The acid test: can a PreToolUse hook short-circuit at a higher tier because a lower tier already covers it? That's the structural payoff signal — without it the tiers are just labels.

Q2 — write-side enforcement. Yes, but selectively. execute_obsidian_command is gated by a command-permissions feature (deny-by-default + per-command allowlist + modal confirmation + audit log + soft rate-limit) — full threat model in docs/design/issue-29-command-execution.md. For vault-file ops the fork is read/write-symmetric intentionally (caller controls scope), but with hardening on irreversible paths: e.g., patch_vault_file with targetType: "heading" defaults createTargetIfMissing: false so a typo can't silently append at EOF (#58 in the fork). Different philosophy from axiom-reflex's PreToolUse blocking — symmetric on cheap reversible writes, gated on irreversible ones.

The fork's HTTP-embedded architecture (in-process MCP server on 127.0.0.1:27200, no binary, npx mcp-remote bridge for stdio clients) is a different shape from your hook-based flow, but the read-side surface (vault read, semantic search via on-device MiniLM, template execution) overlaps yours — feel free to cross-reference if useful.

— Stefano