feat: markdown-first architecture (Phases 1-6)

.github/workflows/seed-standards.yml

@@ -0,0 +1,37 @@
+name: Seed Standards to R2
+
+on:
+  push:
+    branches: [main]
+    paths:
+      - 'content/standards/**'
+      - 'scripts/seed-standards.ts'
+      - '.github/workflows/seed-standards.yml'
+
+concurrency:
+  group: seed-standards-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  seed:
+    runs-on: ubuntu-latest
+    timeout-minutes: 5
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '22'
+
+      - name: Install tsx
+        run: npm install -g tsx
+
+      - name: Install wrangler
+        run: npm install -g wrangler
+
+      - name: Seed standards to R2
+        run: npx tsx scripts/seed-standards.ts --remote
+        env:
+          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
+          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

config/claude/commands/backpressure-review.md

@@ -0,0 +1,97 @@
+# Backpressure Review
+
+Deep review of this project against the quality enforcement strategy. This command handles the judgment-based checks that deterministic tools cannot cover.
+
+## Instructions
+
+First, fetch the `sveltekit-backpressure` standard from the esolia-standards MCP server (or read `docs/shared/guides/SVELTEKIT_BACKPRESSURE.md` if available locally).
+
+Perform the following review, then output a structured report.
+
+### 1. Type system audit
+
+Examine `src/app.d.ts` (or equivalent):
+
+- Is `Locals.user` a simple `User | null`, or a discriminated union that forces exhaustive handling?
+- Is there a `TenantContext` type (or equivalent) that makes unscoped queries structurally impossible?
+- Are load function return types narrow and explicit (using `satisfies`), or wide and trusting?
+
+Rate: strong / adequate / weak. Recommend specific changes.
+
+### 2. Data boundary validation
+
+Search for D1 query patterns (`db.prepare`, `.first()`, `.all()`, `.batch()`):
+
+- Are results validated through Zod schemas at the boundary, or cast with `as`?
+- Is `safeParse()` used in form actions and API routes, or bare `.parse()`?
+- Are there raw `db.prepare()` calls scattered across load functions, or centralized in a query helper module?
+
+Rate: strong / adequate / weak. Count the violations.
+
+### 3. CLAUDE.md audit
+
+Read this project's `CLAUDE.md` and identify every "always" or "never" statement. For each one, assess:
+
+| Statement | Can be a type? | Can be a lint rule? | Can be a test? | Should stay in CLAUDE.md? |
+| --------- | -------------- | ------------------- | -------------- | ------------------------- |
+
+Statements that can be mechanically enforced should migrate out of CLAUDE.md.
+
+### 4. Lint rule coverage
+
+Check the linting configuration against the `linting-strategy` standard:
+
+- Is oxlint installed with `.oxlintrc.json`?
+- Is `eslint-plugin-svelte` configured for Svelte 5?
+- Is `eslint-plugin-oxlint` placed last in flat config?
+- Are custom backpressure rules implemented?
+- Does `package.json` chain oxlint before eslint?
+
+Rate: strong / adequate / weak.
+
+### 5. Test coverage assessment
+
+- Are there unit tests for utility functions?
+- Are there contract tests for D1/R2/KV behaviors?
+- Is there a `verify` script that chains all checks?
+- What's the most impactful missing test?
+
+### 6. Tenant isolation
+
+For multi-tenant repos:
+
+- Are queries scoped via a helper module?
+- Could an AI-generated load function skip the tenant filter?
+- Would the type system catch it?
+
+## Output format
+
+Write to `docs/backpressure-review.md`:
+
+```markdown
+# Backpressure Review — [project name]
+
+**Date:** [today]
+**Overall readiness:** [Phase 1 / Phase 2 / Phase 3 / Phase 4]
+
+## Scorecard
+
+| Area             | Rating                   | Key finding |
+| ---------------- | ------------------------ | ----------- |
+| Type system      | strong/adequate/weak     | ...         |
+| Data boundaries  | strong/adequate/weak     | ...         |
+| CLAUDE.md        | strong/adequate/weak     | ...         |
+| Lint rules       | strong/adequate/weak     | ...         |
+| Test coverage    | strong/adequate/weak     | ...         |
+| Tenant isolation | strong/adequate/weak/n-a | ...         |
+
+## Recommended next actions
+
+1. [highest-impact action]
+2. [second action]
+3. [third action]
+
+## Detailed findings
+
+[One section per area above]
+```

config/claude/commands/seo-setup.md

@@ -0,0 +1,47 @@
+# SEO Setup
+
+Apply the SEO checklist to this project. Works with SvelteKit, Hono, and generic web projects. Checks trailing slashes, meta tags, JSON-LD, sitemap, robots.txt, and optionally installs a CI workflow.
+
+## Instructions
+
+Fetch the `sveltekit-seo-checklist` standard from the esolia-standards MCP server (or read `docs/shared/guides/SVELTEKIT_SEO_CHECKLIST.md` if available locally).
+
+Arguments: $ARGUMENTS — Optional: "audit" (report only, no changes) or "ci" (only install the CI workflow).
+
+### 1. Detect the framework
+
+Read `package.json` and determine the project type:
+
+- **SvelteKit**: has `@sveltejs/kit` in dependencies
+- **Hono**: has `hono` in dependencies
+- **Generic**: anything else
+
+### 2. Understand the project
+
+- Read `package.json` for dependencies and scripts
+- Check for `content/` directory (markdown content pipeline)
+- Check for existing `static/sitemap.xml`, `static/robots.txt`
+- Check for existing security headers configuration
+
+### 3. Audit current SEO state
+
+| Check              | Status | Notes |
+| ------------------ | ------ | ----- |
+| Trailing slashes   | ?      |       |
+| Meta tags          | ?      |       |
+| Canonical URL      | ?      |       |
+| OG tags            | ?      |       |
+| Title/desc lengths | ?      |       |
+| JSON-LD            | ?      |       |
+| Sitemap            | ?      |       |
+| robots.txt         | ?      |       |
+| Security headers   | ?      |       |
+| hreflang           | ?      |       |
+
+If `$ARGUMENTS` is "audit", stop here.
+
+### 4. Install fixes and CI workflow
+
+Apply fixes for each failing check. Install the SEO test suite and CI workflow as appropriate.
+
+**Do not commit — let the user review first.**

config/claude/commands/update-diagram.md

@@ -0,0 +1,56 @@
+---
+allowed-tools: Bash(npx wrangler d1 execute:*), Bash(npx tsx scripts/export-diagram-yaml.ts:*), Read
+description: Update a Hanawa Mermaid diagram fragment
+---
+
+## Hanawa Diagram Update Workflow
+
+This command updates Mermaid diagram fragments in the Hanawa CMS.
+
+### Reference
+
+Fetch the `mermaid-compact-reference` standard from the esolia-standards MCP server for syntax reference.
+
+### Database Info
+
+- Database: `hanawa-db`
+- Table: `fragments`
+- Columns: `content_en`, `content_ja` (HTML with `data-source` attribute containing Mermaid)
+
+### Update Process
+
+1. **Get current content** (if needed):
+```bash
+npx wrangler d1 execute hanawa-db --remote --command "SELECT content_en, content_ja FROM fragments WHERE id = '{fragment-id}'"
+```
+
+2. **Update D1** with new Mermaid content (properly escaped)
+
+3. **User clicks Export** in Hanawa UI to regenerate SVGs
+
+4. **Backup to YAML**:
+```bash
+npx tsx scripts/export-diagram-yaml.ts {fragment-id}
+```
+
+### HTML Escaping Rules
+
+In SQL/data-source attribute:
+- `'` → `''` (SQL)
+- `"` → `"`
+- `<` → `&lt;`
+- `>` → `&gt;`
+- `&` → `&amp;`
+
+### Your Task
+
+User will specify:
+1. Fragment ID (e.g., `password-vault-master-password`)
+2. Requested changes (text, layout, etc.)
+
+Steps:
+1. Read current content if needed
+2. Generate updated Mermaid for EN and JA
+3. Update D1 with proper escaping
+4. Remind user to click Export in UI
+5. Run backup script

config/claude/mcp.json.example

@@ -0,0 +1,12 @@
+{
+  "mcpServers": {
+    "esolia-standards": {
+      "type": "url",
+      "url": "https://esolia-standards-mcp.YOUR_SUBDOMAIN.workers.dev/sse",
+      "headers": {
+        "Authorization": "Bearer YOUR_SHARED_SECRET"
+      },
+      "note": "Replace YOUR_SUBDOMAIN and YOUR_SHARED_SECRET. If no auth is configured, remove the headers block."
+    }
+  }
+}

config/claude/rules/backpressure-verify.md

@@ -0,0 +1,21 @@
+# Backpressure Verification Rule
+
+After generating or modifying SvelteKit code (Svelte components, server routes, API endpoints, hooks), always run the project's preflight checks before presenting results.
+
+## Verification steps
+
+1. Run `npm run verify` (or the manual chain: `oxlint --config .oxlintrc.json && eslint . && svelte-kit sync && svelte-check --tsconfig ./tsconfig.json`)
+2. If checks fail, read the errors, fix the code, and re-run until clean
+3. Only present the result to the user after all checks pass
+
+The `verify` script should chain: oxlint (fast pass) → eslint (Svelte + custom rules) → svelte-check (types) → vitest (unit tests). See the `linting-strategy` standard via the esolia-standards MCP server for the full setup.
+
+## Quality principles
+
+- Prefer `safeParse()` over `.parse()` for Zod schemas in form actions and API routes
+- Never use `{@html expr}` without wrapping in `sanitizeHtml()` from `$lib/sanitize.ts`
+- Never return platform bindings (`platform.env.*`) from load functions
+- Use parameterized queries (`.bind()`) — never interpolate values into SQL strings
+- Include tenant isolation (`org_id` / `client_id`) in all multi-tenant queries
+
+These are reminders — the type system and lint rules should enforce them mechanically. If you find yourself relying on this rule to catch errors that a type or lint rule could catch instead, note it for the developer.

config/claude/rules/security-standards.md

@@ -0,0 +1,39 @@
+# Security Standards Rule
+
+All eSolia code must follow OWASP Top 10 and ISO 27001 security standards.
+
+## OWASP Top 10 Checklist
+
+| ID | Category | Requirement |
+|----|----------|-------------|
+| A01 | Access Control | Validate authorization, least privilege |
+| A02 | Crypto Failures | Strong encryption, secure key management |
+| A03 | Injection | Parameterized queries, input sanitization |
+| A04 | Insecure Design | Security-first architecture |
+| A05 | Misconfiguration | Secure defaults, proper error handling |
+| A06 | Vulnerable Components | Dependency auditing |
+| A07 | Auth Failures | Strong authentication mechanisms |
+| A08 | Data Integrity | Validate processing operations |
+| A09 | Logging Failures | Log security events, no sensitive data in logs |
+| A10 | SSRF | Validate external requests |
+
+## InfoSec Comments
+
+Add `InfoSec:` comments for changes to:
+- Input validation / sanitization
+- Authentication / authorization
+- Cryptographic operations
+- Error handling
+- Dependency updates
+- Rate limiting / DoS protection
+- Security headers / CORS
+- Logging modifications
+
+## Commit Format
+
+Security-relevant commits must include:
+```
+type(scope): description
+
+InfoSec: [security impact/consideration]
+```

content/fragments/capabilities/continuous-monitoring.en.md

@@ -0,0 +1,52 @@
+---
+id: continuous-monitoring
+language: en
+title: Continuous Security Monitoring
+category: capabilities
+type: capability-description
+version: 2025-01
+status: production
+tags:
+  - "security"
+  - "monitoring"
+  - "compliance"
+sensitivity: normal
+author: rick.cogley@esolia.co.jp
+created: 2025-01-08
+---
+
+## Proactive Security Monitoring
+
+Stay ahead of threats with continuous monitoring that detects issues before they become incidents:
+
+**Real-time Threat Detection**
+- 24/7 monitoring of your infrastructure
+- Automated anomaly detection
+- Correlation of events across systems
+- Immediate alerting on suspicious activity
+
+**Vulnerability Management**
+- Regular security scans
+- Prioritized remediation recommendations
+- Tracking of patch status
+- Third-party component monitoring
+
+**Compliance Tracking**
+- Continuous control assessment
+- Evidence collection for audits
+- Gap analysis and remediation planning
+- Regular compliance reporting
+
+**Security Dashboards**
+- Executive-level security posture overview
+- Trend analysis and historical data
+- Risk scoring and prioritization
+- Exportable reports for stakeholders
+
+**Incident Response**
+- Defined escalation procedures
+- Rapid containment capabilities
+- Post-incident analysis and reporting
+- Lessons learned integration
+
+All monitoring is managed by eSolia's security team, with regular reviews and recommendations for improvement.