# INTRALOCK ## Sole-Source Product Architecture, Technical Specification, Engineering Plan, Operations Manual, and Conformance Blueprint **Version:** 1.0.0 | **Date:** 2026-11-09 | **Status:** Proposed canonical design; not a claim of completed implementation **Project:** Intralock only | **Document owner:** Intralock engineering | **Canonical file:** `INTRALOCK_MASTER_SPEC.md` **Positioning:** *Your Files. A Living Workspace.* **Reading rule:** All normative requirements in this document are proposals for implementation. `MUST` means required to claim conformance to this Intralock specification; `SHOULD` means a strong recommendation; `MAY` denotes optional functionality. External protocols retain the normative meaning assigned by their own published specifications. > **Product definition.** Intralock is a local-first, filesystem-native, machine-readable workspace operating system. It turns existing folders and files into navigable, searchable, connected, verifiable, application-capable workspaces without moving original content into a proprietary vault. Its core is deterministic and useful without an AI model. Intelligence is a replaceable, permissioned enhancement. All human and agent interfaces use a shared object model, capability registry, policy engine, and audit ledger. > **Canonical authority rule.** Files own their content. Explicit manifests declare intent. SQLite indexes observable state. Graph projections express relationships. Lock snapshots attest a particular state. Policy determines who may act. Interface adapters present governed capabilities. Neither an LLM response nor a rendered homepage may silently become authoritative. ## Reading map and document contract The document progresses from product and architecture through data model, filesystem and runtime, knowledge, interface contracts, security, execution, deployment, quality, operational procedures, and roadmaps. It includes sample SQL, JSON, Go-oriented APIs, route designs, CLI commands, MCP/WebMCP patterns, acceptance tests, quality gates, and a detailed feature/capability catalog. It deliberately describes only Intralock itself. References to public standards and open-source libraries are engineering inputs, not dependencies on unrelated private products. ### Status and maturity labels - **Core / P0:** required before calling the first standalone release usable. - **Platform / P1:** required before claiming the complete multi-interface platform. - **Advanced / P2:** optional advanced workspace features that build on stable P0/P1 boundaries. - **Experimental:** protocol or feature not ready to be treated as universally implemented across clients. - **Compatibility:** retained only to interoperate with older external clients, with a documented migration path. Claims of protocol compliance MUST be backed by versioned compatibility tests, not merely by publishing an endpoint or manifest. Claims of offline functionality MUST be tested in a network-isolated environment. Claims of safety MUST be supported by denial, traversal, mutation, and recovery tests. --- # PART A — PRODUCT DEFINITION AND SYSTEM BOUNDARIES ## 1. Product mission, user outcomes, and operating premise Intralock exists to make the ordinary local filesystem an effective operational environment rather than an unstructured dumping ground. Its starting point is not a new database into which a user imports everything. Instead, the user selects a directory; Intralock observes the files and subdirectories already present, assigns persistent logical identities, builds a local searchable catalog, optionally renders a coherent landing page, and exposes structured ways for humans and authorized software to work with those assets. The user remains able to browse, edit, rename, copy, or move original files through ordinary system tools. The primary product promise is a reversible transition from **folder** to **workspace**. A workspace can show its overview, documents, tasks, evidence, relationships, history, status, capabilities, quality checks, and application panels while still being a normal folder on disk. Selecting a subdirectory opens a nested workspace view, not a dead-end listing. Search follows the permissions of the user and the boundaries of the chosen workspace. Navigation remains comprehensible when the service is unavailable: generated artifacts are static and ordinary files remain usable. Intralock must support an individual operator with one computer, a studio with multiple managed directories, and eventually a controlled local multi-user installation. The baseline customer should not have to become a systems administrator or surrender data to a cloud account. The first experience is choosing a folder, reviewing read-only findings, choosing which generated artifacts to create, and seeing an immediately useful directory dashboard. Advanced features are disclosed progressively, not forced into initial onboarding. What the product is not: a mandatory cloud drive, a replacement filesystem, an opaque autonomous agent, a universal enterprise resource-planning application, a speculative graph that can overwrite user documents, or a distributed database in disguise. These systems may be represented as files, views, or optional extensions later, but Intralock's own truth boundary remains local files plus explicit internal state and policy. The product must retain useful read, navigation, search, metadata, and export operations when every AI provider is disabled. ## 2. Personas, jobs-to-be-done, and functional acceptance **Operator.** An individual curates many working folders, needs to know what is inside, what changed, what depends on what, what is missing, and which tasks deserve attention. Their ideal outcome is a rapid transition between current project state and relevant evidence. They value a single-command backup, a clear change history, and no surprise content rewrites. **Builder.** A technical creator maintains code, data, assets, documentation, schemas, and scripts in the same project tree. They want workspace-specific views, generated file inventories, code-aware indexing, test results, capability declarations, and consistent human/agent documentation. A builder must be able to inspect and reproduce generated artifacts rather than trusting black-box logic. **Researcher.** A user works with PDF, Markdown, HTML, structured datasets, notes, recordings with transcripts, and collected references. They need citations, stable links, extraction provenance, relationships, and confidence labels. A search hit must reveal its source path, extraction method, offsets, version, and whether interpretation was generated rather than observed. **Agent client.** A machine client needs a narrowly scoped way to discover, read, search, request context, propose changes, and execute approved work orders. It must never infer its authority from instructions inside an untrusted document. Tools should be small and predictable; returned data should preserve boundaries, provenance, and typed errors. **Maintainer.** A person responsible for upgrades, backups, storage, performance, migrations, and recovery requires diagnostics, explicit schema versioning, repair commands, export/import, signed release metadata, and a legible operational state machine. Functional acceptance is task-based. A user must be able to: (a) register a local workspace; (b) index it offline; (c) see a human-readable hierarchy and searchable inventory; (d) read a document and find related documents; (e) receive a clear conflict rather than an overwrite when a generated page has been manually changed; (f) revoke an agent token and immediately prevent further access; (g) export a machine-readable snapshot; and (h) rebuild local indexes without losing original content. These journeys become formal end-to-end test fixtures. ## 3. Ten immutable product invariants 1. **Non-destructive first contact.** Attaching an existing directory cannot modify any of its files until a distinct explicit permission or managed-directory onboarding step authorizes the change. 2. **Local operation.** Read, browse, FTS search, graph traversal, backup, and policy evaluation must work without external network connectivity. 3. **Path-independent IDs.** Logical object identities survive ordinary moves when identity can be established with sufficient confidence; ambiguous matches become review items. 4. **Separate derived state.** Indexes, embeddings, thumbnails, caches, and most generated pages can be deleted and rebuilt from authoritative sources and accepted annotations. 5. **No silent elevation.** A role, model, plugin, document, browser action, or tool description cannot grant itself powers. Authority is established by authenticated subject, policy, scope, consent, and current state. 6. **Accountable mutations.** Mutating operations carry idempotency keys, preconditions, audit trails, origin, and, where possible, rollback instructions. 7. **Provenance-aware intelligence.** The system exposes what is observed, inferred, proposed, approved, and verified. Confidence is not fact. 8. **Interface equivalence.** The same governed domain operation is invoked across UI, REST, MCP, WebMCP, GraphQL mutation, and CLI; adapters do not bypass policy. 9. **Exportability.** Structured metadata and graph state can be exported with documented schemas and file references; restore is verified by deterministic tests. 10. **Graceful degradation.** Failed extractors, offline model adapters, missing vector indexes, and unsupported browser APIs do not collapse core file navigation and search. Every architecture decision must identify the invariant it strengthens, its tradeoff, its ownership, and a negative test proving it does not break an invariant. An exception requires a written architectural decision record, an explicit user-facing warning when applicable, a migration plan, and a bounded sunset. ## 4. Definition of local-first and a clear consistency model Local-first is a technical condition, not a visual branding phrase. The workspace's ordinary files stay on an operator-controlled filesystem. Private workspace indexes and receipts are local. The system starts, indexes, and serves content when network interfaces are disabled. No login to a hosted account is required for a personal loopback installation. Optional networked use must preserve an isolated operating mode and must never make remote connectivity the single path to local data. A file change is committed by the underlying filesystem, not by a semantic vector database. Intralock's catalog is an asynchronously reconciled **projection** of that filesystem. Therefore it must distinguish `observed_at`, `indexed_at`, `content_mtime`, `content_hash`, `watcher_sequence`, and `catalog_version`. An index can temporarily lag behind a file; API responses should expose an index freshness indicator, and high-risk write preconditions must recheck the actual source. SQLite's transaction commit establishes catalog consistency, not the immutability of files another process can edit concurrently. The reference deployment is a single local daemon with SQLite WAL and one elected writer per catalog. The system may process extraction work concurrently, but all catalog mutations use bounded transactional commits. File writes use same-filesystem temporary files, fsync where required, atomic replacement when supported, and version checks. Cross-device moves and remote filesystems require special handling; file watcher events are hints, not definitive truth. A periodic inventory reconciliation closes missed-event gaps. If optional sync is introduced, it is an outbox/inbox replication layer, not a new primary truth store. A remote copy has no right to silently overwrite locally edited files. Conflicts are presented as separate versions or review items, tombstones are durable and scoped, and deletion is not broadcast without authorization. Sensitive files remain excluded even if a remote replica requests them. ## 5. System context, ports, processes, and execution boundaries A standard single-host deployment contains one `intralockd` process, one SQLite catalog per profile or installation, a workspace registry, extractor workers, a change observer, a local policy service, an HTML/HTMX HTTP server, optional MCP transports, and optional enrichment adapters. The daemon owns catalog transactions and manages per-workspace locks. An `intralock` CLI acts as a client and can launch the daemon in a controlled foreground mode. A companion menu-bar or tray process is optional, not a requirement for core operation. Recommended default local listen address: `127.0.0.1:8765`; IPv6 loopback MAY be added explicitly. Loopback binding is not proof of authentication, because local browser cross-origin attacks and other local processes may attempt requests. The HTTP server enforces origin checks, anti-CSRF rules, capability authentication where appropriate, and explicit secure defaults for mutating operations. Network listening on all interfaces is disabled until the operator explicitly configures TLS, authentication, a firewall policy, and a known audience. ``` Local filesystem ── watcher/reconciler ──> extraction pipeline │ │ │ v └── original files SQLite catalog/FTS/graph │ Domain + capability services │ │ │ │ policy jobs audit events └─────┬─────┘ │ ┌──────────────┬───────┼──────────┬─────────────┐ HTML/HTMX REST GraphQL MCP CLI/SDK │ │ │ Browser/PWA client stdio/HTTP │ WebMCP (browser tools over authenticated actions) ``` All adapters are outer layers. Domain services do not import HTTP routing types, model SDK types, HTML templates, or protocol-specific response structures. They consume a typed `RequestContext`, an `Actor`, a `WorkspaceScope`, an `Operation`, and validated input. This separation is fundamental for conformance across interfaces and for future compatibility work. ## 6. Reference implementation stack and explicit alternatives Use **Go** for the daemon, work queues, index coordinator, filesystem adapters, policy enforcement, core REST server, local MCP server, and CLI. Standard library `net/http`, `html/template`, `context`, `database/sql`, `crypto`, and `os` should be preferred where sufficient. Use **HTML + HTMX** for the application shell and progressive server-rendered behavior. Keep CSS as a versioned design system and JavaScript narrowly focused on functions that require it: graph canvas, drag interactions, browser capabilities, WebMCP, offline shell, and accessible dynamic updates. Use **SQLite** as the catalog, task ledger, work-order registry, permissions database, file snapshot registry, relational graph store, and full-text search index. Enable foreign keys and WAL where safe; keep backups and integrity verification tested. Use **FTS5** for lexical search. A vector index is optional and replaceable; no core feature may require vectors. Choose one Go SQLite driver after proving its build, license, FTS5, backup, extension, and platform requirements. The reference specification does not assert that every SQLite driver supports every extension or encrypted VFS in the same way. Open-source reference candidates include Go's official tools, the official MCP Go SDK, htmx, `fsnotify`, `modernc.org/sqlite` or another verified driver, optional `sqlite-vec`, `gqlgen`, `chromedp` or Playwright for browser testing, OpenTelemetry, and accessible component patterns rather than a heavy client-side framework. Dependency evaluation must record license, transitive dependencies, maintainership, vulnerabilities, binary size, cross-platform behavior, and offline installation behavior. These are reference choices, not license-free promises to redistribute or embed arbitrary code. Default packaging should be a single versioned daemon and CLI binary, embedded audited static web assets, schema migrations, and optional platform-native wrappers. Do not require Node.js in the production runtime for a standard installation. Build tools may use Node-based compatibility tests but their outputs must be reproducible and committed or locked by digest. ## 7. Product domains and internal module contracts Organize domain packages around stable responsibilities: `workspace`, `object`, `filesystem`, `catalog`, `metadata`, `extract`, `search`, `graph`, `context`, `page`, `policy`, `identity`, `credential`, `capability`, `task`, `workorder`, `audit`, `events`, `backup`, `export`, `import`, `health`, `extension`, and `sync` (experimental). A domain package exports commands, queries, errors, schemas, and events; it must not assume that every caller is a web UI. **Workspace** establishes boundaries and configuration. **Object** maintains identities across paths and versions. **Filesystem** resolves paths, normalizes names, reads content, and performs safe writes. **Catalog** manages SQLite transactions and migrations. **Extract** derives canonical text and metadata. **Search** ranks evidence and returns permission-filtered results. **Graph** stores typed edges and evidence. **Context** assembles bounded, permission-aware snapshots. **Page** renders generated human-facing states and reconciles owned regions. **Policy** decides and explains allow/deny outcomes. **Capability** describes operations and maps transports. **Task** manages durable execution. **Audit** records authorized actions, errors, and recovery evidence. Imports follow an acyclic dependency discipline. Domain libraries may depend on narrow ports such as `Clock`, `Filesystem`, `ObjectStore`, `Transaction`, `Authorizer`, `EventWriter`, and `Extractor`. Outer adapters implement these ports. A generated dependency graph becomes a CI check; any cycle must fail architecture validation. Integration tests run the same operation through at least two adapters and assert equal domain results and equivalent denial behavior. ## 8. Core data lifecycle and operational state machine Each managed source object moves through `discovered → fingerprinted → classified → queued → extracted → indexed → linked → ready`. A failure can move it to `blocked`, `quarantined`, or `retry_pending` with an explicit reason; deletion becomes `missing_pending_reconciliation → tombstoned` only after configured verification. Unsupported formats remain indexed at the file metadata level with an `unsupported_extraction` flag. A quick rename can preserve identity while generating a new path alias and a moved event. The job system must be durable. Every stage creates an attempt record with start/end timestamps, processing version, input hash, output hash, extractor identity, and status. Retries use exponential backoff with jitter, a maximum attempt count, and a dead-letter or operator-review queue. One corrupted document must not stop an entire workspace refresh. An interrupted daemon recovers pending jobs from the ledger, verifies their source hash again, and completes or requeues idempotently. Generated views follow a different lifecycle: `not_present → proposed → previewed → approved → published → observed_manual_change → reconciliation_required → republished/abandoned`. Never conflate extracted state with accepted authored content. An AI-proposed relationship follows `suggested → reviewed → accepted/rejected`; it does not silently become an observed structural edge. These state machines are exposed as metrics and command results so operators can see where a workspace pipeline actually stands. --- # PART B — FILESYSTEM, WORKSPACE FORMAT, IDENTITY, AND SNAPSHOTS ## 9. Workspace layout and reserved paths A workspace is any existing directory registered in the local workspace registry. An Intralock-managed directory may contain a manifest, human and agent instructions, generated homepages, and hidden management files, but none is compulsory for initial read-only indexing. The following is a recommended canonical layout; the actual user tree may include arbitrary files and folders outside it. ```text my-workspace/ index.html # optional human-facing homepage; preserve authored regions intralock.lock.html # verifiable generated snapshot and context entrypoint AGENTS.md # human-readable agent guidance; never an authority grant manifest.yaml # optional workspace declaration README.md # ordinary authored documentation docs/ # normal user data datasets/ # normal user data applications/ # normal user data .intralock/ workspace.json # stable ID, schema, tracked root identity policy.yaml # declarative defaults and explicit overrides generated/ # generated templates and static assets manifests/ # generated structured manifests receipts/ # signed or hash-linked operation receipts revisions/ # bounded backups of generated file revisions snapshots/ # reference hashes and export metadata cache/ # discardable per-workspace output ignore # user-readable exclusion rules local/ # explicitly local-only nonportable state ``` By default the primary SQLite catalog, token storage, secrets, long-lived audit ledger, and caches live under a private application data directory **outside** user workspaces. This avoids accidentally committing secrets or megabytes of indexes to a source repository. A portable workspace export may include opted-in metadata, manifests, accepted annotations, and lock snapshots without copying private credentials. Generated outputs inside `.intralock/` should be named clearly and listed in a provenance manifest. Reserved files must have documented ownership and collision policy. If an existing `index.html`, `AGENTS.md`, `.intralock/`, or `manifest.yaml` is present and not explicitly adopted by the user, onboarding must show a diff and choose non-conflicting outputs. Do not overwrite these files merely because their names match the conventional pattern. New managed directories receive a recognizable `generated-by` metadata marker and accepted ownership record. ## 10. Workspace manifest format and precedence `manifest.yaml` is optional, versioned, human-editable configuration. Store its parsed and validated form in the local catalog, but preserve the file as the authoring source for portable settings. An explicit local UI setting may override a manifest for the local installation only; that distinction must be visible rather than silently mutating the file. Local secrets never belong in the manifest. Field-level precedence is `explicit operator/session choice > local protected override > workspace manifest > inherited policy > installation default`, except that a stronger deny always prevails over a weaker allow. ```yaml schema: intralock.workspace/v1 id: wks_01JEXAMPLESTABLEID name: Example Workspace root: . indexing: enabled: true content: true follow_symlinks: false max_file_bytes: 52428800 ignores: [".git/**", "node_modules/**", "**/.env", "**/secrets/**"] views: homepage: index.html lock_snapshot: intralock.lock.html generation: preview_then_approve search: lexical: true semantic: false security: baseline: private remote_access: false mutations: approval_required capabilities: profile: local_read_only extensions: [] ``` Validate unknown keys according to schema version and a configured strictness profile. In strict mode, unknown security-sensitive keys fail validation. In permissive import mode, preserve unfamiliar fields under a separate namespace without executing them. A human must be able to run `intralock manifest validate`, see the exact failing line and rule, and receive a migration suggestion. Declarative settings must never embed executable commands unless they are confined to a separate, expressly trusted execution policy. ## 11. Stable object IDs, moves, aliases, and collision handling Assign a generated stable ID to each observed filesystem object. Do not use absolute paths as primary keys. Maintain an immutable internal identity, a current canonical path, historical aliases, a workspace ID, a source fingerprint, and an identity confidence classification. Hashes identify content versions and allow deduplication, but are not sufficient by themselves to identify an object: two files can share identical content while being intentionally separate objects. File IDs/inodes can assist with move detection, but their semantics vary across filesystems and backups. A move resolver uses a confidence ladder: explicit persisted identity marker if available; recorded filesystem-native stable ID on the same volume; atomic move event correlated with prior state; unique content hash plus temporal and structural evidence; and finally an operator review. Never merge two logical objects solely because their content hashes match. If a hard link is found, represent distinct paths and possible shared physical backing without assuming user intention. For symlinks, record the link as an object with a target descriptor; do not traverse targets outside the approved workspace without a separate allow decision. All public references should prefer `intralock://workspace/{workspaceId}/object/{objectId}` or HTTP route IDs over filesystem paths. Path-display fields are treated as presentation metadata, not authority. A path normalization subsystem must test Unicode normalization, case-insensitive volumes, Windows reserved names, macOS aliases, junctions, and ambiguous separators. Collision states should be recoverable without silently reassigning IDs. ## 12. `intralock.lock.html`: generated verifiable state, not a secret vault The lock HTML is a human-readable, machine-discoverable, versioned snapshot of a managed workspace's declared and observed state. It is **not** the sole graph database and does **not** grant permissions. It may include workspace title, snapshot ID, capture time, source manifest hashes, root ID, indexed object counts, representative typed relationships, capability summaries, provenance tables, data freshness, generated link maps, and an attached or linked JSON snapshot. The file must render meaningfully without JavaScript and without an Intralock daemon. The generator writes deterministic content for the same canonical input and generator version, excluding deliberately documented variable metadata. A content digest covers the normalized snapshot payload, not volatile display formatting. Optional signatures bind a private-key signer and key ID to the digest. Verification compares current source or ledger state against the signed snapshot, reporting `verified`, `stale`, `modified`, `unverifiable`, or `invalid`. The lock should disclose which files were excluded from enumeration and must not inadvertently expose a private directory tree when published. Embed JSON-LD or a structured JSON payload using a safely escaped non-executable script block when necessary. Reject unsanitized HTML from extractors and generated descriptions. Any user-authored `intralock.lock.html` collision is handled like a normal conflict: do not overwrite unless ownership is established. An acceptable workflow is to generate under `.intralock/generated/` and show a preview with an explicit adoption step. ## 13. `AGENTS.md`, `SKILL.md`, and the instruction-security boundary `AGENTS.md` documents the workspace's architecture, editing conventions, public paths, testing commands, permitted workflow descriptions, and review expectations for authorized agents. It is **documentation**, not a grant of credentials or access. A machine client reading it must still authenticate and pass server-side policy checks for each operation. A document may contain malicious instructions; therefore content retrieved from the workspace is lower-trust material relative to the caller's system instructions and the server's authenticated policy. Intralock may install generated agent guidance in an owned section of an existing `AGENTS.md`, or place it in a separate generated file that the user can include. The generator must support round-trip parsing and region ownership delimiters. Changes to manual content are never assumed safe to rewrite. A workspace-specific `SKILL.md` may describe a bounded workflow with declared inputs, output artifacts, prerequisites, non-goals, risk classification, and verification steps. Each skill is assigned a version and digest; the server exposes only the approved version for the caller's current scope. Instruction documents are not executable by default. A code sample, command, or shell script inside a workspace must not run merely because an indexer encountered it or an agent requested context. The execution system uses a separate allowlisted tool registry, isolated runners, resource limits, typed arguments, and approvals. Tests must inject instruction-like text into PDFs, comments, HTML, manifests, and retrieved search snippets, and verify that the system treats the text as data rather than escalating authority. ## 14. Managed homepage strategy and authored/generated regions Each directory can expose an `index.html` without requiring one to physically exist. The preferred sequence is: render a **virtual** homepage from the catalog; offer the user a preview; publish a static homepage only when requested; and maintain only generated, owned regions thereafter. This avoids colliding with websites or applications that already have an authored `index.html`. A generated homepage includes folder heading, purpose, breadcrumbs, summary, child folders, key documents, freshness, changes, relationships, tasks, and action panels appropriate to the caller's rights. Use explicit region markers and a stored base hash for managed sections. On regeneration, parse the current file, compare each region to the last generated base, then either update untouched managed regions or return a three-way diff and a conflict requiring review. Never use broad string replacement across the entire document. The generator must escape file names and content, reject script injection, and preserve manual edits outside owned sections. Rendered directory routes should work when no physical homepage is present. A Folder Steward is an optional deterministic service that checks homepage freshness, missing links, object counts, navigation changes, and stale summaries. An AI-assisted steward may draft explanations or suggest sections, but every authored sentence from an untrusted model is separately marked as a proposal until accepted. Repeated generation from unchanged inputs must be idempotent; a generated page must carry a generator version and receipt so the operator can reproduce its origin. ## 15. File observation: watcher, inventory, fingerprints, and exclusions The watcher uses filesystem notifications to schedule small reconciliations, but it never treats one event as an infallible source of truth. Use bounded debounce windows, coalescing by workspace and path, periodic full inventory scans, and queue backpressure. Watched directories can exceed OS limits; the system must detect and report degraded event coverage, fall back to polling, and avoid spinning. On restart, compare journal checkpoints to the current inventory; rebuild when journal continuity cannot be proved. The indexing preflight applies ignore patterns, privacy classifications, file-size limits, recursion caps, byte budgets, symlink policies, device boundary restrictions, and a denylist of sensitive filenames and directories. Never read the contents of an excluded file to decide whether it should have been excluded. Exclusions must be applied before extraction, embedding, logging, thumbnailing, remote communication, or MCP exposure. Patterns are inherited with explicit precedence and displayed in a dry-run report. Fingerprint incrementally using metadata first and content hashes when needed. A content hash should be computed only for files that pass preflight and under bounded I/O. Large files use streaming readers; extraction processes have CPU, memory, time, and output-size limits. Detect file changes during reads with before-and-after stat/fingerprint checks and retry rather than indexing a torn version. Extractors must never follow arbitrary URLs, resolve untrusted network references, or execute macros by default. ## 16. Extraction formats, parsers, and unsupported content Prioritize text, Markdown, HTML, JSON, JSONL, CSV, TSV, YAML, TOML, source code, PDF, Office formats, images with explicit optional OCR, and transcript-bearing media. Extraction modules advertise supported MIME types, extension hints, maximum sizes, text fidelity, metadata capabilities, runtime dependencies, and security profiles. MIME sniffing and filename extensions are both considered but neither alone is trusted. Every extracted segment records the extractor name/version, original file version, offsets, page/line markers if applicable, language, encoding, and errors. For HTML, retain a sanitized text representation and useful heading/link structure; never execute active content. For source code, derive symbols/imports with parsers where available, but preserve a reliable plain-text fallback. For PDF, mark page numbers and distinguish embedded text from OCR; if a page is image-only and OCR is disabled, expose an explicit extraction gap. For spreadsheets, represent sheets, headers, row ranges, inferred types, and formulas as untrusted text, not executable instructions. For documents with embedded media, record missing extracted children rather than hiding them. A failed or unsupported extraction must not hide the file. The object still appears in directory views and metadata search with a clear `content_unavailable` or `extractor_error` state. Keep extracted text in a controlled local derived store with retention rules; do not attach it permanently to the original file unless the user chooses an export. Establish regression fixtures for malicious ZIP bombs, malformed PDFs, oversized XML, encoding errors, symlink loops, massive directory depth, and archives that attempt path traversal. --- # PART C — DATA, GRAPH, SEARCH, AND GOVERNED CONTEXT ## 17. Relational catalog design and migration discipline SQLite is the local system-of-record for Intralock's **operational facts about files**, not a replacement for the bytes of ordinary files. Split tables by ownership and lifecycle: `workspaces`, `objects`, `paths`, `object_versions`, `file_observations`, `extractions`, `segments`, `edges`, `claims`, `evidence`, `entities`, `tags`, `views`, `capabilities`, `actors`, `roles`, `policies`, `grants`, `tokens`, `tasks`, `task_attempts`, `work_orders`, `approvals`, `audit_events`, `receipts`, `event_outbox`, `sync_peers`, `sync_conflicts`, and `schema_migrations`. Use foreign keys, unique indexes, check constraints, and explicit version columns. Application code must not encode correctness solely in undocumented conventions. Objects and versions are separate: one object may be updated repeatedly, renamed, or moved. Store observations separately from current state so a historical search result can link to the correct version. Graph edges are versioned and provenance-linked, not anonymous strings. Every background run should include `source_version` and `pipeline_version`, permitting predictable invalidation when extractor or schema logic changes. Write APIs accept optimistic `expected_version` preconditions to reject stale updates. Migrations are forward-only by default, checksum-verified, transactional when supported, and preceded by a compatible backup. A migration plan documents rollback feasibility, indexed search rebuild costs, disk amplification, and minimum compatible daemon version. No binary may silently open and mutate a catalog with a future schema version. Read-only inspection is allowed when compatible; otherwise explain how to restore the correct binary. ## 18. Reference SQL schema and indexing strategy The following abbreviated SQL is illustrative and must be expanded to full constraints, indexes, triggers, and migration tests before release. IDs are opaque text; timestamps use a documented UTC representation; hashes identify bytes and must include their algorithm. Sensitive strings and token materials are never stored without an appropriate protected storage design. ```sql PRAGMA foreign_keys = ON; CREATE TABLE workspaces ( id TEXT PRIMARY KEY, root_path TEXT NOT NULL UNIQUE, display_name TEXT NOT NULL, manifest_version INTEGER NOT NULL DEFAULT 1, created_at TEXT NOT NULL, updated_at TEXT NOT NULL, status TEXT NOT NULL CHECK (status IN ('active','paused','missing','archived')) ); CREATE TABLE objects ( id TEXT PRIMARY KEY, workspace_id TEXT NOT NULL REFERENCES workspaces(id), kind TEXT NOT NULL, state TEXT NOT NULL, current_version_id TEXT, created_at TEXT NOT NULL, updated_at TEXT NOT NULL ); CREATE TABLE object_paths ( id INTEGER PRIMARY KEY, object_id TEXT NOT NULL REFERENCES objects(id), rel_path TEXT NOT NULL, valid_from TEXT NOT NULL, valid_until TEXT, UNIQUE(object_id, rel_path, valid_from) ); CREATE TABLE object_versions ( id TEXT PRIMARY KEY, object_id TEXT NOT NULL REFERENCES objects(id), content_sha256 TEXT, size_bytes INTEGER, observed_mtime TEXT, catalog_seq INTEGER NOT NULL, extractor_version TEXT, created_at TEXT NOT NULL ); CREATE TABLE graph_edges ( id TEXT PRIMARY KEY, workspace_id TEXT NOT NULL REFERENCES workspaces(id), src_id TEXT NOT NULL REFERENCES objects(id), dst_id TEXT NOT NULL REFERENCES objects(id), predicate TEXT NOT NULL, provenance_id TEXT NOT NULL, status TEXT NOT NULL, confidence REAL CHECK(confidence BETWEEN 0 AND 1) ); CREATE TABLE audit_events ( seq INTEGER PRIMARY KEY AUTOINCREMENT, timestamp TEXT NOT NULL, actor_id TEXT, workspace_id TEXT, operation TEXT NOT NULL, decision TEXT NOT NULL, request_id TEXT NOT NULL, payload_digest TEXT NOT NULL, previous_digest TEXT, event_digest TEXT NOT NULL ); CREATE VIRTUAL TABLE search_fts USING fts5( object_id UNINDEXED, version_id UNINDEXED, title, body, tokenize='unicode61' ); CREATE INDEX object_paths_current_idx ON object_paths(rel_path) WHERE valid_until IS NULL; CREATE INDEX graph_src_predicate_idx ON graph_edges(src_id,predicate,status); ``` Treat the hash chain as tamper-evidence, not tamper-proof security; a privileged local attacker who controls both data and signing keys can forge state. For stronger attestations, export periodic signed audit checkpoints to a distinct trust location. Separate ledger operations from user-visible search logs to avoid overcollecting private query text. ## 19. Knowledge graph model, edge semantics, and evidence The knowledge graph is a local projection over registered objects, structured entities, relationships, and justified claims. Node types include Workspace, Directory, File, Document, Dataset, Record, PersonReference, OrganizationReference, Concept, Task, Capability, Skill, AgentDescriptor, API, Endpoint, Artifact, Event, and Evidence. Not every node points to a physical file; conceptual nodes must have a stable namespace and evidence record. Structural edges include `CONTAINS`, `LOCATED_AT`, `VERSION_OF`, `GENERATED_FROM`, and `LINKS_TO`. Semantic edges include `REFERENCES`, `DEPENDS_ON`, `DESCRIBES`, `MENTIONS`, `CONTRADICTS`, `SUPERSEDES`, `OWNED_BY`, and `REQUIRES_REVIEW`. Each edge has explicit `source`, `target`, `predicate`, `valid_from`, `valid_to`, `observed_at`, `asserted_by`, `evidence_refs`, `confidence`, `verification_status`, `extraction_method`, and optional `supersedes_edge_id`. Structural edges observed directly from files are not placed in the same authority class as relationships guessed by a model. When relationships conflict, both claims may be retained with source attribution; the graph should not choose a winner solely because one assertion has higher model confidence. The graph API must support typed traversal with depth and node-count budgets; cursor-based pagination; permission-aware filtering; evidence inspection; diff between snapshots; and export as a documented JSON graph structure. Start with relational adjacency tables and recursive CTEs. Do not introduce a separate graph database merely because a graph UI exists; only add a new storage engine after performance evidence and a recoverable migration plan prove its value. ## 20. Claims, verification, uncertainty, and epistemic labels An evidence item is an observable source anchor: file version, page number, line span, row range, DOM selector, code symbol, or signed receipt. A claim is a statement derived from one or more evidence items with a claim author, interpretation method, model/extractor version, time, and confidence. A decision is a recorded act by an authorized subject, not an information extraction. An outcome is an observed subsequent fact linked to the decision or task. These are distinct tables and UI badges so users do not confuse predictions with verified facts. Confidence belongs to the method and the domain. A probabilistic estimate must specify calibration dataset, sample size, population assumptions, validation date, and error statistics if it is presented as a meaningful probability. Otherwise use descriptive labels such as `suggestion`, `unverified`, `conflicting`, and `verified_by_rule`. Graph queries must permit filtering out speculative edges. A generated narrative that cites a document should link directly to its exact source version, not merely to the current file path. Review workflows have clear outcomes: accept with scope, reject with rationale, request more evidence, supersede, or mark obsolete. Review records are append-only; accepted claims can later be challenged. An operator can reconstruct why a relationship appeared at a given time, which source was used, which actor approved it, and whether the source remains available. ## 21. Full-text search, facets, ranking, and permission filtering Default search is lexical, local, deterministic, and fast. Use FTS5 with normalized extracted text, title boosts, metadata facets, path proximity, recentness as an optional transparent signal, and explicit query parsing. Return paginated results with stable object IDs, current/version path, snippets, source offsets, index freshness, extraction state, and permission-derived visibility. Do not use a model call for ordinary search. Respect the query's workspace scope before ranking; never fetch forbidden results and merely hide them after text extraction or snippet generation. Support exact phrase, prefix, fielded path/title/type queries, tags, modified time, entity, relationship type, and state filters. Search syntax errors should return the offending token and a safe suggestion. FTS tokenization must be validated for CJK content, diacritics, code identifiers, file names, long tokens, and privacy-sensitive exact strings. Store enough normalized context to provide meaningful excerpts without copying entire giant documents into API results. Measure relevance with a hand-labeled query set covering known-item retrieval, exploratory research, code references, OCR content, and duplicate documents. Record mean reciprocal rank, recall at 10, median latency, zero-result rate, and permission leakage tests. Search algorithm changes are versioned and evaluated against the same fixtures before rollout. ## 22. Optional embeddings and hybrid retrieval Embeddings may improve semantic discovery but are an **opt-in derived index**, never a required authority. The embedding pipeline takes already authorized, already extracted text; creates size-bounded chunks with offsets; records model identity, tokenizer, language, dimensionality, chunking strategy, source object/version, and generation timestamp; then stores vectors in a replaceable local index. API responses expose whether a hit came from lexical, semantic, structural graph, or blended ranking. The initial hybrid strategy should use lexical recall plus semantic candidates and reciprocal rank fusion or another documented blend, followed by deduplication and authorized evidence expansion. Keep deterministic tests for ranking tie-breakers, stale embeddings, deleted source versions, and access-policy changes. Permission revocation invalidates cached context and search result eligibility immediately; vectors must not become a separate uncontrolled retrieval path. Cost controls include maximum daily tokens, per-workspace byte caps, device CPU/GPU quotas, concurrency limits, eviction, and a button to rebuild or remove all embeddings. The user can disable embedding and still retain every original document and the conventional catalog. Embedding caches must not be included in portable exports by default unless the export explicitly calls for them and checks redistribution rights. ## 23. Context assembly, scope inheritance, and budget control Context is a **constructed view** of governed evidence, not a dump of an entire folder tree. The context assembler receives authenticated subject, workspace scope, task intent, allowed object classes, freshness requirement, token/byte budget, depth, and requested output form. It identifies candidate objects, filters by permissions before reading content, orders evidence, removes redundancy, summarizes only when authorized, and returns a manifest of included and excluded sources. Include object IDs, version digests, offsets, generator versions, and links for citation verification. Use a seven-level resolution model: installation policy → profile policy → workspace policy → ancestor directory policy → target directory policy → target object metadata → request-specific constraints. This is a **logical precedence model**, not seven separate authentication grants. A more restrictive rule at any relevant level wins for access decisions. User intent and context size can select *less* information, never expand an actor's maximum scope. Directory inheritance may carry templates and metadata but must not automatically import the sensitive content of a parent into a child. Generate context in named modes: `orientation`, `overview`, `evidence`, `engineering`, `task`, `review`, and `audit`. Each mode has a stable output schema. For example `engineering` favors readme, build manifests, relevant code symbols, tests, architectural decisions, and current errors, while `audit` favors decisions, approvals, receipts, and signed snapshots. A context packet includes `budget_requested`, `budget_used`, `truncated`, `freshness`, and `omission_reasons` so clients know what they did not receive. ## 24. Knowledge graph lifecycle and consistency reconciliation Reconciliation is a repeatable process with five passes. First, enumerate current filesystem objects and compare to last observations. Second, resolve identities and content-version changes. Third, invalidate changed extractive and semantic projections. Fourth, rebuild derived edges and FTS entries in bounded transactions. Fifth, publish graph/catalog version and change events when all essential assertions for that version are committed. A generation failure must not leave a graph that reports itself fully current when half the source updates were never examined. Use a monotonic catalog sequence and per-workspace high-water marks. Snapshot requests can choose `eventually_current` for speed or `source_verified` for a bounded fresh scan. If the fresh scan cannot complete within a specified deadline, return a partial state with explicit omissions rather than silently falling back. Include a `reconcile --dry-run` CLI that estimates file reads, bytes, parser work, graph deltas, and likely generated artifacts. Maintain a repair command that compares catalog references with actual directory entries, checks orphaned edges and FTS rows, verifies digests of derived artifacts, and proposes safe corrections. Repair must be transactional and auditable, with a default dry-run. Invariant checks should run automatically after unclean shutdown, interrupted migration, and snapshot restore. --- # PART D — INTERFACE DESIGN, HUMAN UX, AND ACCESSIBLE PRESENTATION ## 25. Information architecture and primary application surfaces The UI has six permanent zones: **Workspaces** (root selector and nested tree), **Explore** (directory/homepage browsing), **Search** (cross-document discovery), **Graph** (relationships and evidence), **Activity** (changes, jobs, reviews, audit), and **Settings** (scopes, capabilities, integrations, backup, health). Secondary panels include Files, Tags, Collections, Tasks, Agent Access, Developer Tools, Snapshots, and Diagnostic Center. Advanced functions are revealed according to permission and user preference. Every route can be opened directly by URL and has a meaningful title and breadcrumb. The default workspace landing page contains context before controls: name, location alias, health/freshness, short purpose, child folders, recently changed objects, high-value documents, unresolved reviews, and quick actions. Empty states provide a real next step, not a fictional metric. The file view displays accessible previews where supported, a safe download/open-on-disk action, observed metadata, versions, source provenance, related edges, and agent-accessible resource reference. The graph view provides an alternative accessible table/list representation. The user may pin views, choose layouts, and create local saved searches. These preferences are local state unless explicitly exported. Broken paths must degrade to a searchable object ID with a moved/deleted explanation, never a blank screen. Long-running operations return task IDs and a durable activity entry, not an unbounded browser loading indicator. ## 26. Design language, brand identity, and visual system The intended visual character is calm, technical, architectural, premium, and restrained. Avoid generic glowing AI motifs, decorative cyberpunk, and a simplistic padlock-only identity. The visual concept is a protected nested workspace: folder/frame geometry, linked context, strong alignments, and clear distinction between source, generated, and proposed material. Use a high-contrast dark default with an accessible light theme, subtle slate/graphite foundations, restrained cool-blue accents, typography suited to code and editorial reading, and consistent component spacing. Provide a full design-token specification: foreground/background colors, border levels, focus color, selection, text hierarchy, positive/warning/danger semantics, radii, elevation, grid, motion, breakpoints, icon sizes, and type scale. Do not use color alone to communicate authorization, validity, sync state, or verification. Reserve intense colors for meaningful focus and urgent actions. Audit color contrast against WCAG 2.2 AA targets for text and actionable components; support reduced motion and system font scaling. Every screen must be usable by keyboard alone. Assets required: primary logotype, compact icon, monochrome mark, favicon set, PWA icons and maskable icon, application icon, document preview/logo-safe variants, social sharing image for public docs, and a tiny fallback SVG. Bundle offline application assets locally. Use content-security restrictions and no remote asset dependencies in local mode; a privacy-first workspace should never unexpectedly fetch marketing pixels from a third party while showing local data. ## 27. HTML/HTMX rendering architecture Render meaningful pages on the server using Go templates. HTMX responses should normally return HTML fragments with explicit target IDs and content negotiation; full page routes should remain navigable without JavaScript. Use progressive enhancement for filtering, modal dialogs, tabs, quick edits, pagination, inline approvals, and long-running job status. On error, return semantic HTTP status and a readable, accessible fragment. Avoid competing client-side state stores when the server already owns the true state. For a file list, the initial GET returns a table/list and filter form; an HTMX request carries the same query parameters to an `/fragments/files` endpoint; the server applies policy, validates filters, queries the catalog, renders a new fragment, and includes a cursor. If a result is stale, annotate the freshness rather than painting it as current. For mutating HTMX requests, the handler must check identity, CSRF/Origin, explicit capability, expected version, and idempotency key before any write. Template partials are versioned and testable independently. Unsafe strings are never inserted into HTML as trusted HTML. Sandboxed preview iframes are required for active user-authored HTML. A local page should not be able to invoke privileged server actions merely because it was loaded from a workspace. Tests cover XSS, event-handler injection, URL schemes, invalid form state, broken focus after fragment swaps, and color contrast. ## 28. Offline browser and PWA behavior A Progressive Web App can provide home-screen installation, a shell cache, navigation fallback, local preferences, and offline status. The service worker must **not** automatically cache private documents, access tokens, searchable content, or API responses indiscriminately. Default cache scope is application assets and deliberately public documentation. Any offline private content cache requires explicit per-workspace opt-in, encryption/key-handling design, quotas, and visible deletion controls. The PWA cannot replace the local daemon or gain permission to read the user's filesystem beyond the browser's granted capabilities. PWA routes, manifest, icons, update handling, install prompts, accessibility, and device viewport behavior should be tested on the supported browser matrix. Cache version changes must be atomic and must not serve an HTML shell incompatible with the current API. Offline screens distinguish `daemon unavailable`, `network unavailable`, `credential expired`, and `workspace missing`. For an installed local PWA, provide a link or documented action to start the daemon, but never silently elevate or launch privileged processes through a browser exploit. ## 29. Native desktop packaging and operating-system behavior Optional platform-native wrappers may supply a menu-bar/tray launcher, workspace picker, dock icon, update alerts, system notifications, deep links, and OS-managed credentials. They are **shells around the same Intralock daemon and domain APIs**, not an independent storage engine. The server-rendered UI and CLI remain the portability baseline. Desktop packaging should use signed and notarized binaries where applicable, ordinary uninstall behavior, documented application-data paths, and a no-surprise retention policy for user data. OS dialogs that open or reveal files must validate the selected workspace and display the filesystem-native location clearly. A system service launch mode must not run with broader filesystem privileges than required. Support application sleep/wake, volume mount/unmount, network changes, laptop power constraints, and permission revocation. When a removable volume disappears, mark the workspace unavailable but preserve its identity and history until the user confirms removal. ## 30. Public documentation website and in-product developer portal Intralock needs a public documentation site and a local developer console, but the two must not leak private data across their boundary. Documentation pages include semantic titles, descriptions, accessible navigation, version indicators, code examples, change logs, public API references, privacy/security policy, FAQ, a sitemap, robots rules, appropriate structured metadata, and an `llms.txt` guide if deployed publicly. The public website can include a copyable agent-onboarding guide, but that guide must say that the agent still needs explicit authenticated access from the owner. The local developer console displays current protocol versions, enabled transport listeners, capability list, scope grants, API tokens (never full token values after creation), request logs with sensitive fields redacted, and conformance status. Provide Swagger UI or another OpenAPI renderer from a published `/openapi.json`, an optional GraphQL explorer disabled outside trusted local mode by default, MCP discovery instructions, code snippets, and versioned SDK examples. Public docs never embed a workspace's actual root path, local hostname, or personal object inventory. --- # PART E — AUTHORITY, CAPABILITIES, AGENTS, TASKS, AND WORKFLOWS ## 31. Identity types and the principal model Define distinct principals: local operator, additional local user, service account, agent instance, browser session, CLI client, MCP client, API client, task runner, and extension. These can belong to a common subject registry but must retain type, provenance, credential class, allowed scopes, expiration, and actor attribution. A client name or self-described agent card is not proof of identity. Authentication determines who is acting; authorization determines what that actor may do to the specific workspace/object at the current time. An `Actor` record includes stable ID, type, owner, disabled state, credential reference, creation/revocation timestamps, and optional human accountability link. A `RequestContext` includes actor ID, credential/session binding, trusted transport, workspace ID, object scope, operation, correlation ID, time, and relevant environment facts. Agents do not inherit every permission of the human who launched them. Delegation grants a bounded subset, a time limit, purpose constraints, and may require human approval before execution. Local operator mode may support OS-authenticated startup and a local short-lived session. Remote access MUST use authenticated TLS and scoped tokens or standards-aligned OAuth as appropriate. Do not persist bearer credentials in `AGENTS.md`, a workspace manifest, browser local storage, or public logs. Store secret material in an OS credential store or a protected encrypted key store where the platform supports it; make recovery and key rotation explicit. ## 32. Permission and policy engine: deny by default Represent authorization as a tuple: `(subject, action, resource, context) → allow/deny/approval_required`. Resource identifiers include workspace, object, folder subtree, graph edge, context bundle, task, skill, tool, API route, external listener, and export. Actions include `discover`, `list`, `read_metadata`, `read_content`, `search`, `read_graph`, `propose`, `create`, `update`, `delete`, `execute`, `approve`, `export`, `share`, `manage_policy`, and `manage_credentials`. A policy decision is evaluated on the server at the moment of execution, not accepted from client-provided hints. Role-based permissions simplify common personas; attribute-based rules handle scope, sensitivity, network origin, time, tool risk, and operation arguments. Fine-grained grants may restrict a credential to a read-only subtree, a document class, a specific context mode, or a narrow set of tools. A policy compiler produces an inspectable effective-permissions report with deny explanations. Reject ambiguous scope strings, parent traversal, unregistered workspaces, and identity mismatches. Policy files are configuration inputs requiring authorized application, not magical self-enforcing text. A high-impact action returns `approval_required` with a structured review package: exact requested operation, affected object versions, rationale, possible side effects, proposed changes, expiration time, and audit ID. Approval must be bound to a content hash or exact arguments so an agent cannot change the action after consent. A revoked grant cancels future steps, but does not retroactively undo a completed operation; recovery remains explicit. ## 33. Capability registry and interface parity A capability is a typed declaration of an actual domain operation, not a marketing claim. Registry entries specify machine name, semantic version, description, inputs/outputs as JSON Schema 2020-12, read/write risk, minimum permission, workspace/object applicability, side effects, idempotency, timeout, quota, stability, supported surfaces, and examples. The registry is the single source used to derive REST operation descriptions, MCP tool schemas, WebMCP registered tools, CLI help, SDK method metadata, and developer documentation where mapping is safe. For example, the domain capability `workspace.search` takes workspace ID, query, filters, and pagination. It maps to `GET /api/v1/search`, an MCP tool named `intralock_search`, a read-only browser WebMCP tool for the current page, `intralock search`, and SDK `search()`. Every path calls `SearchService.Search` with a common authorization decision. A capability change triggers compatibility tests for every exposed adapter. If one interface cannot faithfully represent a complex operation, it declares unsupported rather than inventing a semantically different implementation under the same name. Maintain a conformance matrix with columns for `domain`, `UI`, `REST`, `GraphQL`, `MCP`, `WebMCP`, `CLI`, `SDK`, `PWA`, and tests. The matrix must distinguish **not implemented**, **implemented**, **versioned**, **policy tested**, and **interop tested**. Capability listings are permission-filtered by server-side policy; a browser may discover that search exists without being given unrestricted search access. ## 34. Internal task engine, jobs, and work orders Distinguish a **job** (background unit of computation), a **task** (user/agent-visible durable objective), and a **work order** (approved specification of permitted mutations). A job runs extraction or indexing; a task can coordinate multiple jobs and approvals; a work order contains exact intended changes and verification. A task has a state machine such as `queued → running → input_required → running → completed|failed|cancelled`; terminal transitions are idempotent and audited. Input-required steps must not block a worker thread indefinitely. A work order contains scope, actor, goals, affected objects, read/write intents, precondition hashes, planned operations, risk, budget, resource caps, sandbox needs, tests, approval requirements, expiry, and rollback procedure. A bounded executor checks permissions before every step and again when the source version changes. Any mismatch yields a reviewable conflict rather than a silent best-effort merge. Maintain a durable event stream with strictly ordered task versions, not just an opaque free-form log. Resource budgets include disk, memory, CPU, time, network access, model tokens if enabled, maximum mutations, and allowed tool calls. Workers renew time-limited leases and checkpoint progress; after a crash, a new worker may safely resume using idempotent steps and reconciled receipts. Cancellation is cooperative and must prevent future writes, while reporting any partial effects already completed. ## 35. Optional AI augmentation and deterministic validation The Intralock core is intentionally not an autonomous model by default. Optional model adapters may produce classifications, summaries, candidate relationships, candidate tags, extraction repairs, contextual answers, interface proposals, and code-change work orders. Every AI invocation goes through a replaceable adapter contract carrying model identity, input hash, context scope, data disclosure destination, token/latency budget, output schema, cancellation, and policy. No AI dependency may be imported into the core file scanner or permission evaluator. Generated responses are proposals. Validate syntax, schema, paths, referenced object IDs, evidence, policy, test results, and mutation preconditions with deterministic code. A numeric quality score may triage review, but it is not sufficient to authorize a destructive write or claim correctness. Capture the instructions version, allowed context manifest, model/provider metadata, tool invocations, structured result, evaluator outcome, and final human disposition in a trace ledger subject to explicit retention and privacy controls. An optional software-construction workflow follows **Specification → Work Order → Sandboxed Build → Tests → Independent Review → Approval → Release → Deployment → Monitoring**. At each step, store artifact hashes and explicit acceptance tests. Do not execute newly discovered repository scripts, arbitrary document examples, or model-generated shell commands in the daemon's privileged process. Testing and review may be automated to propose a release, but the governed release policy decides whether publication is allowed. --- # PART F — MCP, WEBMCP, REST, GRAPHQL, CLI, SDK, AND AGENT INTEROPERABILITY ## 36. MCP architecture and the version boundary The Model Context Protocol server is a **capability adapter** over Intralock domain services. It does not implement a second object database or permission engine. The primary wire compatibility target is published MCP specification `2026-07-28`. This revision is stateless: requests are self-describing; `server/discover` can advertise capabilities; protocol-level `initialize` handshakes and `Mcp-Session-Id` are removed for the modern era. HTTP requests include routing/version metadata in documented headers and client metadata in `_meta`; the service validates headers against the body and does not treat self-reported client names as authentication. Consult the exact published schema and official SDK for required fields; examples here illustrate architecture, not a byte-for-byte conformance fixture. The local daemon supports stdio via `intralock mcp serve --transport stdio` and Streamable HTTP at `/mcp` when deliberately enabled. Standard local use must not expose the server to public interfaces. Client capability negotiation and authorization are distinct: a client may support tools, resources, or an extension while still being forbidden to access a particular workspace. Catalog operations such as `tools/list` must return deterministic order and applicable cache metadata with user-scope safety. No cross-user metadata is cached under a shared key. Create compatibility adapters for older MCP eras only when interoperating with known clients. The adapters translate legacy handshake, session-related behavior, and old feature capabilities into the canonical domain services. Do not implement old session semantics in the core runtime. Record client version, negotiated extension set, authentication subject, and tool outcomes in sanitized telemetry. Include protocol-version and schema fixtures in CI so an SDK upgrade cannot silently change a tool contract. ## 37. MCP tools: naming, schemas, risk, and result conventions Intralock MCP tools should be narrow, self-descriptive, and stable. The initial catalog uses names such as `intralock_workspace_list`, `intralock_workspace_inspect`, `intralock_object_get`, `intralock_object_read`, `intralock_search`, `intralock_graph_query`, `intralock_context_bundle`, `intralock_index_status`, `intralock_snapshot_verify`, `intralock_change_preview`, `intralock_change_apply`, `intralock_task_start`, `intralock_task_get`, `intralock_task_cancel`, `intralock_skill_list`, and `intralock_capability_list`. The exact set is governed by the capability registry and MCP version compatibility matrix; a tool listing must not imply permissions that the caller lacks. Each tool specifies JSON Schema 2020-12 input and output contracts, validation rules, read/write hints where applicable, expected latency, side effects, maximum response size, and possible error codes. Prefer stable IDs over path strings. Use typed pagination cursors and version preconditions. Tool outputs include content representations appropriate to the protocol, optional structured results, source references, catalog freshness, and a domain error object when needed. Never leak source filesystem absolute paths to a caller limited to logical workspace access unless that permission is explicitly granted. Tool annotations are hints to clients, not enforcement. A model may ignore a `readOnlyHint`; the server must not. A destructive tool should normally create a preview or approval request and complete only after an approved work order has been bound to exact arguments. Limit the number of tools exposed at once by profile and scope to reduce agent confusion and attack surface. Include examples of valid, invalid, stale, unauthorized, cancelled, and partial results in the developer reference. ## 38. MCP resources, templates, and provenance Resources provide addressable readable context without inventing a new protocol. Resource URIs should use an `intralock://` scheme with stable logical IDs, for example `intralock://workspace/{id}/overview`, `intralock://workspace/{id}/object/{objectId}`, `intralock://workspace/{id}/graph`, `intralock://workspace/{id}/snapshot/{snapshotId}`, and `intralock://workspace/{id}/skills/{skillId}/SKILL.md`. Dynamic selectors may use resource templates when supported; validate all URI parameters and pagination. A resource read always checks the current actor, scope, object version, and budget. Separate source-file resources, derived extraction resources, and generated summaries. Resource descriptions disclose whether they are authoritative, derived, or proposed. HTML, Markdown, plain text, JSON, and binary representations must use accurate MIME metadata. Content potentially containing prompt injection or personal information is explicitly classified as untrusted source material. Resource updates and stale cache invalidation follow the applicable MCP revision and negotiated capabilities, not hardcoded assumptions from older notification or subscription models. Return handles to very large content rather than embedding entire files in one tool result. Support bounded ranges and reproducible context packets. A resource URI is a locator, not a bearer credential: possession of the URI alone never authorizes reading it. The same object must be protected consistently through direct file routes, graph queries, and search snippets. ## 39. MCP prompts and structured reusable workflows MCP prompts are curated templates for asking a compliant agent to perform legitimate tasks with limited context. Recommended prompts include `orient_workspace`, `summarize_changes`, `review_unindexed_content`, `trace_dependency`, `compare_versions`, `prepare_context_bundle`, `audit_snapshot`, `propose_homepage`, `explain_search_result`, and `draft_work_order`. Prompts may specify arguments, suggested resource reads, result format, review rules, and output citations. They cannot override system policy or authorize tool calls. Maintain prompt versions separately from executable skills. Each prompt gets a documented scope and test cases for missing resources, ambiguous identities, malicious source instructions, sensitive-content exclusions, and hallucinated citations. Where old protocol clients represent prompts differently, compatibility code can map them without altering the domain. A prompt library should be inspectable as ordinary files and can be exported without private workspace text. Prompts should not instruct clients to ask for all available files by default. Default examples favor least privilege: request a workspace overview, discover relevant items, then retrieve the smallest necessary context. Explain how to cite sources using stable object IDs and version hashes. Provide a clear pattern for a user-approval handoff when the suggested workflow transitions from reading to writing. ## 40. MCP Tasks extension and asynchronous operations In the modern MCP baseline, durable Tasks are an extension, not a guaranteed feature of every host. Intralock should support `io.modelcontextprotocol/tasks` when negotiated and map task state onto its own durable task ledger. Implement the exact extension methods and transitions from the selected stable specification; the domain model remains independent so REST and CLI can access the same tasks even when an MCP client does not support the extension. Do not claim that all MCP clients can poll or update a task. An indexing refresh, large export, graph rebuild, multi-file context extraction, or approved work order can return a durable task identifier and status. Task metadata records actor and scope binding, idempotency key, creation time, expiry, status, progress, costs/resources, outcome digest, and safe result references. Polling is rate-limited and returns a stable status until the next transition. Updates and cancellations must check that the caller remains authorized; no task ID is treated as sufficient authorization. Multi Round-Trip Requests in the modern MCP core can handle missing input or approval interactions, but Intralock must never assume a model-host can represent an approval UI safely. If the client cannot support the input request, return a review URL or structured pending state that requires a human to use an authenticated application surface. A task that is cancelled or revoked cannot continue issuing writes from a stale queue lease. ## 41. MCP Apps and interactive `ui://` views MCP Apps are a separately negotiated official extension for interactive views delivered by MCP servers. A tool can reference a predeclared `ui://` resource with the appropriate UI MIME profile; hosts render it in a sandboxed environment and exchange permitted messages. Intralock can expose document browsers, task review panels, graph views, search filters, snapshot diff viewers, and approval forms. Each UI view must have a strictly defined message contract and a graceful text-only fallback for hosts without MCP Apps support. Never assume an embedded UI iframe has the same origin, credentials, or privileges as Intralock's trusted local application shell. Treat messages, display text, and tool arguments as untrusted. The host-sandbox communication must not bypass the capability registry. Approval screens should re-fetch the authoritative pending work order and show exact versioned changes before accepting; a UI message of `approved` alone is not authority. Keep layout accessible, keyboard operable, responsive, and compact enough for conversation hosts. UI resources must be versioned, tied to a capability, tested against the sandbox model, and protected by a restrictive content security policy. Avoid remote scripts, unnecessary network communication, and resource access beyond the negotiated host. A host without MCP Apps still receives typed content and ordinary action links that reveal no unauthorized data. ## 42. Skills over MCP, local skills, and the execution distinction The Skills over MCP extension `io.modelcontextprotocol/skills` allows servers to publish skill directories with a `SKILL.md`, using the extension contract compatible with the modern MCP revision. Intralock also supports local on-disk skills independent of MCP. The same skill descriptor can be exported through approved surfaces after versioning, hashing, validation, and permission filtering. A skill directory may include reference schemas, examples, tests, templates, and bounded helper scripts; not every file in such a directory is executable by default. A skill descriptor should include `name`, `version`, `purpose`, `trigger`, `inputs`, `outputs`, `permission_requirements`, `allowed_capabilities`, `risk_level`, `prerequisites`, `SOP`, `verification`, `rollback`, `license`, `owner`, and `digest`. Documentation describes intent while the capability registry and policy engine authorize actual operations. A skill cannot register a privileged tool merely by declaring it in Markdown. Executable portions require explicit trusted packaging, reviewed dependencies, and sandbox permissions. Skill discovery should rank relevance using capability semantics and workspace context, but not expose restricted skills. Compatibility tests verify URI addressability, content integrity, schema validity, and graceful behavior when clients do not support this extension. The interface should show skill status as `available`, `requires_permission`, `disabled`, `outdated`, or `not_compatible` rather than implying that every declared skill is runnable. ## 43. WebMCP progressive enhancement in the browser WebMCP is a browser-side Community Group draft, separate from backend MCP. Its tools live in a browser document and typically use `document.modelContext` in current Chromium experimentation; some examples and testing tools may still reference older `navigator.modelContext` naming. The implementation must feature-detect against the selected supported draft and browser version, not assume universal availability. The browser page registers only capabilities relevant to its current visible context, such as `search_current_workspace`, `open_object`, `filter_file_list`, `inspect_graph_selection`, `prepare_export`, and `preview_change`. Two exposure styles may be implemented: the imperative JavaScript API for context-aware operations, and declarative HTML form annotations for ordinary form workflows. Neither browser tool is a privilege boundary. Tool execution should call the same authenticated HTTP domain endpoint as the corresponding human UI action, apply CSRF/Origin and session policy, validate input, and return typed results. Do not place access tokens, filesystem secrets, or privileged system commands in page JavaScript. Unsupported browsers simply show forms, links, and standard controls. High-risk actions must not be given a one-step browser tool that can delete, share, execute, or approve without an independent human-controlled confirmation. A browser agent may prepare a request or open an approval screen. The server checks the immutable approval package. Browser tests should cover absent API, tool registration/disposal on navigation, browser permission settings, duplicate tool names, form validation, changing scopes, and calls to a revoked session. ```javascript // Illustrative only: follow the tested draft's exact signature. if (document.modelContext?.registerTool) { document.modelContext.registerTool({ name: 'intralock_search_workspace', description: 'Search the workspace currently open in Intralock.', inputSchema: { type: 'object', properties: { query: { type: 'string', minLength: 1, maxLength: 500 } }, required: ['query'], additionalProperties: false }, async execute({query}) { const r = await fetch('/api/v1/search?query=' + encodeURIComponent(query), { credentials: 'same-origin', headers: {'Accept':'application/json'} }); if (!r.ok) throw new Error('Search unavailable or not permitted'); return await r.json(); }, annotations: {readOnlyHint: true} }); } ``` The backend must resolve the workspace from the trusted authenticated page/session or a validated selected ID, not from a browser-controlled hidden field alone. Treat the sample as conceptual pseudocode until the exact browser implementation is pinned and conformance tested. ## 44. REST API, OpenAPI, versioning, and error semantics The REST API is mounted at `/api/v1`, with resource paths based on logical IDs. Important routes include `GET /health`, `GET /api/v1/workspaces`, `POST /api/v1/workspaces`, `GET /api/v1/workspaces/{id}`, `GET /api/v1/objects/{id}`, `GET /api/v1/objects/{id}/content`, `GET /api/v1/search`, `POST /api/v1/context/bundles`, `POST /api/v1/graph/query`, `GET /api/v1/capabilities`, `GET /api/v1/tasks/{id}`, `POST /api/v1/tasks`, `POST /api/v1/changes/preview`, `POST /api/v1/changes/apply`, `POST /api/v1/backups`, and `GET /api/v1/audit`. Use method-appropriate verbs and semantic HTTP codes. OpenAPI 3.1 documents request/response JSON Schema, security schemes, error representations, pagination, idempotency headers, concurrency preconditions, rate limits, and examples. Unknown input fields should be rejected for security-sensitive mutations; read endpoints may be more liberal where documented. Return consistent problem details with `code`, `message`, `request_id`, optional `field_errors`, `retry_after`, `conflict_version`, and `approval_request_id`. Do not expose stack traces, root filesystem secrets, or policy internals in general-user responses. Version breaking changes by route or media type, document deprecations, and publish a machine-readable compatibility table. Use `ETag`/`If-Match` or equivalent stable revision tokens for writes, and idempotency keys for operations that may be retried after network failure. A direct source-file write endpoint should not be exposed before safe mutation and rollback procedures are complete. ```yaml openapi: 3.1.0 info: title: Intralock Local API version: 1.0.0 paths: /api/v1/search: get: operationId: searchWorkspace security: [{localSession: []}] parameters: - {name: query, in: query, required: true, schema: {type: string, minLength: 1}} - {name: workspace_id, in: query, required: true, schema: {type: string}} responses: '200': {description: Permission-filtered search results} '403': {description: Not authorized for this workspace} components: securitySchemes: localSession: {type: apiKey, in: cookie, name: intralock_session} ``` ## 45. GraphQL and query cost containment GraphQL is appropriate for structured clients exploring interconnected workspaces and typed graph relationships. It is **not** a backdoor around the domain authorization engine. Begin with read-only query types `Workspace`, `Object`, `Version`, `Edge`, `Evidence`, `Task`, `Capability`, `Snapshot`, and connection types for pagination. Mutations should call exactly the same preview/approval/apply services used by REST; clients cannot directly mutate arbitrary columns or graph edges. Implement query depth, field cost, result cardinality, and time budgets. Reject introspection outside authorized development contexts if exposure would reveal sensitive schema features; keep a safe schema distribution endpoint for legitimate SDK generation. Avoid unlimited recursive graph traversal or a broad `node(id)` resolver that ignores workspace scope. Data loaders should batch reads without losing per-object access checks. For subscriptions, require authorization at connection and event delivery time, bound event scope, and documented reconnect behavior. Define explicit behavior for partially unauthorized relationships: omit the hidden node and disclose bounded redaction metadata where doing so does not leak sensitive existence. Never return hidden node names, counts, or source snippets in errors. Test graph query bypasses with aliases, fragments, nested connections, and expensive queries. ## 46. CLI contract and shell ergonomics The CLI is an independently useful product interface, not a thin debug command. Representative commands: ```bash intralock init --workspace . --read-only intralock workspaces list intralock workspace inspect wks_... intralock index run --workspace wks_... --dry-run intralock index status --workspace wks_... intralock search "architecture" --workspace wks_... --json intralock graph neighbors obj_... --depth 2 intralock context bundle --workspace wks_... --mode engineering --max-tokens 6000 intralock homepage preview --workspace wks_... intralock homepage publish --workspace wks_... --approval apr_... intralock policies explain --actor agt_... --action read_content --object obj_... intralock capabilities list --format json intralock tasks list --state running intralock snapshot create --workspace wks_... intralock snapshot verify --workspace wks_... intralock backup create --target /safe/backup/location intralock doctor --full intralock mcp serve --transport stdio intralock server start --bind 127.0.0.1:8765 ``` Shell commands obey consistent global flags: `--workspace`, `--profile`, `--format`, `--json`, `--timeout`, `--quiet`, `--verbose`, `--dry-run`, `--yes` only where safe, `--expected-version`, and `--request-id`. A destructive `--yes` flag must never bypass mandatory policy approvals. Exit codes distinguish input error, policy denial, conflict, unavailable daemon, partial completion, and internal fault. JSON output is schema-versioned, contains no presentation ANSI sequences, and is suitable for pipelines. Progress goes to stderr so stdout remains parseable. ## 47. SDKs and typed developer experience Publish a first-party Go SDK early because it shares the core language and tooling. Add a TypeScript SDK for browsers and Node-compatible clients and a Python SDK for automation once the REST contract is stable. SDKs should be generated or checked against OpenAPI where suitable, but domain-level ergonomics may require carefully maintained wrapper methods. All SDKs implement authentication, retries limited to safe/idempotent operations, timeouts, pagination, cancellation, typed domain errors, expected-version preconditions, and streaming uploads/downloads without loading large files into memory. An SDK cannot evade policy by selecting a different transport. Expose `client.workspaces.list()`, `client.objects.get(id)`, `client.search.query()`, `client.context.bundle()`, `client.graph.neighbors()`, `client.tasks.watch()`, `client.changes.preview()`, and `client.changes.apply(approvedWorkOrder)` semantics consistently. Document where functions call REST versus MCP and why. Avoid hidden model invocations or remote calls from a supposedly local SDK method. Maintain compatibility tests that run the same fixture across Go, TypeScript, and Python versions. SDK packages ship examples, typed definitions, changelogs, security advisories, checksums, and protocol compatibility. Publishing a package does not constitute a stable API until it passes the public conformance suite. ## 48. Events, webhooks, SSE, and subscriptions The event system is an append-only local outbox of domain events, independent of the UI and protocol. Core event types include `workspace.registered`, `object.discovered`, `object.changed`, `object.moved`, `object.missing`, `extraction.completed`, `graph.updated`, `search.rebuilt`, `homepage.proposed`, `homepage.published`, `task.updated`, `approval.created`, `approval.resolved`, `policy.changed`, `snapshot.verified`, and `backup.completed`. Events have stable IDs, workspace scope, actor reference, type, schema version, timestamp, sequence, resource IDs, and redacted payloads. The application may provide authenticated SSE or WebSocket updates for UI activity, GraphQL subscriptions where implemented, and bounded local webhook delivery to explicitly approved destinations. Webhooks are disabled by default; never permit arbitrary callback URLs that can reach local metadata endpoints or private network resources without SSRF controls. Sign deliveries, implement retries and dead-letter inspection, and use monotonic cursor resumption. The event stream does not replace the source of truth: consumers must be able to reconcile by querying current state. Avoid coupling unrelated transports: MCP's notification/subscription mechanisms follow its own negotiated specification; WebMCP is browser tools; HTTP SSE is a conventional UI delivery mechanism; webhook requests are outgoing notifications. They all may derive from the same domain event ledger without pretending to share one wire format. ## 49. A2A, agent cards, ACP, AG-UI, and A2UI adapters Intralock's **required core** is governed content and capabilities, not a particular agent orchestration framework. An optional agent-to-agent adapter can publish an Agent Card and an A2A endpoint for specifically approved capabilities, while keeping direct file access behind the same authorization boundary. A2A tasks, messages, artifacts, and streaming are translated to internal work orders and task state. The card must advertise actual implemented skills and authentication requirements, not private documents or unimplemented actions. ACP-style agent/editor interoperability is a distinct optional adapter and must not be confused with internal access-control policy. AG-UI can stream agent runs and user-facing interaction events; A2UI can describe structured UI surfaces for a renderer. Neither message format grants an agent permission to mutate files. Render only allowlisted components; validate event shapes and HTML/text output; do not expose privileged internal reasoning as a telemetry feature. The simpler HTML/HTMX UI remains the functional baseline when adapters are absent. Each protocol has its own compatibility matrix, spec revision, test fixtures, dependency version, threat model, and enable/disable control. The capability registry can create a common map without forcing protocols into a false equivalence. Protocol adoption must be gated by actual client availability and a security review, not by a requirement to display a long integration list on the home page. ## 50. Agent onboarding, discovery, and copyable instructions An AI-native public and local entrypoint should display a clear **Copy Instructions for Your Agent** action. The copied text directs a permitted agent to a versioned Markdown onboarding page such as `/docs/agent-onboarding.md`, explains how to discover `/mcp` and `/openapi.json`, instructs it to authenticate through an owner-approved flow, and lists read-only initial operations. Copyable instructions do not contain live credentials. A machine-readable `/.well-known/` discovery manifest may advertise supported endpoints when the site is configured for discovery, but its exact path and schema must be documented as an Intralock convention unless a separate standard is implemented. The agent onboarding document should explain the workspace identity model, stable URIs, available transports, request budgets, rate limits, permissions, input validation, approval process, content trust boundary, tool error taxonomy, task lifecycle, evidence citations, and how to avoid unnecessary broad crawling. Documentation should also provide a human-readable one-click review path for adding or removing an agent credential. No agent should be forced to parse private `AGENTS.md` files before it can use the public API reference. The local in-app developer page should include **Copy Page**, **Copy API Example**, **Copy MCP Configuration**, and **Copy Agent Instructions** actions with accessible success feedback. Clipboard contents must be redacted when generated from a view that contains secrets. Public search engine metadata is useful for public documentation only; private workspace pages default to no indexing, no analytics pixels, and no external discoverability. --- # PART G — SECURITY, PRIVACY, DATA PROTECTION, AND SAFE EXECUTION ## 51. Threat model and explicit trust zones Intralock handles private local data and exposes it through multiple software boundaries; security must be designed before remote access or autonomous execution. Identify attacker classes: untrusted files, malicious embedded links, hostile workspace scripts, an unauthorized local process, a compromised browser extension, a stolen API token, a poorly designed third-party extension, a remote attacker against a mistakenly exposed port, a prompt-injecting document, and a privileged machine user who alters catalog files. Some threats cannot be fully eliminated by an unprivileged application; distinguish their limits transparently. Define zones: (A) operating-system files and user accounts; (B) Intralock daemon and protected catalog; (C) renderer and browser session; (D) extractor subprocesses; (E) optional model execution; (F) plugins and sandbox runners; (G) remotely connected authenticated clients. Crossing a zone requires validation and explicitly scoped authority. HTML content extracted from a file never arrives at the browser as trusted application code. Text emitted by an LLM never becomes a shell command. A locally running browser page does not inherit OS-level file read permissions because it can see a daemon URL. Produce data-flow diagrams for search, read, export, write, task execution, approval, and remote token exchange. Each diagram lists entrypoint, principal, authentication, authorization, validation, data accessed, logging, recoverability, and possible external disclosure. Threat reviews must cover both direct misuse and combinations of benign features that together create an escape route. ## 52. File traversal, symlinks, race conditions, and sandboxing Never authorize a filesystem request by concatenating a client-supplied path with an approved root. Convert logical object IDs to catalog entries, re-resolve root identity, normalize and validate paths, and use platform-specific secure open operations where available. Validate containment after symlink resolution; do not follow symlinks outside scope by default. Treat archive entries, extracted filenames, hard links, case folding, and Unicode confusables as possible traversal/collision sources. Check file identity immediately before writes to reduce time-of-check/time-of-use exposure. Untrusted parsers run in a constrained subprocess or another enforceable isolation boundary with a fixed temporary directory, no inherited secrets, bounded file descriptors, CPU/memory/time limits, output bytes, and no network by default. Scripts associated with scanned repositories or documents are never executed during indexing. If full OS sandboxing is unavailable, the feature must be disabled or labeled a reduced-assurance option, not falsely called sandboxed. Source writes should use a mutation service with named operations, explicit affected object IDs, expected digests, restricted destinations, preview receipts, and rollback copies where lawful and technically possible. Directory creation, rename, removal, executable launch, and external network calls are separate risk classes. High-risk deletion should normally move data to a protected recoverable area before permanent purge, while respecting explicit secure deletion and storage semantics. ## 53. Authentication, sessions, OAuth, and remote mode Local interactive browser sessions use secure, HTTP-only cookies with SameSite protections and anti-CSRF measures, appropriately scoped for loopback operation. Session lifetime, refresh, logout, and device trust must be documented. API tokens are random, high-entropy, narrowly scoped, rotatable, revocable, and displayed only once. Store a nonreversible token verifier or protected credential reference; avoid retaining raw tokens for convenience. Bind token grants to actor identity, workspace, allowed capability set, and expiration. Rate-limit failed authentication without allowing trivial denial-of-service. Remote MCP deployments should implement the authorization requirements of the selected protocol revision, including OAuth discovery and resource metadata where applicable, redirect URI and issuer validation, token audience restrictions, and client identity binding. The server must not accept a token intended for some other resource. Client self-declared metadata is informational only. Never expose an insecure loopback session endpoint directly to the Internet through a tunnel without a deliberate remote-authentication architecture. If a hosted or remote account feature is ever added, an email-verification and payment-verification gate can govern premium provisioning, but **local private operations must not be silently dependent on them**. Any billing state is separate from filesystem authority. A payment method is not a security credential. If API-key issuance is restricted to verified accounts, enforce the rule server-side on issuance and subsequent request authorization, with explicit error states and clear privacy terms. ## 54. Secret handling, encryption, retention, and minimization Classify protected information into credentials, private file content, derived excerpts, embeddings, workspace structure, identifiers, user activity, audit metadata, and telemetry. Each category receives a collection purpose, storage location, retention, export policy, and permitted exposure path. Avoid storing full document contents inside audit events. Logs should contain IDs, digests, status, duration, and redacted error types rather than arbitrary file snippets or bearer tokens. Store configuration separately from secrets. Encryption at rest relies first on operating-system full-disk protection and file permissions; optional application-level encryption requires a concrete key-management and recovery model. Do not claim an ordinary SQLite database is encrypted just because the app uses TLS. Backup encryption must be independently verifiable, with salt, KDF and algorithm metadata, key rotation plan, integrity checks, and a recovery rehearsal. Portable exports should be encrypted when they contain protected source content and should never accidentally include local tokens. Provide a retention dashboard with indexed content cache eviction, audit-event policy, task history, old revisions, snapshots, excluded files, and emergency purge options. Retention settings must not make audit evidence disappear before mandatory operational accountability windows when those windows apply. A “forget this indexed content” operation removes its derived data and pointers; it must explain that it does not delete the original file or other separately owned backups. ## 55. Prompt injection, untrusted content, and model-data disclosure The system must assume some documents contain instructions intended to manipulate agents, tools, or the operator. Treat all retrieved workspace content as data with source labels. Models must not receive credentials, hidden policy details, out-of-scope files, or arbitrary full-directory dumps. Create a context manifest before calling an optional model and compare the exact payload to the authorization decision. Reject model-generated requests for new credentials or scope escalation unless separately approved by a human. Detect and flag suspicious patterns as supporting signals, not as a guarantee of safety. Primary protection is architectural: no tool execution from content, server-side least privilege, bounded data disclosure, write approval, schema validation, and verification of effects. A document stating “ignore all previous instructions” may be displayed or quoted as evidence without granting it authority. The product must test cross-file attacks where one document attempts to cause the model to copy another private document into an export or browser URL. Maintain a model-call ledger containing consent status, actor, provider or local engine designation, operation, input references and hashes, output digest, model/version, token usage if known, timing, policy result, and retention settings. Capture sufficient trace to reproduce a decision without unnecessarily recording all confidential prompt text forever. A no-model/offline mode must make zero network calls for inference and provide diagnostic evidence of that fact. ## 56. Approval lifecycle and safe mutation protocol Approval has four separate objects: proposal, immutable preview, human decision, and execution receipt. A proposal expresses intent; a preview resolves exact current objects, diffs, preconditions, and expected side effects; a decision binds an identified approver to that preview hash; execution rechecks scope and versions and records the actual effects. If any material precondition changes, the approval becomes stale and the action returns to preview. Approval must not be a bare Boolean attached to a mutable task row. For multi-file changes, define atomicity expectations. A filesystem rarely offers a portable cross-file transaction, so use a write plan, staged files, journal, checkpoint, rollback references, and an explicit `partially_applied` state. Mutations that cannot be rolled back (external webhook, secure deletion, OS command) require prominent warnings. A work order should include a `max_effects` and `allowed_paths` constraint; authorization is rechecked for each actual effect. Duplicate retries must be detected by idempotency key and should return the prior receipt rather than applying the effect again. An operational incident workflow can freeze new writes, revoke agent grants, stop task runners, preserve audit evidence, recover from revisions, verify catalog consistency, and reopen in read-only mode. These controls should work without an AI assistant. --- # PART H — RELIABILITY, PERFORMANCE, OPERATIONS, AND DELIVERY ## 57. Backups, snapshots, restore, and disaster recovery A backup is a recoverable package containing the SQLite catalog snapshot, portable workspace manifests and accepted annotations, generated outputs where selected, metadata needed to link original files, and optionally user source content if explicitly selected. A snapshot is a point-in-time reference and may be **metadata-only**. The interface must clearly distinguish backing up Intralock's catalog from backing up the actual user files; restoring a catalog without original files cannot recreate those file bytes. The default backup procedure should produce an encrypted or otherwise appropriately protected artifact and a signed/checksummed manifest. Run SQLite's supported online backup mechanism or a verified consistent snapshot strategy, never just copy arbitrary live WAL files with uncertain consistency. Before backup, checkpoint or coordinate active tasks and record source-file coverage. After backup, verify hashes and attempt a test restore into an isolated location. Restore is a previewable operation that reports workspace path remapping, missing originals, schema migration, credential exclusions, conflicting IDs, and derived-cache rebuild cost. Set initial recovery targets by profile: personal local catalog recovery point of at most one day with configured scheduled backups, faster when change journaling is enabled; recovery time target measured against fixture size and actual device limits, not a universal promise. Do not purge the old catalog until the restored catalog passes integrity, graph, FTS, and sample-source verification. ## 58. Sync architecture as an opt-in future capability Synchronization is not required for the first standalone release. If added, model it as a versioned replication protocol that preserves local authority and offline operation. The local outbox records mutations and source observations with logical IDs, source version hashes, lineage, and tombstones. A remote peer authenticates, receives only authorized subsets, acknowledges operations, and reconciles revisions with explicit conflict preservation. Replication should support selective folder scopes, bandwidth constraints, resumable transfer, encryption in transit, and no automatic distribution of excluded sensitive content. Do not promise strongly consistent multi-master file editing without implementing conflict resolution suited to each file type. For binary files, preserve conflicting versions and request a user decision. For structured metadata, a merge can be attempted only where field semantics and authorship are known. A deletion tombstone has retention and acknowledgement rules so an offline peer does not unknowingly resurrect removed content. The local app keeps working during remote service outages and queues outbound work without blocking navigation. ## 59. Observability, diagnostics, and privacy-preserving telemetry Expose metrics for watcher latency, queue depth, extraction throughput, parse failures, catalog transaction times, FTS freshness, search latency, context assembly, task states, approval aging, policy denials, disk usage, backups, and protocol requests. Use structured internal logs with correlation IDs and trace context. OpenTelemetry is a suitable reference for optional traces and metrics, but exporters are disabled by default. A local diagnostics panel should show service health without making any network call. Define event severity and runbook links for disk nearly full, catalog corruption, watcher overflow, stale index, repeated extractor crash, failed backup, revoked token usage, unexpected remote bind, excessive graph query cost, and protocol incompatibility. A diagnostic bundle must redact credentials and private content by default and provide an operator preview before sharing. Telemetry consent is granular and revocable; local diagnostics are always available without remote reporting. Build a deterministic `doctor` command that checks database integrity, migrations, workspace permissions, filesystem availability, ACL consistency, resource budgets, bind address, TLS configuration, artifact digests, pending tasks, schema mismatches, and tool conformance. Doctor produces machine-readable status codes and human remediation instructions, not an unstructured panic log. ## 60. Performance budgets, capacity planning, and benchmarks Begin with measured targets rather than ungrounded universal claims. Recommended first-release acceptance gates on the defined reference fixture and test machine: initial shell response under 250 ms median locally after warm startup; ordinary metadata directory navigation under 300 ms p95 for representative views; FTS query under 500 ms p95 for a 100,000-object indexed corpus; policy checks under 10 ms p95 in-process; and no sustained unbounded memory growth during a 24-hour watcher test. These are **engineering targets**, not measured current performance. Benchmark dimensions must include 1k/10k/100k/1M filesystem entries, deep nested trees, millions of FTS tokens, large PDFs, text-heavy code repositories, removable media, low free disk, cold start, warm start, and repeated rapid renames. Record hardware, OS, filesystem, extraction settings, data corpus, CPU, RAM, storage type, and concurrency. Use memory and disk budgets per job so a single large archive cannot starve the UI. Throttle expensive extraction under low battery or high system load where platform APIs permit. The dominant scalability bottleneck may be parser throughput, directory traversal, FTS writes, thumbnails, graph joins, or user-facing rendering depending on corpus. Profile first, optimize second. Introduce separate worker processes or additional storage engines only when a reproducible benchmark shows the need. A memory-safe queue and resumable pipeline are more valuable than maximum concurrency with no backpressure. ## 61. Release engineering, signing, and software supply chain Build from pinned dependency versions with generated SBOM, license inventory, vulnerability scan, reproducible build instructions, static-analysis results, unit/integration test reports, protocol conformance results, and signed release artifacts. Each binary identifies build version, commit, schema version, protocol support, and enabled features. Plugins and extractors are reviewed as independent supply-chain components with explicit permissions and published provenance. A release must not silently switch a private installation into a telemetry-enabled or network-exposed profile. Use a staged channel strategy: development, nightly/internal, beta, release candidate, stable, and long-term maintenance if adoption justifies it. Upgrades perform preflight disk/backup checks and compatibility validation, then migrate with transaction/checkpoint logic. Rollback documentation explains when a catalog requires restoring a pre-upgrade backup. Critical security updates should not break offline access to existing files even if the daemon refuses to open a newer catalog. A trust ledger records release signatures, dependency digests, migration checksums, test results, and security advisories. If a third-party dependency becomes unmaintained or changes license, the build must flag it and an architectural decision must document replacement, vendoring with compliance, or risk acceptance. ## 62. Repository organization and development standards A single repository is recommended until stable interface boundaries justify splitting packages. Suggested top-level structure: ```text intralock/ cmd/intralock/ # CLI cmd/intralockd/ # daemon internal/ # domain implementations workspace/ object/ filesystem/ catalog/ watcher/ extract/ search/ graph/ context/ pages/ policy/ identity/ capability/ tasks/ workorders/ audit/ events/ pkg/sdk/go/ # public Go client api/openapi/ # OpenAPI source and schemas api/graphql/ # schema and generated adapters api/mcp/ # transport + conformance api/webmcp/ # feature-detected browser tools web/templates/ # Go HTML template hierarchy web/assets/ # CSS, JS, icons, PWA assets migrations/sqlite/ # versioned immutable migrations specs/ # architecture and contracts schemas/ # JSON Schema 2020-12 skills/ # internal and published skills examples/ # sample independent workspaces test/fixtures/ # deterministic corpora and attacks test/contract/ # interface parity fixtures test/security/ # authorization and traversal tests scripts/ # build/test/release tooling docs/ # user/operator/developer documentation .github/workflows/ # CI/CD AGENTS.md # repository guidance LICENSES/ # third-party notices CHANGELOG.md ``` Require small pull requests with traceable issue IDs, reviewable migration files, code ownership, architecture decision records for boundary changes, and tests for each bug class. Formatting and linting should be automated. A change to the `Capability` interface must trigger regenerated docs and adapter contract tests. Use semantic versioning for packages where practical, plus an independent schema version for stored data and explicit protocol revision labels. ## 63. Test pyramid, safety properties, and formal acceptance Unit tests validate path normalization, identity confidence, schema validation, ranking, hash computation, policy rules, document sanitization, task transitions, and diff ownership. Integration tests use temporary workspaces with real filesystem changes, SQLite transactions, and request adapters. End-to-end tests run a daemon, browser, CLI, and MCP client against isolated fixtures. Protocol tests validate modern and legacy negotiated behavior separately. Security tests attempt unauthorized operations and should fail closed. Property-based tests are especially valuable for arbitrary path names, directory depth, Unicode, rename sequences, crash/restart, generated-region merging, event deduplication, and query filters. Fuzz all public JSON parsers, archive extraction, URI resolvers, HTML generators, and manifest validators. Migration tests build old catalog versions and verify upgrade and recovery. Chaos tests kill workers during extraction, lose disk space during writes, unmount a volume, and revoke credentials halfway through a task. Each feature needs a positive test, denial test, stale-version test, partial/failure test, and audit-evidence test. Coverage percentage alone is insufficient. Release acceptance requires restoring a backup, verifying an offline run, proving no unauthorized files are read, and comparing domain outcomes across at least the UI, REST, and CLI surfaces; MCP/WebMCP/GraphQL parity applies when those adapters are declared supported. ## 64. Accessibility, localization, documentation, and support quality Accessibility is an architectural requirement for desktop web, PWA, MCP Apps, and developer docs. Use semantic headings, landmarks, visible focus, keyboard interaction, skip links, explicit form labels, errors tied to inputs, text alternatives for icons, non-color-only states, and live announcements for background task changes. Graph visualization must have an equivalent keyboard-accessible relation table. Approval dialogs must trap focus correctly and explain exact consequences, not just present a colored button. Localization should use externalized strings and ISO-aware date/number formatting without changing canonical IDs or machine schemas. Paths and filenames may be Unicode and must display in a way that protects against bidirectional text spoofing and invisible separators. Documentation should have beginner, operator, security, developer, protocol, and migration tracks. Every user-facing error links to a stable troubleshooting page or returns a machine-readable remediation code. Support bundles have privacy-safe defaults; diagnostics are locally inspectable. Documentation examples use fake paths and dummy credentials, never a real user's private files. A self-hosted local install must be operable using the written docs if all online support resources are unavailable. --- # PART I — OPERATING PROCEDURES AND BUILD PLAN ## 65. System-level standard operating procedures **SOP 01 — Register workspace:** verify root exists; check expected ownership; run exclusion preflight; estimate index size; create local registry entry; optionally preview managed files; request explicit permission before writing generated artifacts; start background observation; display readiness and freshness. Failure state leaves originals untouched and returns a reversible registration receipt. **SOP 02 — Reconcile filesystem:** acquire workspace lease; read journal checkpoint; scan bounded paths; compare fingerprints; resolve moves; mark ambiguous identities; enqueue changed versions; update catalog transactionally; publish reconciliation results; verify no unauthorized path was traversed; release lease. A missed notification triggers a scan rather than pretending no change occurred. **SOP 03 — Extract content:** resolve authorized object ID; enforce ignore/privacy rules; validate stable version; choose sandboxed extractor; run with budgets; validate normalized output; record offsets and errors; persist derived segments; update FTS and graph invalidation; emit receipt. Failure must not erase previously valid source observations until the new state is reconciled. **SOP 04 — Generate homepage:** compute source context; render virtual preview; verify ownership of target regions; create deterministic output; compare against base version; display diff; secure approval if needed; stage file; atomically publish; verify generated links; record hash, template version, source snapshot, and undo reference. **SOP 05 — Read through agent:** authenticate caller; resolve scope; evaluate policy; validate requested resource/capability; enforce token/byte budget; read current permitted source version; attach evidence manifest; redact sensitive fields; return structured result; record minimal audit metadata. Do not expand to neighboring workspaces as a convenience. **SOP 06 — Execute work order:** validate immutable preview and approval; recheck object preconditions and actor grants; allocate resource budget; create sandbox/rollback checkpoints; apply steps idempotently; run verification; publish receipts; close or mark partial; notify operator; preserve recovery details. **SOP 07 — Backup:** pause or coordinate incompatible writes; snapshot SQLite consistently; collect selected portable manifests and source files; encrypt if configured; compute manifest checksums; write to target; verify output; perform periodic restore rehearsal; record backup evidence without embedding keys. **SOP 08 — Recover:** isolate suspect catalog; revoke unnecessary writers; preserve forensic copies; select verified backup; restore to a separate path; validate database/graph/FTS integrity; remap paths; compare source versions; restart read-only; require approval before returning to write mode. **SOP 09 — Rotate credentials:** identify affected grants; create replacement secret; update trusted storage; revoke old credential; invalidate sessions and cached authorization; test that old token fails; record sanitized rotation event; avoid placing secrets in task outputs. **SOP 10 — Release update:** build and sign candidate; generate SBOM; run tests and threat review; inspect migration plan; create backup; deploy to canary fixture; validate health/performance; publish artifact; monitor errors; invoke rollback plan when gates fail. ## 66. Phase 0 — contracts, threat model, and non-destructive prototype **Stage 0.1 / Item 0.1.1:** freeze canonical object IDs, workspace manifest v1, policy action vocabulary, file ownership rules, and error taxonomy. **Item 0.1.2:** author architecture diagrams, public API principles, and permissions matrix. **Item 0.1.3:** prepare representative test corpora and a malicious-file fixture set. **Item 0.1.4:** establish repository rules, migration framework, CI, licensing, and security reporting. **Item 0.1.5:** write a no-data-loss recovery test. Build a read-only daemon that registers a root and lists files without writing into that root. Collect file metadata, handle Unicode and symbolic links safely, serve an offline HTML view, and demonstrate a clean uninstall without touched source files. The exit gate is intentionally narrow: no AI, no remote server, no generated homepage writes, and no claims of protocol completeness. This phase proves the hardest user-trust invariant before adding feature volume. ## 67. Phase 1 — catalog, watcher, extraction, and search **Stage 1.1:** implement SQLite migrations, workspace and object tables, IDs, path history, and observations. **Stage 1.2:** watcher with overflow detection, periodic scan, durable queue, and restart. **Stage 1.3:** extractors for text/Markdown/HTML/JSON/CSV/source and metadata-only fallback for all other files. **Stage 1.4:** FTS5 with facets, snippets, pagination, and permission filtering. **Stage 1.5:** diagnostics and repair. **Stage 1.6:** benchmark 1k to 100k file fixtures. Exit requires reproducible index builds, recovery from worker termination, no traversal outside scope, stable IDs across ordinary renames, no silent duplicate merge, deterministic FTS fixtures, and no changes to original content. A user must be able to select a directory and benefit immediately without advanced setup. ## 68. Phase 2 — homepages, lock snapshots, graph, and context **Stage 2.1:** virtual homepage and nested navigation. **Stage 2.2:** generated region ownership and three-way diff. **Stage 2.3:** `intralock.lock.html` with verifiable state and privacy-safe projection. **Stage 2.4:** portable manifest and AGENTS guidance. **Stage 2.5:** structural graph, provenance, and read-only relationship explorer. **Stage 2.6:** context packet assembler with filters, budgets, omissions, and stable citations. Release gate: an existing authored `index.html` survives onboarding; generation produces a preview/receipt; a manual edit to a generated region triggers conflict; a fresh lock snapshot validates; graph queries and context packets cannot reveal excluded files. Generated pages must remain meaningful as static HTML when the daemon is stopped. ## 69. Phase 3 — identity, governance, tasks, and safe writes **Stage 3.1:** actor registry and credential storage. **Stage 3.2:** role and attribute policy rules. **Stage 3.3:** capability registry with JSON Schema. **Stage 3.4:** durable jobs/tasks and event outbox. **Stage 3.5:** preview/apply work orders, approval binding, and rollback revisions. **Stage 3.6:** incident freeze and authorization debugging. **Stage 3.7:** full security test pass. Do not ship write-capable agent access before this phase. Exit requires authenticated principal scoping, denial tests for each domain action, revoked credential failure, stale hash rejection, duplicate retry idempotence, cross-file recovery where feasible, and proof that an instruction embedded in a source document cannot elevate permissions. ## 70. Phase 4 — multi-interface developer platform **Stage 4.1:** REST/OpenAPI 3.1 and interactive local docs. **Stage 4.2:** CLI with JSON output. **Stage 4.3:** Go SDK and sample clients. **Stage 4.4:** official Go MCP SDK adapter targeting `2026-07-28`; stdio first, authenticated HTTP next. **Stage 4.5:** resources/prompts/tools and extension negotiation. **Stage 4.6:** MCP Tasks, MCP Apps, and Skills extension with independent conformance. **Stage 4.7:** optional GraphQL API. **Stage 4.8:** browser WebMCP progressive enhancement and fallback. Exit requires documented conformance for each enabled surface, policy-equivalent outcomes between adapters, protocol negotiation tests, sandboxed MCP Apps views, durable task polling, and no assumption that a WebMCP experimental browser API exists in every supported browser. ## 71. Phase 5 — polish, backups, secure packaging, and stable release **Stage 5.1:** keyboard and screen-reader review. **Stage 5.2:** dark/light brand system, icon assets, and mobile/PWA behavior. **Stage 5.3:** backup/restore rehearsals. **Stage 5.4:** package signing and signed updates. **Stage 5.5:** documentation and public onboarding. **Stage 5.6:** performance baseline and resource budgets. **Stage 5.7:** security audit and fault-injection suite. **Stage 5.8:** staged public beta with explicit telemetry consent. A stable release requires an operator to complete onboarding, navigation, search, graph evidence inspection, safe homepage generation, agent read-only discovery, approved mutation, backup, restore, and uninstall using published instructions. Versioned release notes list known limits and the specific external protocol revisions actually tested. ## 72. Phase 6 — optional advanced functions, explicitly gated Potential advanced work includes local embeddings, hybrid semantic retrieval, visual graph editing, typed workspace applications, extension marketplace, portable skill bundles, secure multi-user local mode, opt-in cross-device sync, specialized content extractors, A2A/ACP/AG-UI/A2UI adapters, and advanced model-assisted software factory workflows. Each function must begin with an ADR, security model, feature flag, migration compatibility, independent conformance tests, and a no-feature fallback. Do not allow Phase 6 ambitions to delay a safe, comprehensible, fast local core. Feature sequencing should be based on observed user journeys and measurable failures: if search recall is weak, improve extraction and lexical ranking before allocating a new vector cluster; if file-watch reliability is weak, fix reconciliation before adding sync; if generated pages are unstable, fix region ownership before adding complex visual editing. --- # PART J — COMPLETE CAPABILITY ACCEPTANCE CATALOG The following concrete capability requirements turn broad product claims into implementable backlog items. Each entry has a contract-level behavior, a boundary to enforce, and an acceptance case. They are individually traceable to API schemas, policy fixtures, test IDs, UI states, and a responsible module. Unless explicitly marked as optional in the phase plan, their availability is determined by the release profile and conformance matrix; this inventory does not claim all are implemented today. ## Workspace lifecycle **CAP-001 — Register workspace.** Accept an existing directory without moving files; compute an exclusion preview and space estimate before any managed artifact is written. **Acceptance:** Test first-contact read-only behavior on source trees containing authored index.html and hidden private files. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-002 — Pause workspace.** Stop scheduled scanning and optional enrichment while keeping its identity, catalog, and historical evidence available. **Acceptance:** Test in-flight job cancellation and preservation of existing search results with an explicit stale indicator. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-003 — Resume workspace.** Revalidate the root identity and policy before restarting watcher and reconciliation, especially after volume remount or permission changes. **Acceptance:** Test changed root paths, symlink substitution, and obsolete credentials. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-004 — Relocate workspace.** Resolve a new filesystem path to an existing stable workspace ID using ownership and identity evidence instead of treating every move as a fresh import. **Acceptance:** Test ambiguous same-content directories and conflicting IDs. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-005 — Archive workspace.** Make a catalog entry inactive and read-only without implying the original directory was deleted; retain chosen audit and snapshot records. **Acceptance:** Test restore and reactivation with the same logical identity. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-006 — Unregister workspace.** Remove local registration only after explaining whether indexes, cache, generated files, and original content are affected separately. **Acceptance:** Test that normal user files remain intact by default. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-007 — Workspace health.** Report missing root, watcher coverage, index lag, task backlog, backup age, and active errors using explicit severity. **Acceptance:** Test degraded operation and no false healthy state after unexpected crashes. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-008 — Workspace template.** Apply a versioned blueprint to a newly created directory only after a file-by-file preview, with collision-safe naming. **Acceptance:** Test partial failures and independent rollback of generated assets. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-009 — Workspace policy inheritance.** Resolve installation, profile, workspace, ancestor, directory, object, and request constraints in deterministic order. **Acceptance:** Test restrictive ancestor deny and request-level narrowing. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-010 — Workspace portable export.** Bundle accepted workspace metadata and references with published schemas while excluding secrets and machine-only cache. **Acceptance:** Test importing on a second offline device without source-file relocation errors. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. ## Filesystem observation **CAP-011 — Directory enumeration.** Traverse within approved root boundaries using a time and entry budget and deterministic path normalization. **Acceptance:** Test deep nesting, Unicode names, unreadable folders, and a million-entry synthetic tree. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-012 — Symlink inspection.** Record symlinks as objects without following out-of-scope targets; display target state only to suitably authorized viewers. **Acceptance:** Test escape attempts through intermediate symlinks, junctions, and case changes. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-013 — Move recognition.** Correlate moves through stable native IDs, journal evidence, content versions, and context without merging intentionally duplicated files. **Acceptance:** Test simultaneous rename collisions and hard-link behaviors. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-014 — Deletion detection.** Require reconciliation before tombstoning an apparently missing source and preserve enough historical metadata for explanation. **Acceptance:** Test removable-volume disconnection versus true deletion. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-015 — Content hashing.** Stream content in bounded chunks and compute a named digest only after exclusion and file stability checks. **Acceptance:** Test changed source during read and enormous sparse files. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-016 — Ignore rules.** Apply policy-protected excludes before any read, thumbnail, embedding, logging, or export of the target. **Acceptance:** Test hidden secrets and nested ignore patterns. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-017 — Watcher coalescing.** Merge duplicate filesystem events into bounded work units while preserving a monotonic reconciliation checkpoint. **Acceptance:** Test event storms and overflowing OS watcher queues. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-018 — Polling fallback.** Detect unsupported or exhausted watcher capacity and enable a measured periodic inventory scan without pegging CPU. **Acceptance:** Test network mounts and platforms lacking expected event fidelity. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-019 — File metadata.** Capture MIME estimate, size, timestamps, version hash, path history, observed permissions, and extraction status separately. **Acceptance:** Test timestamp-only changes and inaccessible metadata. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-020 — Source-version reread.** Revalidate source identity immediately before writes or high-assurance reads rather than trusting a previously indexed hash. **Acceptance:** Test TOCTOU replacement between approval and execution. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. ## Content extraction **CAP-021 — Markdown extraction.** Preserve heading hierarchy, source line spans, links, fenced code boundaries, and frontmatter without executing embedded commands. **Acceptance:** Test malformed frontmatter and fenced prompt-injection content. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-022 — HTML extraction.** Extract readable text, headings, and links while sanitizing active content and refusing external subresource fetches. **Acceptance:** Test scripts, data URLs, inline event handlers, and hostile base tags. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-023 — PDF extraction.** Index text by page and annotate extraction gaps and optional OCR provenance so citations can reach the correct page version. **Acceptance:** Test encrypted, corrupted, and image-only fixtures. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-024 — Structured JSON extraction.** Validate size, nesting, and syntax, expose typed paths and selected values, and preserve raw source hashes. **Acceptance:** Test duplicate keys, deeply nested content, and huge arrays. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-025 — CSV and tabular extraction.** Infer headers and types conservatively, keep row offsets, and treat spreadsheet formulas as text rather than instructions. **Acceptance:** Test inconsistent rows, escaped delimiters, and extremely wide tables. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-026 — Source-code extraction.** Extract symbols, imports, tests, and documentation using language-specific parsers with a plain-text fallback. **Acceptance:** Test malformed source and files containing shell payload comments. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-027 — Archive inventory.** List supported archive members safely with compression ratio and path limits, without blindly extracting or executing contained files. **Acceptance:** Test zip bombs, path traversal, and nested archive caps. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-028 — Media transcript linkage.** Associate existing transcript or caption files with media objects using explicit provenance, without mandatory cloud transcription. **Acceptance:** Test unmatched and multiple candidate transcript versions. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-029 — Image metadata and optional OCR.** Respect orientation and privacy metadata, perform local OCR only when enabled, and label confidence and region geometry. **Acceptance:** Test sensitive images excluded from derived indexes. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-030 — Extractor quarantine.** Isolate repeated crashing or malformed inputs, surface a visible error, and allow controlled retry after the extractor is updated. **Acceptance:** Test that the rest of the queue remains live. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. ## Catalog and graph **CAP-031 — Stable object registry.** Issue opaque object IDs and maintain current and historical paths, never use an absolute path as global object identity. **Acceptance:** Test moves, duplicates, and user-created conflicting sidecars. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-032 — Version ledger.** Store immutable source observations with hash, time, extractor version, and catalog sequence for reproducible evidence. **Acceptance:** Test out-of-order watcher delivery and partial extraction failure. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-033 — Structural containment graph.** Maintain folder-parent and file-location relationships from observed filesystem state, with explicit status and provenance. **Acceptance:** Test child moves and symlink edges that should not imply physical containment. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-034 — Semantic relationship proposals.** Store model-inferred edges as suggestions with evidence links and approval states separate from observed edges. **Acceptance:** Test graph queries filtering unverified claims. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-035 — Entity registry.** Normalize optional named entities with source citations without assuming two same-name entities are identical. **Acceptance:** Test ambiguous names and human merge decisions. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-036 — Claim verification.** Tie assertions to exact source version and span, maintain contested claims, and track reviewer decisions. **Acceptance:** Test the effect of a source revision on previously approved claims. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-037 — Graph diff.** Compare versioned node/edge snapshots and report added, removed, changed, and review-required relationships. **Acceptance:** Test identical rebuilds yielding no spurious differences. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-038 — Graph traversal.** Enforce depth, node count, edge type, and workspace scope budgets before returning results. **Acceptance:** Test recursive explosion and unauthorized neighboring nodes. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-039 — Graph serialization.** Export schema-versioned nodes, edges, evidence, and manifest references without private machine paths unless explicitly chosen. **Acceptance:** Test round-trip parsing and dangling-edge detection. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-040 — Catalog repair.** Detect orphaned FTS entries, missing object versions, broken edge references, and corrupted derived artifacts with a dry-run plan. **Acceptance:** Test interrupted migrations and safe repair receipts. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. ## Search and context **CAP-041 — Keyword FTS search.** Parse exact phrases, fields, prefixes, and filters into parameterized FTS5 queries with deterministic ranking and snippet offsets. **Acceptance:** Test injection-like query text and large result sets. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-042 — Metadata faceting.** Allow filters by file type, path subtree, tags, state, date, owner, and extraction quality without revealing hidden counts. **Acceptance:** Test permission changes during pagination. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-043 — Saved search.** Persist named query definitions as portable metadata when requested, but never copy private result contents into a public preset. **Acceptance:** Test renamed workspace and deleted filters. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-044 — Search explanation.** Return source type, ranking signals, index freshness, and evidence pointers in a consistent inspectable result format. **Acceptance:** Test that a semantic hit is not mislabeled lexical. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-045 — Optional semantic search.** Build permission-scoped vectors from extracted chunks with reproducible model and chunk metadata. **Acceptance:** Test full disable/rebuild and delete propagation. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-046 — Hybrid ranking.** Merge lexical and semantic candidate lists under explicit ranking configuration and a permission-filtered deduplication stage. **Acceptance:** Test stable tie-breaks and lexical-only fallback. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-047 — Context mode selection.** Assemble overview, engineering, evidence, review, and audit packets according to explicit presets and caller intent. **Acceptance:** Test irrelevant source exclusion and budget use. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-048 — Context token budget.** Enforce hard byte/token limits with source-level omission reasons rather than truncating silently in the middle of a citation. **Acceptance:** Test oversized files and model-tokenizer unavailability. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-049 — Citation manifest.** Include object IDs, exact version digests, segments, time, extraction method, and link targets in every answer-ready context bundle. **Acceptance:** Test citation verification after a source move. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-050 — Freshness verification.** Offer an opt-in bounded source rescan for high-assurance contexts, returning partial status when deadline is exceeded. **Acceptance:** Test concurrent modifications and stale graph projections. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. ## Homepages and views **CAP-051 — Virtual folder homepage.** Render a useful server-generated overview for every registered directory without creating a physical index.html. **Acceptance:** Test unmodified source tree and no JavaScript. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-052 — Homepage draft.** Generate a preview from deterministic object summaries and templates, with optional model-written prose separately identified. **Acceptance:** Test HTML injection from filenames and document content. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-053 — Authored region preservation.** Identify managed markers and compare stored base hashes before updating only owned sections. **Acceptance:** Test manual edits and three-way conflict presentation. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-054 — Lock HTML snapshot.** Export a static readable state view plus machine-readable snapshot digest and explicit excluded content counts. **Acceptance:** Test offline rendering and tamper detection. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-055 — Breadcrumb navigation.** Use stable IDs for linked ancestor views and accessible labels that survive renaming. **Acceptance:** Test missing parent, deep nesting, and non-ASCII paths. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-056 — File preview.** Render safe plain text and sanitized previews while isolating active HTML and unsupported binary content. **Acceptance:** Test malicious embedded scripts and unsafe media links. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-057 — Changes timeline.** Show file, graph, task, and generated artifact changes with actor attribution and explicit certainty. **Acceptance:** Test out-of-order events and redacted private fields. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-058 — Review queue.** Group approval requests, identity ambiguities, graph suggestions, homepage conflicts, and failed extractions by urgency. **Acceptance:** Test that a denied actor cannot view another user's review details. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-059 — Graph explorer.** Offer visual relation navigation paired with an accessible tabular representation and evidence side-panel. **Acceptance:** Test keyboard-only use and large graph budgets. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-060 — Workspace dashboard.** Aggregate health, freshness, key documents, child directories, recent work, and actionable errors without inventing status metrics. **Acceptance:** Test partial data and graceful loading failures. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. ## Security and governance **CAP-061 — Principal enrollment.** Register typed human, service, and agent actors with owner attribution, status, and short-lived credential policies. **Acceptance:** Test that self-declared client metadata cannot impersonate an actor. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-062 — Capability-scoped token.** Generate an opaque credential bound to workspace, permitted operations, expiry, and revocation state. **Acceptance:** Test replay after revocation and token-redaction in logs. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-063 — Policy decision explanation.** Return a human-readable allow/deny/approval-required rationale without disclosing hidden policies to unauthorized users. **Acceptance:** Test sensitive resource existence leakage. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-064 — Directory ACL mapping.** Translate platform file access into an additional restriction, never into a grant overriding Intralock policy. **Acceptance:** Test OS permission revocation after catalog indexing. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-065 — Sensitive file detection.** Apply configured filename, path, and metadata heuristics prior to content reading; permit explicit reviewed overrides. **Acceptance:** Test private keys and secrets in nested ignored trees. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-066 — Approval request.** Bind an authorized decision to exact arguments, target versions, risk summary, and expiration. **Acceptance:** Test modifying any argument after approval. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-067 — Approval revocation.** Allow a pending decision to be withdrawn and stop not-yet-executed effects immediately. **Acceptance:** Test races between revocation and worker lease acquisition. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-068 — Audit event.** Record minimally sufficient actor, operation, policy result, object references, receipt digest, and timestamp in an append-oriented ledger. **Acceptance:** Test log failure and protected integrity checks. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-069 — Remote listener gate.** Require authenticated TLS, explicit interface binding, known allowed origins, and visible warning before exposing any local content remotely. **Acceptance:** Test accidental wildcard binding. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-070 — Emergency read-only lock.** Freeze new writes and executable jobs while retaining authorized navigation, export, and incident diagnostics. **Acceptance:** Test recovery after a compromised plugin or leaked token. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. ## Tasks and execution **CAP-071 — Durable task creation.** Start idempotent long-running work with actor/scope binding, deadlines, budgets, and output schema. **Acceptance:** Test duplicate requests and daemon crash recovery. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-072 — Task state inspection.** Return canonical state, progress, attempts, errors, and results through every declared transport. **Acceptance:** Test unauthorized task ID guessing and stale cursor. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-073 — Task cancellation.** Stop future effectful steps while reporting completed partial work and preserving rollback information. **Acceptance:** Test cancellation during an ongoing source write. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-074 — Work-order preview.** Produce a typed diff and risk report against current source versions before an actionable approval is requested. **Acceptance:** Test changed source between draft and preview. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-075 — Work-order execution.** Enforce each approved step against current policy and immutable preview, with idempotency and receipts. **Acceptance:** Test missing approvals and stale hashes. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-076 — Sandbox runner.** Execute expressly approved commands in a restricted environment with resource ceilings and isolated temporary storage. **Acceptance:** Test network denial and inherited-secret leakage. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-077 — Retry scheduler.** Retry transient failures with bounded backoff and dead-letter escalation without duplicating side effects. **Acceptance:** Test failure injection across each job transition. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-078 — Job resource quota.** Limit CPU, memory, disk, file descriptors, network, and runtime per task and per workspace. **Acceptance:** Test one overlarge job cannot starve local UI. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-079 — Task receipt.** Produce a machine-readable summary of inputs, effects, outputs, checks, actor, and provenance for each completed task. **Acceptance:** Test receipt verification after restart. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-080 — Rollback action.** Offer safe undo where supported and clear warnings for effects that cannot be reversed. **Acceptance:** Test partially applied multi-file plans and missing rollback files. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. ## MCP and agent surfaces **CAP-081 — MCP stdio transport.** Serve modern MCP requests over a process stdio boundary without printing log noise to stdout. **Acceptance:** Test independent client initiation and malformed JSON-RPC. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-082 — MCP Streamable HTTP.** Expose a deliberately enabled authenticated endpoint using modern routing headers and stateless per-request metadata. **Acceptance:** Test headers/body mismatches and unsupported versions. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-083 — MCP tools listing.** Return deterministic, permission-filtered, schema-complete tools in an accurately cacheable response. **Acceptance:** Test scope-dependent catalog differences and no leaked tool descriptions. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-084 — MCP resource read.** Resolve stable resource URIs to authorized source or projection data with bounded content and citations. **Acceptance:** Test a copied URI without credentials. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-085 — MCP prompt catalog.** Distribute versioned curated prompts with documented inputs, context budgets, and no self-granted authority. **Acceptance:** Test injection from untrusted prompt arguments. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-086 — MCP Tasks extension.** Translate negotiated extension calls into the durable task ledger with correct authorization and task state behavior. **Acceptance:** Test clients lacking the extension. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-087 — MCP Apps view.** Associate a tool with a sandboxed ui:// HTML resource, validate messages, and provide a text fallback. **Acceptance:** Test unauthorized host-UI callbacks. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-088 — Skills over MCP.** Expose approved SKILL.md bundles by URI with version, digest, compatibility, and read permissions. **Acceptance:** Test a skill trying to gain executable privileges from prose. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-089 — MCP compatibility mode.** Negotiate explicitly supported older protocol eras without polluting modern core behavior. **Acceptance:** Test sessions and handshake across pinned fixtures separately. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-090 — Agent onboarding guide.** Offer copyable instructions and a Markdown discovery page with no embedded tokens, truthful capabilities, and a clear human approval path. **Acceptance:** Test stale documentation and credential disclosure. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. ## Developer and browser interfaces **CAP-091 — REST objects API.** Return stable IDs, object versions, typed errors, and ETag-style preconditions for authorized reads and writes. **Acceptance:** Test 403, 404, 409, and 412 behavior. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-092 — OpenAPI publication.** Serve a versioned 3.1 contract with schema validation, examples, authorization, and operation IDs matching actual code. **Acceptance:** Test generation drift in CI. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-093 — GraphQL query API.** Expose typed graph connections subject to field-level policy, depth budgets, cardinality limits, and cursor pagination. **Acceptance:** Test alias and fragment bypasses. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-094 — WebMCP registration.** Feature-detect the experimental browser API and register only page-relevant tool schemas with safe lifecycle disposal. **Acceptance:** Test fallback browsers and duplicate names. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-095 — WebMCP form contract.** Annotate selected ordinary forms without sacrificing keyboard access, standard validation, or human submission. **Acceptance:** Test forms when WebMCP is absent. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-096 — CLI JSON contract.** Emit schema-versioned machine output to stdout, progress to stderr, and stable exit statuses. **Acceptance:** Test pipes, cancellation, invalid flags, and localization independence. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-097 — Go SDK.** Provide typed domain clients for workspace, search, graph, context, task, approval, and backup operations. **Acceptance:** Test compatibility across daemon minor releases. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-098 — TypeScript SDK.** Offer browser and server-safe adapters with explicit token handling and cancellable pagination. **Acceptance:** Test no accidental filesystem or secret assumptions in browser bundles. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-099 — Python SDK.** Support automation with typed errors, async tasks where appropriate, streaming I/O, and strict retries. **Acceptance:** Test cross-language fixture equivalence. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-100 — Event subscriptions.** Deliver scoped ordered events with resume cursors and safe filtering through approved UI/SDK mechanisms. **Acceptance:** Test replay limits and permission revocation during a stream. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. ## Operations and platform **CAP-101 — Catalog backup.** Take a transactionally consistent database backup with source coverage manifest and integrity checks. **Acceptance:** Test restore after crash and simultaneous indexing. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-102 — Source-inclusive backup.** Optionally package original files with explicit operator consent, quota estimate, protection, and a complete item manifest. **Acceptance:** Test exclusion fidelity and disk exhaustion. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-103 — Restore preview.** Compare target environment, source paths, versions, permissions, and schema before any replacement. **Acceptance:** Test conflicts and missing originals. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-104 — Diagnostic doctor.** Check database, file roots, watcher, permissions, schemas, queues, listeners, assets, and receipts with machine-readable remediation. **Acceptance:** Test independent simulated failure cases. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-105 — Signed release validation.** Verify checksums and release signing metadata before installing a binary or migration bundle. **Acceptance:** Test altered packages and revoked trust settings. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-106 — Offline conformance.** Operate core navigation, indexing, lexical search, graph, exports, and permission checks with network disabled. **Acceptance:** Test that optional features fail gracefully without outbound calls. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-107 — Dependency bill of materials.** Publish pinned direct and transitive libraries with version, license, provenance, and vulnerability state. **Acceptance:** Test untracked dependencies and incompatible licenses. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-108 — Accessibility conformance.** Verify full keyboard navigation, screen reader names, text contrast, and alternative graph representation. **Acceptance:** Test important workflows with no mouse. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-109 — Performance regression.** Compare representative file trees, search corpus, and graph traversal to documented latency and memory budgets. **Acceptance:** Test pathological inputs and queue fairness. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **CAP-110 — Data portability test.** Export, verify, import, and reconstruct a workspace on a clean machine using documented schemas and no proprietary cloud account. **Acceptance:** Test old schema migrations and missing optional caches. **Contract deliverable:** publish a typed schema or documented user action, a scope-and-policy rule, a deterministic positive fixture, a denial or misuse fixture, and a traceable status in the release conformance matrix. **Catalog size:** 110 individually testable capability contracts across 11 domains. All capabilities must be traceable from the user workflow to the underlying domain operation; duplicate implementations on separate transports are architectural defects. # PART K — REFERENCE CONTRACTS, GOVERNANCE MATRIX, AND RESOURCE INDEX ## 73. Canonical JSON resource envelope All interface adapters should preserve a small common envelope, even where their external wire protocols represent it differently. An illustrative internal DTO is: ```json { "schema": "intralock.resource/v1", "id": "obj_01JEXAMPLE", "workspace_id": "wks_01JEXAMPLE", "version_id": "ver_01JEXAMPLE", "catalog_sequence": 145, "kind": "document", "source": {"kind": "filesystem", "relative_path": "docs/overview.md", "sha256": ""}, "index": {"status": "ready", "observed_at": "2026-11-09T12:00:00Z", "indexed_at": "2026-11-09T12:00:05Z"}, "provenance": {"method": "text-extractor", "version": "1.0.0", "evidence": []}, "visibility": {"scope": "workspace", "redacted": false}, "links": {"self": "/api/v1/objects/obj_01JEXAMPLE"} } ``` This envelope is a **domain convention**, not a claim that MCP, GraphQL, A2A, or other protocols require these exact properties. Each adapter maps it to its official representation. Never place an authorization decision such as `allowed:true` into persisted content and assume it remains valid later; access is re-evaluated at read time. Response serializers must support field-level omission and redaction, with independent tests so objects returned through graph traversal are not more revealing than direct object reads. ## 74. Error taxonomy and client remediation | Code | Meaning | Client behavior | Security and operations note | |---|---|---|---| | `INVALID_ARGUMENT` | Input failed schema or semantics | Correct named fields and retry | Do not include private values in errors | | `UNAUTHENTICATED` | Missing or invalid identity | Begin approved authentication | Do not silently issue credentials | | `PERMISSION_DENIED` | Authenticated actor lacks privilege | Request narrower scope or owner review | Avoid revealing protected existence | | `APPROVAL_REQUIRED` | Action needs a distinct reviewer | Show immutable proposal and approval path | Bind approval to exact digest | | `VERSION_CONFLICT` | Source/catalog changed since preview | Refresh, diff, and reapprove | Never force a silent merge | | `WORKSPACE_UNAVAILABLE` | Root is missing or unreadable | Check volume and permissions | Do not automatically delete catalog | | `INDEX_STALE` | Source-verified result unavailable | Request bounded reconcile or accept stale flag | Disclose freshness limit | | `EXTRACTION_FAILED` | Parser could not process source | Show failure and retry policy | Quarantine suspicious input | | `RESOURCE_LIMIT` | Byte, token, CPU, memory, time, or query budget exceeded | Narrow operation or adjust approved quota | Prevent starvation | | `TASK_CANCELLED` | Task terminated | Inspect completed effects and receipts | Do not claim full rollback without proof | | `PROTOCOL_UNSUPPORTED` | Client used incompatible revision/extension | Follow documented compatibility matrix | Reject unknown protocol assumptions | | `BACKUP_UNVERIFIED` | Restore/backup integrity not demonstrated | Keep existing data and run verification | Do not overwrite sound catalog | | `INTERNAL_ERROR` | Unexpected server failure | Use request ID and sanitized diagnostics | No stack trace in ordinary response | Errors include stable machine codes and a correlation ID. Transport-specific HTTP statuses, MCP tool-result error forms, CLI exit codes, or GraphQL error extensions are mapped according to each protocol's rules. Recovery operations are never suggested in generic errors if the caller lacks permission to perform them. ## 75. Role-to-operation reference policy matrix The following profiles are product defaults, not unconditional grants. Each action is still evaluated against effective resource scope and operating-system permissions. | Operation | Viewer | Editor | Workspace steward | Administrator | Scoped agent | |---|---:|---:|---:|---:|---:| | Browse permitted metadata | Allow | Allow | Allow | Allow | Explicit grant | | Search permitted content | Allow | Allow | Allow | Allow | Explicit grant | | Read graph and citations | Allow | Allow | Allow | Allow | Explicit grant | | Propose relationships | Deny | Allow | Allow | Allow | Explicit grant | | Propose homepage | Deny | Allow | Allow | Allow | Explicit grant | | Publish generated page | Deny | Review | Review | Review | Approval bound | | Change original source | Deny | Review | Review | Review | Approval bound | | Execute external command | Deny | Deny | Restricted | Review | Special grant + approval | | Manage workspace policies | Deny | Deny | Deny | Allow | Deny by default | | Issue/revoke credentials | Deny | Deny | Deny | Allow | Deny by default | | Export private data | Scoped | Scoped | Scoped | Scoped | Explicit grant | | Create backup | Deny | Scoped | Scoped | Allow | Explicit grant | | Expose remote listener | Deny | Deny | Deny | Controlled setup | Deny by default | `Review` means an action can be proposed but requires the policy engine's actual decision and may require a separate approver. No role should have an unbounded ability to export all workspaces by virtue of its friendly display name. The policy matrix is checked into the repository and compiled into fixtures. A changed default permission requires a security review and migration note. ## 76. Definition of done, release gate, and evidence package A feature is not done because a route returns a success response. It is done when its domain semantics are described; input/output schemas are published; authority is enforced; positive, negative, and concurrency tests pass; privacy and accessibility impacts are reviewed; observability is instrumented without content leakage; failure states are documented; and a recovery or rollback strategy exists. For multi-surface capabilities, parity tests and version compatibility are mandatory. For opt-in AI functionality, offline fallback and model-output validation are mandatory. The release evidence package contains: architecture decision record IDs; code revision; dependency lockfiles and SBOM; migration checksums; security scan and test report; performance benchmark provenance; backup-and-restore results; accessibility checklist; API/protocol conformance matrix; actual supported client versions; documentation builds; signed artifact checksums; known limitations; and post-release incident contact/process. This is the authoritative basis for any assertion that a capability is production-ready. **Go/no-go questions:** Does the product preserve existing files? Does it work offline? Can we explain every state-changing effect? Can a revoked credential still read a file through any adapter? Can a stale approved preview overwrite changed content? Can the operator reconstruct a file's identity after a move? Can the operator restore from a verified backup? Can a malicious document cause hidden network disclosure? Can the same operation produce equivalent domain output through its advertised surfaces? A single failed critical invariant blocks release. ## 77. Open-source and public standard reference library The following are upstream engineering references to inspect for interoperability, licensing, and implementation patterns. They are not claims that the corresponding code is currently installed or that all projects are stable, API-compatible, or suitable for unmodified commercial redistribution. Pin versions and review license files before using them. **Core implementation:** - Go language/runtime: https://go.dev/ ; standard library docs: https://pkg.go.dev/std - Go filesystem notifications: https://github.com/fsnotify/fsnotify - HTML-first progressive enhancement: https://github.com/bigskysoftware/htmx and https://htmx.org/docs/ - SQLite engine and documentation: https://sqlite.org/ ; FTS5: https://sqlite.org/fts5.html - Pure-Go SQLite driver candidate: https://pkg.go.dev/modernc.org/sqlite ; alternative driver: https://github.com/mattn/go-sqlite3 - Optional vector index, pre-1.0 and version-sensitive: https://github.com/asg017/sqlite-vec - Go GraphQL schema-first candidate: https://github.com/99designs/gqlgen - OpenTelemetry Go instrumentation: https://github.com/open-telemetry/opentelemetry-go - Go static analysis/security: https://pkg.go.dev/golang.org/x/tools/go/analysis ; https://github.com/securego/gosec **MCP protocol and extensions:** - Modern MCP specification index: https://modelcontextprotocol.io/specification/2026-07-28 - July 2026 spec revision announcement: https://blog.modelcontextprotocol.io/posts/2026-07-28/ - Modern MCP change log: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/changelog.mdx - Official Go MCP SDK, including version compatibility: https://github.com/modelcontextprotocol/go-sdk - MCP Tasks extension: https://github.com/modelcontextprotocol/ext-tasks - MCP Apps official extension: https://github.com/modelcontextprotocol/ext-apps - MCP Skills over MCP extension: https://github.com/modelcontextprotocol/ext-skills - MCP Apps developer docs: https://apps.extensions.modelcontextprotocol.io/ **Browser and agent interoperability:** - WebMCP Community Group draft: https://webmachinelearning.github.io/webmcp/ - Chrome WebMCP development documentation: https://developer.chrome.com/docs/ai/webmcp - WebMCP imperative API: https://developer.chrome.com/docs/ai/webmcp/imperative-api - WebMCP declarative API: https://developer.chrome.com/docs/ai/webmcp/declarative-api - A2A protocol specifications: https://a2a-protocol.org/latest/ - AG-UI repository and event protocol: https://github.com/ag-ui-protocol/ag-ui - A2UI specification and renderers: https://github.com/a2ui-project/a2ui **Web and data standards:** - OpenAPI specification: https://spec.openapis.org/oas/latest.html - JSON Schema 2020-12: https://json-schema.org/draft/2020-12 - GraphQL specification: https://spec.graphql.org/ - W3C Trace Context: https://www.w3.org/TR/trace-context/ - W3C Web Content Accessibility Guidelines: https://www.w3.org/TR/WCAG22/ - JSON-LD: https://www.w3.org/TR/json-ld11/ - RFC 9457 problem details: https://www.rfc-editor.org/rfc/rfc9457 - HTTP Semantics: https://www.rfc-editor.org/rfc/rfc9110 - OAuth 2.0 Protected Resource Metadata: https://www.rfc-editor.org/rfc/rfc9728 - OAuth Security Best Current Practice: https://www.rfc-editor.org/rfc/rfc9700 **Security references:** - OWASP Application Security Verification Standard: https://owasp.org/www-project-application-security-verification-standard/ - OWASP Top Ten: https://owasp.org/www-project-top-ten/ - OWASP LLM and agentic security project: https://genai.owasp.org/ - Supply chain levels for software artifacts: https://slsa.dev/ - SPDX software bill of materials: https://spdx.dev/ **Repository adoption SOP:** investigate source repository, owner and maintainership; review version history and supported platforms; verify license and transitive obligations; check security advisories; build an isolated proof of concept; benchmark realistic data; evaluate API and schema stability; add SBOM and reproducible lockfile; record an ADR; run conformance/security tests; then promote to the approved dependency list. Do not ingest an entire external repository and run its build scripts merely because it is open source. ## 78. Nonfunctional service-level objectives and tracked risks The following should be stored as a versioned operational profile, not treated as universal promises. **Availability:** core browsing and catalog reading should remain available despite an extractor crash; a catalog integrity fault may require read-only recovery. **Latency:** p95 local FTS search target 500 ms on the reference 100,000-object corpus after warmup; the actual baseline must be recorded. **Integrity:** no unapproved original-file modifications in onboarding and indexing tests. **Isolation:** zero permitted out-of-root reads in malicious path fixtures. **Recoverability:** daily configured local catalog backup passes automated checksum validation and periodic restore drills. **Privacy:** no external data transfer in offline-mode tests. **Compatibility:** all advertised interface operations pass pinned schemas and fixtures. Maintain a live risk register with at least: variable filesystem semantics; watcher overflow; catalog/file race conditions; source page collisions; private content accidentally included in context; prompt injection leading to unauthorized actions; browser tool support fragmentation; MCP revision migration; extension supply-chain compromises; oversized parser workload; wrong permissions after workspace relocation; duplicate source identity inference; remote access exposure; untested restore; and excessive scope of initial implementation. Each risk has an owner, severity, mitigation, test, and next-review date. ## 79. Final canonical implementation order The implementation sequence is not interchangeable. Establish the **filesystem authority and read-only index** before advanced agent capabilities. Establish **stable IDs and versioned source evidence** before graph relationships. Establish **policy and capability contracts** before opening write APIs. Establish **safe previews, approvals, and recovery** before model-driven mutation. Establish **domain operation correctness** before adapting every surface. Establish **explicit modern protocol compatibility** before claiming MCP parity. Establish **tested rollback and backup** before frequent releases. Every stage should ship a user-visible capability and a verified negative test. Intralock's durable competitive advantage is not any single model, viewer, or protocol logo. It is the coherent combination of ordinary filesystem ownership, inspectable machine-readable state, non-destructive generated views, traceable relationships, reliable local search, scope-governed actions, and consistent interfaces. That combination only remains credible if each new subsystem respects the original authority boundary. --- # FINAL ACCEPTANCE STATEMENT **An implementation conforms to the core Intralock specification only when it demonstrably preserves the user's original filesystem, operates locally and offline, maintains reliable identity and search across changes, keeps derived indexes and generated views reversible, reports provenance and uncertainty, enforces the same policy for every exposed operation, and provides verified backup/recovery.** **A complete platform implementation additionally publishes and passes conformance suites for every declared API, CLI, SDK, MCP, WebMCP, task, app, skill, and optional interoperability surface.** A roadmap, mocked endpoint, promotional page, schema without execution, or unreviewed plugin is not evidence of shipped support. **End of Intralock Sole-Source Master Specification v1.0.0.**