data-olympus 0.3.3__tar.gz → 0.3.5__tar.gz

{data_olympus-0.3.3 → data_olympus-0.3.5}/CHANGELOG.md

@@ -12,6 +12,65 @@ This project uses [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ## [Unreleased]
 
+## [0.3.5] - 2026-07-06
+
+### Fixed
+
+- **Ambiguous rejection reason for writes outside the deployment's indexed
+  prefixes.** `kb_propose_edit` (and `kb_propose_memory`) rejected a
+  well-formed, non-malicious path outside `KB_INDEXED_PREFIXES` with the same
+  opaque reason string (`traversal_or_excluded` / `not_md_or_excluded`) used
+  for an actual traversal or control-character attempt. A syntactically fine
+  path outside the configured prefixes is an ordinary deployment-configuration
+  fact, not a structural or security rejection - conflating the two sent an
+  operator hunting for a nonexistent traversal bug during a company-knowledge
+  KB audit session (`operator/laptop.md`, readable and indexed for search,
+  came back rejected on write with no indication it was simply outside the
+  deployment's writable-prefix allowlist). `rejected_path_not_indexable`
+  responses (and audit events) now carry a specific reason:
+  `structurally_invalid` (empty/control-chars/absolute/traversal/excluded
+  segment), `not_markdown`, or `not_in_indexed_prefixes`.
+- Investigated the same session's second report (a `rejected_stale_base`
+  resolve appearing to "leak" its path lock) and confirmed it is **not a
+  bug**: `restore_resolve` deliberately keeps the path lock held after a
+  gate rejection so the operator's still-pending proposal can't be clobbered
+  by a concurrent write to the same path (documented behavior, hardened
+  across multiple rounds of review). `reject`ing the stale entry (which does
+  release the lock) and re-proposing fresh, exactly what that session did, is
+  the correct and only intended recovery for a pending entry with a
+  permanently-wrong base marker - there was nothing to fix.
+
+## [0.3.4] - 2026-07-05
+
+### Fixed
+
+- **Enforcement gate false-positives on prose that merely mentions a governed
+  keyword, for tool calls with a known file path.** `IntentClassifier.classify`
+  scanned `action_diff` (the raw Write/Edit content or Bash command text, up
+  to 4000 chars) for free-text keywords like `auth`, `rls`, `tenant`, `secret`
+  in addition to `intent`, for every tool call. A scratch write whose text
+  simply discussed one of those words as a topic - not an actual governed
+  action - tripped the pre-tool gate regardless of the real (ungoverned)
+  write target, and a fresh `kb_consult` call did not clear it because the
+  consult's own classification (`intent`-only) and the gate's classification
+  (`intent + action_diff`) disagreed on whether the action was governed.
+  Keyword matching on `action_diff` now only applies when the tool call
+  carries no `action_path` (Bash commands and OpenCode's `patch`, whose
+  content is the only signal available); when an `action_path` is present
+  (Write/Edit/MultiEdit), classification uses the path globs and dependency
+  command patterns, unchanged, so this keeps full detection for real governed
+  edits (a patch touching `package.json`) without flagging unrelated prose in
+  files the path globs don't consider governed. Found via a company-knowledge
+  KB audit session that reproduced it live (a scratch `.txt` file containing
+  "RLS tenant boundaries auth trust model" was blocked with no governed path
+  or command in sight); independently reviewed via `codex exec` before
+  release.
+  - The audit's other finding (CX1: the pre-tool gate and the pre-commit
+    `report --staged` gate resolving two different workspace keys) was
+    already fixed in v0.2.0 (#64, worktree-invariant workspace key); no
+    further change needed. It was still visible in that audit only because
+    it predated the deployed kn-dev redeploy.
+
 ## [0.3.3] - 2026-07-05
 
 ### Fixed

{data_olympus-0.3.3 → data_olympus-0.3.5}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: data-olympus
-Version: 0.3.3
+Version: 0.3.5
 Summary: Governance-grade knowledge-base format (OKF-compatible) plus CLI and single-writer MCP server
 Project-URL: Homepage, https://github.com/knaisoma/data-olympus
 Project-URL: Repository, https://github.com/knaisoma/data-olympus

{data_olympus-0.3.3 → data_olympus-0.3.5}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "data-olympus"
-version = "0.3.3"
+version = "0.3.5"
 description = "Governance-grade knowledge-base format (OKF-compatible) plus CLI and single-writer MCP server"
 readme = "README.md"
 requires-python = ">=3.13"

{data_olympus-0.3.3 → data_olympus-0.3.5}/src/data_olympus/auth.py

@@ -95,6 +95,32 @@ def is_writable_path(target_path: str) -> bool:
     return any(canonical.startswith(p) for p in indexed_prefixes())
 
 
+def path_rejection_reason(raw_target_path: str) -> str:
+    """Why a path fails :func:`is_writable_path`, for a caller that already knows
+    it does. Three distinct causes were previously collapsed into one opaque
+    reason string (``not_md_or_excluded`` / ``traversal_or_excluded``), which
+    reads identically whether the path was a malicious traversal attempt or a
+    perfectly legitimate path outside the deployment's configured
+    ``KB_INDEXED_PREFIXES`` - the latter is an ordinary, expected outcome for any
+    deployment whose repo layout has top-level directories beyond the generic
+    default (see ``indexed_prefixes()``), not a security event, and conflating
+    the two sent at least one operator hunting for a traversal bug that was
+    actually a missing ``KB_INDEXED_PREFIXES`` entry.
+
+    Returns one of: ``structurally_invalid`` (empty/control-chars/absolute/
+    traversal/excluded-segment - :func:`normalize_target_path` rejected it),
+    ``not_markdown``, or ``not_in_indexed_prefixes`` (a syntactically fine path
+    outside every configured prefix - a deployment-configuration gap, not a
+    structural or security rejection).
+    """
+    canonical = normalize_target_path(raw_target_path)
+    if canonical is None:
+        return "structurally_invalid"
+    if not canonical.endswith(".md"):
+        return "not_markdown"
+    return "not_in_indexed_prefixes"
+
+
 def safe_join_under_root(root: str, target_path: str) -> str | None:
     """Join ``target_path`` under ``root`` and return the absolute path only when
     it resolves to exactly that lexical location inside ``root``; else return None.

{data_olympus-0.3.3 → data_olympus-0.3.5}/src/data_olympus/enforce_policy.py

@@ -81,7 +81,21 @@ class IntentClassifier:
         action_diff: str = "",
     ) -> ClassifyResult:
         signals: list[str] = []
-        text = f"{intent} {action_diff}".lower()
+        # Free-text keyword signals always scan `intent` (a short, deliberate
+        # statement of what the agent is about to do - kb_consult's argument -
+        # so a keyword there is a real signal). They scan `action_diff` too,
+        # but ONLY when there is no `action_path`: `action_diff` is arbitrary
+        # write/command CONTENT up to 4000 chars (Write.content, Edit.new_string,
+        # Bash.command, OpenCode patch text), and when a concrete action_path is
+        # already given, path-glob matching below is the intended signal for
+        # that action - layering the free-text net on top blocked benign writes
+        # to ungoverned files that merely discussed a keyword as a topic (a
+        # scratch file quoting "RLS"/"auth" from a security standard). Bash
+        # commands and OpenCode's `patch` tool carry no action_path at all
+        # (their action_diff IS the only content available), so the free-text
+        # net still applies there - dropping it entirely would silently lose
+        # the only governed-decision signal for those two tool shapes.
+        text = intent.lower() if action_path else f"{intent} {action_diff}".lower()
         for kw, rx in self._keyword_res:
             if rx.search(text):
                 signals.append(f"keyword:{kw}")

{data_olympus-0.3.3 → data_olympus-0.3.5}/src/data_olympus/tools_write.py

@@ -15,6 +15,7 @@ from data_olympus.auth import (
     PathBlocklist,
     is_writable_path,
     normalize_target_path,
+    path_rejection_reason,
     safe_join_under_root,
 )
 from data_olympus.format.frontmatter import parse_frontmatter
@@ -486,11 +487,12 @@ def kb_propose_memory_fn(
 
     # 1. Structural rule (cheap).
     if not is_writable_path(target_path):
+        reason = path_rejection_reason(target_path)
         _emit_audit(audit_log, **{**audit_base, "status": "rejected_path_not_indexable",
-                                   "reason": "not_md_or_excluded"})
+                                   "reason": reason})
         return ProposeResponse(
             status="rejected_path_not_indexable",
-            reason="not_md_or_excluded",
+            reason=reason,
             target_path=target_path,
         )
 
@@ -657,9 +659,15 @@ def kb_propose_edit_fn(
     }
     canonical = normalize_target_path(target_path)
     if canonical is None or not is_writable_path(canonical):
-        _emit_audit(audit_log, **{**audit_base, "status": "rejected_path_not_indexable"})
+        # audit_base["reason"] otherwise carries the caller's edit rationale;
+        # for this terminal rejection (nothing is written) it is overwritten
+        # with the machine rejection cause instead, since that is what an
+        # operator reading the audit log needs to see here.
+        rejection_reason = path_rejection_reason(target_path)
+        _emit_audit(audit_log, **{**audit_base, "status": "rejected_path_not_indexable",
+                                   "reason": rejection_reason})
         return ProposeResponse(status="rejected_path_not_indexable",
-                               reason="traversal_or_excluded",
+                               reason=rejection_reason,
                                target_path=target_path)
     # From here on operate ONLY on the canonical path: classification, blocklist,
     # the pending record, the filesystem join, and ``git add`` must all agree with