Merge remote-tracking branch 'origin/main' into develop

Author: tbitcs

.chronomemory/events.wal

@@ -4,10 +4,24 @@ updates:
     directory: "/"
     schedule:
       interval: "weekly"
+      day: "monday"
     open-pull-requests-limit: 5
+    labels:
+      - "dependencies"
+    groups:
+      dev-deps:
+        patterns:
+          - "ruff"
+          - "mypy"
+          - "pytest*"
+          - "types-*"
 
   - package-ecosystem: "github-actions"
     directory: "/"
     schedule:
       interval: "weekly"
+      day: "monday"
     open-pull-requests-limit: 5
+    labels:
+      - "dependencies"
+      - "ci"

.chronomemory/snapshot.json

@@ -0,0 +1,35 @@
+name: CodeQL
+
+on:
+  push:
+    branches: [main, develop]
+  pull_request:
+    branches: [main, develop]
+  schedule:
+    - cron: '30 2 * * 1'  # Weekly Monday 02:30 UTC
+
+permissions:
+  actions: read
+  contents: read
+  security-events: write
+
+jobs:
+  analyze:
+    name: Analyze (Python)
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Initialize CodeQL
+        uses: github/codeql-action/init@v4
+        with:
+          languages: python
+          queries: security-extended,security-and-quality
+
+      - name: Autobuild
+        uses: github/codeql-action/autobuild@v4
+
+      - name: Perform CodeQL Analysis
+        uses: github/codeql-action/analyze@v4
+        with:
+          category: "/language:python"

.github/dependabot.yml

@@ -6,7 +6,7 @@ on:
   workflow_dispatch:
 
 permissions:
-  contents: read
+  contents: write   # needed to create/update the rolling 'latest' GitHub pre-release
 
 jobs:
   test:
@@ -30,7 +30,7 @@ jobs:
     runs-on: ubuntu-latest
     environment: pypi
     permissions:
-      contents: read
+      contents: write   # write required to create/update the dev GitHub pre-release
       id-token: write
     steps:
       - uses: actions/checkout@v6
@@ -66,6 +66,22 @@ jobs:
         uses: pypa/gh-action-pypi-publish@release/v1
         continue-on-error: true  # version already exists on PyPI is not a failure
 
+      # Create/update a rolling GitHub pre-release so users can track dev builds.
+      # NOTE: when the first official stable release ships, remove this step and
+      # instead rely on release.yml with --latest to make stable the default.
+      - name: Create/update rolling dev GitHub pre-release
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          # Delete any existing 'latest-dev' tag+release so we can overwrite it.
+          gh release delete latest-dev --repo ${{ github.repository }} \
+            --yes --cleanup-tag 2>/dev/null || true
+          gh release create latest-dev dist/* \
+            --title "Latest dev build (${DEV_VERSION})" \
+            --notes "Rolling dev pre-release built from the develop branch." \
+            --prerelease \
+            --no-latest
+
   docs-build:
     needs: build-and-publish
     runs-on: ubuntu-latest

.github/workflows/codeql.yml

@@ -57,10 +57,14 @@ jobs:
         env:
           GH_TOKEN: ${{ github.token }}
         run: |
+          # NOTE: using --no-latest during the dev/pre-release phase so that the
+          # rolling dev pre-release stays as the visible "latest" on GitHub.
+          # FIRST STABLE RELEASE: change --no-latest to --latest here, and also
+          # update kairos_updater.rs default channel back to Stable.
           gh release create "${{ github.ref_name }}" dist/* \
             --title "${{ github.ref_name }}" \
             --generate-notes \
-            --latest || echo "Release already exists — skipping"
+            --no-latest || echo "Release already exists — skipping"
 
   pypi-publish:
     needs: build

.github/workflows/dev-release.yml

@@ -41,6 +41,8 @@ temp/
 # Secrets and local-only artifacts
 .env
 .repo-index/
+# Local diagnostic / one-off scripts (absolute paths, never commit)
+_diag_*.py
 
 # .specsmith/ split: committed (audit chain) vs gitignored (runtime cache)
 # Keep committed: config.yml, requirements.json, testcases.json
@@ -60,10 +62,15 @@ temp/
 .specsmith/logs/
 .specsmith/sessions/
 .specsmith/agent-reports/
+# Dispatch DAG event logs (runtime only — replay from .chronomemory if needed)
+.specsmith/dispatch/
+# Generated migration scan manifest (re-created by specsmith esdb migrate)
+.specsmith/esdb_migration_manifest.json
 
 # Old Warp branding directory — renamed to .kairos/; prevent accidental re-creation
 .warp/
 
-# Rust build artifacts (chronomemory crate)
+# Rust build artifacts
 crates/chronomemory/target/
+app/target/
 

.github/workflows/release.yml

@@ -0,0 +1,26 @@
+# .specsmith/compliance/
+
+Project-specific compliance overlays for AI regulation.
+
+## Structure
+
+Each file overrides the built-in regulation status for this project:
+  eu-ai-act.yaml        — EU AI Act (Regulation 2024/1689)
+  nist-rmf.yaml         — NIST AI RMF 1.0 + AI 600-1
+  omb-m-24-10.yaml      — OMB M-24-10
+  colorado-sb24-205.yaml — Colorado AI Act (effective Feb 2026)
+  texas-hb1709.yaml     — Texas AI Transparency Act
+  etc.
+
+## Usage
+
+  # Check compliance for all regulations
+  specsmith compliance check
+
+  # Generate compliance report
+  specsmith compliance report --format html --output compliance-report.html
+
+  # Store results to ESDB audit trail
+  specsmith compliance audit
+
+See: https://specsmith.readthedocs.io/en/stable/compliance/

.gitignore

@@ -0,0 +1,17 @@
+# EU AI Act (Regulation 2024/1689) — project overlay
+#
+# This file allows overriding compliance status for this specific project.
+# Leave fields empty to use specsmith's auto-detection.
+#
+# regulation_id: eu-ai-act
+# project notes:
+
+risk_tier: minimal_risk   # prohibited | high_risk | gpai | minimal_risk
+is_gpai: false            # true if this is a General Purpose AI model
+gpai_systemic_risk: false # true if > 10^25 FLOP training compute
+
+# Override specific article status (auto-detected if absent):
+# article_overrides:
+#   Art.9:
+#     status: compliant
+#     notes: "Risk management system via specsmith AEE pipeline"

.specsmith/compliance/README.md

@@ -0,0 +1,200 @@
+# Generated by specsmith migrate m001
+# Edit this file; original MD kept as view.
+
+content: '# Epistemic Axioms — specsmith
+
+
+  specsmith is built on Applied Epistemic Engineering (AEE) principles. This document
+
+  defines the five axioms as they apply to specsmith''s own development.
+
+
+  See the full AEE primer: https://specsmith.readthedocs.io/en/stable/aee-primer/
+
+
+  ---
+
+
+  ## Axiom 1: Observability
+
+
+  Every requirement in `docs/REQUIREMENTS.md` must be fully inspectable. Hidden assumptions
+
+  are a stop condition (H13).
+
+
+  **In practice:**
+
+  - All REQ-XXX entries must have `**Platform:**` or `**Boundary:**` fields
+
+  - Technology decisions in architecture.md must declare alternatives considered
+
+  - AGENTS.md proposals must include `Assumptions:` field
+
+
+  ---
+
+
+  ## Axiom 2: Falsifiability
+
+
+  Every accepted requirement must have a corresponding test. Unchallenged claims are
+  not
+
+  engineering artifacts.
+
+
+  **In practice:**
+
+  - Every REQ-XXX with status ACCEPTED must have TEST-XXX in TESTS.md with `Covers:`
+  reference
+
+  - `specsmith audit` enforces REQ↔TEST consistency
+
+  - `specsmith epistemic-audit` detects accepted requirements without test coverage
+
+
+  ---
+
+
+  ## Axiom 3: Irreducibility
+
+
+  Requirements must be decomposed to atomic, independently verifiable primitives.
+
+
+  **In practice:**
+
+  - Requirements with more than one core claim should be split
+
+  - `specsmith stress-test` flags compound claim patterns
+
+  - Each REQ-XXX should be independently testable
+
+
+  ---
+
+
+  ## Axiom 4: Reconstructability
+
+
+  Every failed requirement can be reconstructed. Failure modes are recovery opportunities.
+
+
+  **In practice:**
+
+  - `specsmith epistemic-audit` emits `RecoveryProposal` objects for all failure modes
+
+  - Recovery proposals require human approval before applying (H2)
+
+  - DEPRECATED requirements are kept in the ledger — never deleted
+
+
+  ---
+
+
+  ## Axiom 5: Convergence
+
+
+  Systematic application of stress-test (S) and recovery (R) will converge to equilibrium.
+
+
+  **In practice:**
+
+  - Run `specsmith stress-test` after every batch of new requirements
+
+  - A passing `specsmith epistemic-audit` with `Equilibrium: YES` is the milestone
+  gate
+
+  - CI can gate on `specsmith epistemic-audit --threshold 0.6`
+
+
+  ---
+
+
+  ## Current Epistemic Status
+
+
+  Run `specsmith epistemic-audit --project-dir .` to check current status:
+
+  - Equilibrium: [run to check]
+
+  - Overall certainty: [run to check]
+
+  - Logic knots: [run to check]
+
+
+  ---
+
+
+  ## Certainty Threshold
+
+
+  specsmith''s epistemic threshold: **0.7** (configured in `scaffold.yml`)
+
+
+  P1 requirements with confidence below MEDIUM are a stop condition per H13.
+
+
+  ---
+
+
+  ## External Validation: OEA Recursive Generative Stability
+
+
+  The five AEE axioms above describe the engineering properties that a governed AI
+  system
+
+  must have. The question of *why* these axioms specifically prevent hallucination
+  and drift
+
+  was answered empirically by the study:
+
+
+  > *"Ontology-Epistemic-Agentic (OEA) Recursive Generative Stability: A Unified Framework
+
+  > for Preventing Hallucination and Drift in Large Language Models"*
+
+  > — BitConcepts Research, 2026
+
+
+  The OEA study ran controlled ablation experiments across several LLM families and
+
+  identified the following correspondences between AEE axioms and measurable hallucination
+
+  control mechanisms:
+
+
+  | AEE Axiom | OEA Control Mechanism | Hard Rule |
+
+  |---|---|---|
+
+  | Axiom 1 — Observability | Epistemic scope bounding (H15) | H15 |
+
+  | Axiom 2 — Falsifiability | Calibration direction (H17); Falsifiability required
+  (H20) | H17, H20 |
+
+  | Axiom 3 — Irreducibility | No undisclosed model assumptions (H21) | H21 |
+
+  | Axiom 4 — Reconstructability | Anti-drift recursion guard (H16) | H16 |
+
+  | Axiom 5 — Convergence | RAG retrieval filtering (H18); Synthetic contamination
+  prevention (H19) | H18, H19 |
+
+
+  H22 (cross-platform CI enforcement) addresses the infrastructure dimension of the
+  OEA
+
+  cross-platform validity requirement.
+
+
+  In concrete terms: a system that enforces H15–H22 operationalises the OEA framework.
+
+  Specsmith''s governance layer is the first open-source AEE toolkit to encode these
+
+  findings as machine-enforceable rules via `specsmith validate`.
+
+  '
+generated_by: specsmith migrate (m001)
+kind: axioms
+source_md: docs/governance/EPISTEMIC-AXIOMS.md