prole/docs/knoe-db-documentation-mcp-architecture.md
chrisfu a069989315 Rename prole-db to knoe-db, add knoe-auth as cluster-internal KDC
Itemized changes:

1. knoe-auth: New cluster-internal KDC and SSO gateway service
   - Created etc/init_knoe_auth.sh based on init_kdc.sh with knoe-auth naming
   - Namespace defaults to SERVICE_NAMESPACE (knoe-system)
   - ConfigMap: knoe-auth-kdc-config, Secret: knoe-auth-secrets
   - Legacy cleanup removes old auth/dog/authority deployments

2. Orchestration: knoe-auth initializes before CloudNativePG
   - Updated prole.sh to insert init_knoe_auth.sh as step 2 (before CNPG)
   - Renumbered all subsequent initialization steps

3. Kong routing: Updated init_kong.sh to route to knoe-auth in SERVICE_NAMESPACE

4. Comment/reference updates for knoe-auth
   - Updated init_common_services.sh, init_service_layer.sh, init_kerberos.sh

5. prole-db renamed to knoe-db across the entire codebase
   - Renamed prole-db/ directory to knoe-db/
   - Renamed all prole-db Kubernetes manifests (deploy/opentofu, k8s/)
   - Renamed scripts: docker-root-knoe-db.sh, docker-run-knoe-db.sh, test-cnpg-knoe-db.sh
   - Renamed etc/init_prole-db-reset.sh to etc/init_knoe-db-reset.sh
   - Renamed etc/prole-db-passwwd.sh to etc/knoe-db-passwwd.sh
   - Renamed mock_val counterparts accordingly
   - Renamed tests/etc/test_init_prole-db-reset.sh to test_init_knoe-db-reset.sh
   - Renamed docs/prole-db-documentation-mcp-architecture.md to knoe-db variant
   - Renamed modes/k3d/prole-db/ to modes/k3d/knoe-db/
   - Renamed prole-db.iml to knoe-db.iml

6. Configuration updates
   - Updated conf/dev, conf/prod, conf/test, conf/service prole.cfg files
   - Updated conf/port-mapping.cfg
   - Updated etc/prole_cfg.sh and mock_val/prole_cfg.sh
   - Updated service/prole.cfg

7. Kubernetes manifests and deploy configuration
   - Updated deploy/opentofu/k3s ArgoCD application YAMLs
   - Updated kong-configmap.yaml and kustomization.yaml
   - Updated k3s/kong-config.yml and prole-resources.yaml
   - Updated prole-mssql-db deployment YAMLs
   - Updated supabase helm render and deploy scripts

8. Infrastructure and GCP Terraform
   - Updated deploy/gcp/terraform: folders, groups, IAM, service-projects

9. Python/installer code updates
   - Updated knoe/core: actions, build_context, controller, env, milestones
   - Updated knoe/milestone.py
   - Updated knoe/ui/screens: cfg, database, database_options, deploy, docker,
     navigation, security, services, validate
   - Updated knoe.spec, status.py

10. Shell script updates
    - Updated etc/: build_db, init_cloudnative_pg, init_cnpg_backup,
      init_db_manager, init_forgejo, init_gitlab, init_monitoring, init_openbao,
      init_port_forwards, init_postgrest, init_supabase_ports, status
    - Updated mock_val/ counterparts for all above scripts
    - Updated prole-net/init-prole-dns.sh
    - Updated bin/prole-kpf.sh, gitea/deploy.sh, supabase/deploy.sh

11. Test updates
    - Updated tests/etc/: test_init_cloudnative_pg*, test_init_cnpg_backup*,
      test_init_kdc*, test_init_kerberos*, test_init_kong*, test_prole_cfg*
    - Updated tests/installer/: test_actions_helpers, test_cfg_save_kubecontext,
      test_controller, test_core_classes, test_milestones, test_milestones_extended,
      test_namespace_propagation
    - Updated tests/: test_database_options, test_navigation,
      test_render_supabase_hostname, test_docker_build_fix,
      test_all_prole_home_fixes, silent_install_test, final_test

12. Documentation updates
    - Updated docs/: DOCKER-BUILD-FIX, PROLE-CFG-SECRETS, PROLE-HOME-DIRECTORY,
      build-system, patent
    - Updated scan/network_description.txt
    - Updated pom.xml

13. Miscellaneous script updates
    - Updated root-level: _adopt_replica_pvcs, _fix_replica_merlin, _import_pi,
      _patch_cluster, _prebind_pvcs, _rebind_d002, _rebind_d002b, test_resolve
    - Updated scripts/generate_spec.py

Co-authored-by: Junie <junie@jetbrains.com>
2026-03-22 22:16:21 -07:00

344 lines
7.6 KiB
Markdown

# Prole-DB Documentation MCP Architecture
**Design: Postgres-Core, Next.js Edge**
------------------------------------------------------------------------
## 1. Objective
Implement a Documentation MCP Server integrated into **Prol.app
(Next.js)** where:
- **Postgres (knoe-db) is the only authoritative core**
- Next.js provides the MCP interface and UI
- Vector search is optional and derived
- Ingestion is idempotent and Git-versioned
- All responses are citation-grounded and reproducible
There is no Python core and no secondary business-logic layer.\
**The database owns truth, provenance, and policy.**
------------------------------------------------------------------------
## 2. High-Level Architecture
Git Repo (docs branch)
↓
CI → doc-manifest.json (git_sha, files, hashes)
↓
Ingestion Worker (Node k8s Job)
↓
Postgres (knoe-db) ← authoritative core
↓
Next.js (Prol.app)
├── UI (/docs, /search)
└── MCP Server (/api/mcp)
Optional vector indexing:
Postgres → embedding worker → pgvector (same DB)
------------------------------------------------------------------------
## 3. Core = Postgres Schema
Schema name: `doc`
Postgres is the authoritative knowledge store.
### 3.1 `doc.source`
Tracks document origin and versioning.
Column Type Notes
-------------- ------------- -----------------
source_id uuid pk
repo text git repository
git_sha text commit hash
path text file path
ingested_at timestamptz
content_hash text integrity check
------------------------------------------------------------------------
### 3.2 `doc.document`
Canonical document metadata.
Column Type Notes
----------------- ------------- ---------------------------------
doc_id uuid pk
source_id uuid fk references doc.source
title text
uri text unique `doc://doc/{doc_id}`
lifecycle text `stable`, `draft`, `deprecated`
confidentiality text `internal`, `restricted`
content_text text full markdown content
updated_at timestamptz
------------------------------------------------------------------------
### 3.3 `doc.chunk`
Chunked content for search and embeddings.
Column Type Notes
------------- --------- -------------
chunk_id uuid pk
doc_id uuid fk
ordinal int chunk order
text text
token_count int
------------------------------------------------------------------------
### 3.4 `doc.embedding` (Optional)
Requires pgvector.
Column Type Notes
------------ -------------- -------
chunk_id uuid pk
embedding vector(1536)
model text
indexed_at timestamptz
------------------------------------------------------------------------
### 3.5 `doc.link`
Semantic relationships between documents.
Column Type
---------- -------------------------------------------------
from_doc uuid
to_doc uuid
relation text (`applies_to`, `supersedes`, `references`)
------------------------------------------------------------------------
## 4. Policy Enforcement
Default rule:
> Only `stable` documents are searchable unless explicitly overridden.
Enforcement options:
- SQL WHERE clauses in MCP queries (initial phase)
- Row Level Security (future phase)
Confidentiality gating:
- MCP layer passes `user_role`
- Queries filter by `confidentiality <= role_level`
Every answer must include:
- `doc_id`
- `uri`
- `git_sha`
The database guarantees provenance.
------------------------------------------------------------------------
## 5. Ingestion Pipeline
### 5.1 Trigger
Git push to docs branch triggers CI.
### 5.2 CI Output
`doc-manifest.json`
``` json
{
"repo": "knoe-db",
"git_sha": "abc123",
"files": [
{ "path": "runbooks/kerberos.md", "hash": "..." }
]
}
```
### 5.3 Ingestion Worker (Node.js, Kubernetes Job)
Process:
1. Read manifest
2. For each file:
- Compute content hash
- Upsert `doc.source`
- Upsert `doc.document`
- Chunk content → insert `doc.chunk`
3. Optional:
- Generate embeddings → insert `doc.embedding`
Requirements:
- Idempotent
- Upsert keyed by `(repo, git_sha, path)`
- Historical versions preserved
------------------------------------------------------------------------
## 6. MCP Server (Next.js)
Location:
/app/api/mcp/route.ts
Transport:
- MCP Streamable HTTP
Next.js acts as a stateless façade over Postgres.
------------------------------------------------------------------------
## 7. MCP Tools
### 7.1 `doc.search`
Input:
``` json
{
"query": "kerberos optional kdc",
"scope": "stable",
"limit": 8
}
```
Baseline SQL:
``` sql
SELECT d.doc_id, d.title, d.uri, s.git_sha
FROM doc.document d
JOIN doc.source s USING (source_id)
WHERE
(d.lifecycle = 'stable' OR $scope = 'all')
AND (d.title ILIKE $q OR d.content_text ILIKE $q)
ORDER BY d.updated_at DESC
LIMIT $limit;
```
Returns:
``` json
{
"results": [
{ "doc_id": "...", "title": "...", "uri": "...", "git_sha": "..." }
]
}
```
------------------------------------------------------------------------
### 7.2 `doc.get`
Input:
``` json
{ "doc_id": "..." }
```
SQL:
``` sql
SELECT d.*, s.git_sha
FROM doc.document d
JOIN doc.source s USING (source_id)
WHERE d.doc_id = $1;
```
Returns full document with citation metadata.
------------------------------------------------------------------------
### 7.3 `doc.list_runbooks`
Filtered by:
- Path prefix
- Tag field (future enhancement)
------------------------------------------------------------------------
## 8. Vector Search (Phase 2)
Uses pgvector inside knoe-db.
Query example:
``` sql
WITH ranked AS (
SELECT c.doc_id,
1 - (e.embedding <=> $query_embedding) AS score
FROM doc.embedding e
JOIN doc.chunk c USING (chunk_id)
JOIN doc.document d USING (doc_id)
WHERE d.lifecycle = 'stable'
ORDER BY e.embedding <=> $query_embedding
LIMIT 20
)
SELECT DISTINCT doc_id FROM ranked;
```
Important:
- Vector search returns `doc_id` only.
- Final filtering and citations always use authoritative document
table.
Vector index is derived, not core.
------------------------------------------------------------------------
## 9. Security Model
- Next.js handles authentication (OAuth/session)
- MCP endpoint validates user
- Database role is read-only
- No filesystem reads
- No direct git access from MCP
- NetworkPolicy: only Next.js → Postgres
- No shell execution
------------------------------------------------------------------------
## 10. Versioning Model
Every answer includes:
- `doc://doc/{doc_id}`
- `git_sha`
- `lifecycle`
Stable answers reference only stable documents.
Reproducibility guarantee:
Given a `git_sha`, the answer corpus is reconstructible.
------------------------------------------------------------------------
## 11. Efficiency Rationale
- Single authoritative core (Postgres)
- No language-dependent core logic
- Native integration with Next.js ecosystem
- Vector search does not introduce a new source of truth
- Policy enforced at SQL layer
- Backup/restore handled by CNPG + Barman
------------------------------------------------------------------------
## Final Principle
**Postgres owns knowledge.\
Next.js exposes it.\
Everything else is replaceable.**