tegwick
b93df3aa68
W1: Document user-scope MCP config location in ~/.claude/CLAUDE.md —
adds verification and re-registration commands, warns against
settings.json (saves ~12K tokens per registration session).
W2: scripts/register_project.sh + make register-project —
5-step automation: API health → topic lookup → MCP check →
CLAUDE.md from template → progress event.
W3: state-hub/scripts/project_claude_md.template —
parameterised CLAUDE.md with {PROJECT_NAME}/{DOMAIN}/{TOPIC_ID}
placeholders; used by register_project.sh.
W4: Add custodian_topic_id + domain to all 6 canon project charters —
lets agents grep for topic IDs without touching the API.
W5: state-hub/mcp_server/TOOLS.md — compact 30-line tool reference
card; replaces reading the full server.py (~350 lines).
W6: Switch .mcp.json to absolute path + PYTHONPATH env so cwd is not
required; add scripts/patch_mcp_cwd.py for post-registration fix.
Update ~/.claude.json to match (cwd kept for belt-and-suspenders).
W7 (SessionStart hook) deferred: no SessionStart hook type in Claude
Code; PreToolUse with empty matcher fires before every tool call.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
42 lines
1.4 KiB
Markdown
42 lines
1.4 KiB
Markdown
---
|
|
id: CUST-PRJ-RAIL-2026-000001
|
|
type: charter
|
|
title: "Railiance — Project Charter v0.1"
|
|
status: active
|
|
owners: ["Bernd", "Custodian"]
|
|
created: "2026-02-24"
|
|
updated: "2026-02-24"
|
|
scope:
|
|
domains: ["Railiance"]
|
|
sensitivity: internal
|
|
tags: ["devops", "reliability", "automation", "sovereignty"]
|
|
custodian_topic_id: "ca369340-a64e-442e-98f1-a4fa7dc74a38"
|
|
domain: railiance
|
|
---
|
|
|
|
# Railiance — Project Charter v0.1
|
|
|
|
## Purpose
|
|
Build a robust, automated DevOps and operational reliability foundation that supports long-lived projects under sovereignty constraints (local-first, provider-independent).
|
|
|
|
## Problem
|
|
Modern stacks become brittle due to vendor coupling, hidden dependencies, and operational complexity. Founder-driven operations do not scale and do not survive absences.
|
|
|
|
## Outcome
|
|
A repeatable operational substrate:
|
|
- reproducible deployments
|
|
- automated backups and recovery drills
|
|
- integrity checks and audit trails
|
|
- secure secret management
|
|
- portable infrastructure templates
|
|
|
|
## Boundaries (v0.1)
|
|
- Focus on pragmatic reliability engineering and automation.
|
|
- Prefer boring, proven primitives over cleverness.
|
|
- No “platform for everyone” ambition until internal stability is proven.
|
|
|
|
## Success criteria (v0.1)
|
|
- One-click (or scripted) deploy + restore for the Custodian stack.
|
|
- Routine evidence: logs, checks, and recovery tests.
|
|
- Clear runbooks and minimal operational burden.
|