llm-context-base boundary

Type: agentic-system-analyses/types/agentic-system-boundary.md

Boundary and evidence

This run analyses llm-context-base as a template for an LLM-maintained personal knowledge base. Its intended use is to retain captures, knowledge, decisions, projects and personal context in files, then have a file-capable assistant reload, query and maintain those files. The target is a memory/knowledge/context-engineering system, not an enclosing agent runtime. Its model-dependent operation is prescribed by shipped prompts consumed by external AI tools. The absence of an internal model-call implementation does not remove the instruction-driven knowledge loop from scope (SRC-1, README.md, PHILOSOPHY.md, docs/supported-tools.md).

The target explicitly separates its substrate from the host:

The repo stays dumb. The intelligence lives outside it. --- PHILOSOPHY.md

No runtime. The repo doesn't run. It exists. Sophisticated behaviors — monitoring the web, creating PRs, integrating with external services — belong in the intelligence layer above. --- PHILOSOPHY.md

The whole-system boundary covers the shipped substrate: tool bootstrap prompts and recommended permissions; session initialization and phase-sensitive context loading; configuration and learned preferences; capture and source preservation; metadata, templates and admission/completion instructions; query and decision-precedent consumption; lint and instruction optimization; project indexes and logs; Obsidian capture settings and the clipper template; and the metadata migration utility. This is whole-system coverage of the template's material shipped responsibilities, not of the external hosts that act on them (SRC-1, AGENTS.md, _config/config.md, _meta/instructions/general.md, _meta/instructions/agent-write.md, _meta/instructions/knowledge-query.md, _meta/instructions/knowledge-lint.md, migrate-to-yaml-frontmatter.py).

Entry-point inspection traced all six bootstrap files to the shared configuration and general module. Those prompts belong to the target even though their consumers execute outside the repository. The generic bootstrap declares:

Follow the Session Start Protocol defined in _config/config.md, then _meta/instructions/general.md. All instructions are there. --- AGENTS.md

The general module connects conversation output to retained state, including instructions and preferences:

The rule: when something new is established in conversation, update the relevant file immediately. --- _meta/instructions/general.md

The later query path explicitly consumes retained content:

Read the 1-3 most relevant files in full. For very large files (500+ lines), focus on the first major section. --- _meta/instructions/knowledge-query.md

Accordingly, the boundary includes both the writing and later reading instructions, rather than treating the write API or metadata format alone as the system. It includes the supplied lint and completion criteria as prescribed evaluation paths, not as demonstrated independent evaluators. The tracked tree contains no separate test suite, benchmark harness or observed agent trace; the sample records are examples, not measured operation (SRC-1, _meta/instructions/definition-of-done.md, _meta/instructions/knowledge-lint.md, examples/example-decision-record.md).

Coverage of the tracked top level

All rows concern SRC-1 at the reviewed commit. “Included, inspected” denotes source-text inspection, not execution. Deliberately excluded supporting material remains available at the same commit; it is not an access gap. Empty placeholders were identified through the tracked tree. No material loop path is left uninspected.

Dependencies, exclusions and evidence limits

External dependencies include a file-capable LLM assistant and its filesystem/shell tools for the prescribed loop; Git/GitHub for versioning, optional upstream updates and hosted sync; Obsidian and its browser clipper for optional human capture/viewing; Marp for optional rendered outputs; and optional journal encryption or external synchronization tools. The target ships instructions and configuration for these integrations, not their implementations (SRC-1, docs/supported-tools.md, docs/obsidian-setup.md, docs/journal-sync.md, _config/tools.md).

The host owns model selection, inference, instruction discovery, context-window handling, actual filesystem operations and permission enforcement. These responsibilities are excluded; the boundary cannot establish reliable prompt adherence, isolation, security or cost across Claude Code, Cursor, Copilot, Windsurf or other hosts. Built-in Claude memory outside the repository, referenced in the FAQ, is likewise not target-retained state (SRC-1, .claude/settings.json, docs/supported-tools.md, docs/faq.md).

Documented hooks, connectors, MCP servers, third-party plugins and linked code repositories are included only as shipped recipes or integration expectations. No separate source has been acquired for them. Their implementation, uptime, privacy guarantees and correctness cannot be concluded here. In particular, the optional hook script described in the Claude setup page is not a tracked shipped script; the linked-code scaffold has no executable implementation in this tree (SRC-1, docs/claude-code-setup.md, docs/linked-code-repos.md).

The frozen evidence is Git commit 6d01cba8e2c22f9ca2519c70073a05cd54378a8c, verified as the checkout's HEAD, with applicability cutoff 2026-10-14 from the supplied opening record. No live pages, dependencies, other repositories or later revisions are included. The overall tier is doc-grounded because the knowledge loop is defined by prompts and documentation, not an inspected internal model-calling runtime. The migration utility supplies a bounded implementation layer for metadata conversion only. No target execution, tests, provider calls or experiments were performed. These limits prevent conclusions about observed adaptation, retrieval accuracy, maintenance reliability, causal improvement or production-scale performance.

Source register