Elevation: world-class README + Pages landing, validate CI, governance

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,11 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Read the spec first
+    url: https://github.com/frankxai/bless/blob/main/SPEC.md
+    about: The Blessing Protocol — the file contract, ritual, schemas, voice.
+  - name: SIP substrate
+    url: https://github.com/frankxai/Starlight-Intelligence-System
+    about: The substrate the lowercase file-contract reconciles with.
+  - name: frankx.ai
+    url: https://frankx.ai
+    about: Frank's hub.

.github/ISSUE_TEMPLATE/proposal.yml

@@ -0,0 +1,35 @@
+name: Protocol proposal
+description: Propose a change or addition to the Blessing Protocol.
+title: "proposal: "
+labels: ["proposal"]
+body:
+  - type: textarea
+    id: problem
+    attributes:
+      label: The problem
+      description: What is missing or wrong today? Who experiences it?
+    validations:
+      required: true
+  - type: textarea
+    id: proposal
+    attributes:
+      label: The proposal
+      description: What you propose, concretely. Which file/schema/section it touches.
+    validations:
+      required: true
+  - type: dropdown
+    id: scope
+    attributes:
+      label: Scope
+      options:
+        - Additive (templates, docs, examples)
+        - File contract (the five files)
+        - Record or room schema
+        - Voice register
+        - Breaking change
+    validations:
+      required: true
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives considered

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,19 @@
+## What
+
+<!-- One or two sentences: what this changes in the protocol, templates, or docs. -->
+
+## Why
+
+<!-- The reason. Link an issue or proposal if there is one. -->
+
+## Spec impact
+
+- [ ] No change to the file contract / record schema / room schema
+- [ ] Additive change (templates, docs, examples)
+- [ ] Breaking change (bumps the protocol minor version + CHANGELOG)
+
+## Checklist
+
+- [ ] `node scripts/validate-protocol.mjs` passes
+- [ ] Voice stays in the grounded witness register (no spiritual-bypass vocabulary, SPEC §7)
+- [ ] CHANGELOG.md updated if the spec changed

.github/workflows/validate.yml

@@ -0,0 +1,18 @@
+name: Validate
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  validate:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: "20"
+      - name: Validate the Blessing Protocol
+        run: node scripts/validate-protocol.mjs

CODE_OF_CONDUCT.md

@@ -0,0 +1,17 @@
+# Code of Conduct
+
+This project follows the [Contributor Covenant](https://www.contributor-covenant.org/version/2/1/code_of_conduct/),
+version 2.1.
+
+We pledge to make participation a harassment-free experience for everyone. We act with respect, accept
+constructive feedback, and prioritize what is best for the community.
+
+Examples of unacceptable behavior: harassment, insulting or derogatory comments, publishing others'
+private information, and other conduct that would reasonably be considered inappropriate.
+
+Maintainers are responsible for clarifying standards and may remove contributions or contributors that
+violate this code.
+
+**Reporting:** contact **friemerx@gmail.com**. All reports are reviewed and handled confidentially.
+
+This Code of Conduct is adapted from the Contributor Covenant v2.1.

CONTRIBUTING.md

@@ -0,0 +1,77 @@
+# Contributing to bless
+
+`bless` is the open standard for the Blessing Protocol. It is small on purpose. Contributions
+are welcome — and the bar is restraint: the protocol earns its keep by staying legible, not by
+growing features.
+
+By participating you agree to the [Code of Conduct](CODE_OF_CONDUCT.md).
+
+---
+
+## Ways to contribute
+
+- **Adopt it.** Drop the [five files](README.md#the-five-files) into a repo and run a Sunday
+  ritual. Lived adoption is the most useful feedback the protocol can get.
+- **Extend a template.** Improve a starting template in [`templates/`](templates/) without
+  breaking the file contract in [`SPEC.md` §2](SPEC.md).
+- **Build a renderer.** A palace can render as HTML, React, Three.js, or print. The spec defines
+  the room schema ([`SPEC.md` §5](SPEC.md)); the renderer is yours.
+- **Propose a spec change.** Open a [proposal](https://github.com/frankxai/bless/issues/new/choose)
+  before sending a PR that touches `SPEC.md`, the file contract, or either schema.
+- **Fix the small things.** Typos, broken links, clarity. These are always welcome.
+
+---
+
+## Proposing a change to the spec
+
+The normative surface — the five-file contract, the `blessings.jsonl` record, the `rooms.json`
+room schema, the voice register — changes deliberately, never casually. Before opening a PR that
+touches any of it:
+
+1. **Open a proposal first.** Use the proposal form. State the problem, the smallest change that
+   solves it, and what it would break. A spec change with no stated problem will be closed.
+2. **Default to additive.** Additive changes (new optional fields, new enum values) are easy.
+   Breaking changes to the contract or a schema bump the minor version until v1.0 — they need a
+   clear reason and a migration note.
+3. **Respect the voice register.** Copy in this repo obeys [`SPEC.md` §7](SPEC.md): the allowed
+   vocabulary and the refused vocabulary are load-bearing, not stylistic. No spiritual-bypass
+   language, no AI-slop, no canon leak from any single brand's mythology into the protocol.
+4. **Keep the witness honest.** Nothing in a proposal may turn `bless` into a streak mechanic, a
+   guilt loop, or a metaphysical claim. Blessing means whole-at-this-moment closure — and only
+   that.
+
+---
+
+## Branch naming
+
+Branch off `main` with a typed prefix:
+
+| Prefix | For |
+|---|---|
+| `feat/` | A new template, renderer reference, or additive spec change |
+| `fix/` | A correction — broken link, typo, schema mismatch |
+| `docs/` | README, CONTRIBUTING, or other prose without behaviour change |
+
+Examples: `feat/rooms-schema-aurora-surface` · `fix/spec-section-anchor` · `docs/quick-start-clarity`.
+
+---
+
+## Before you open a PR
+
+- Run the validator locally: `node scripts/validate-protocol.mjs`. It must exit `0`.
+- Keep the change surgical. Touch only what the proposal named.
+- If you added or renamed a template, make sure `SPEC.md` still references all five files plus
+  `weekly.md`, and that the validator still passes.
+- Fill out the PR template: What / Why / Spec impact / Checklist.
+
+CI runs the same validator on every push and pull request to `main`. A green check is the gate.
+
+---
+
+## Reviews
+
+PRs are reviewed for: correctness against the spec, restraint (does this need to exist?), and
+voice. A change that passes the validator but fails restraint will be sent back. The answer is
+usually less.
+
+Built on SIP · The Blessing Protocol v0.1 · MIT

README.md

@@ -1,6 +1,22 @@
+<div align="center">
+
+<img src=".github/hero.svg" alt="bless — The Blessing Protocol: witness the week, grow a palace." width="100%">
+
 # bless
 
-**The Blessing Protocol** — a weekly, agentic practice for *witnessing* the work you ship and *growing a palace* from it.
+*The Blessing Protocol — a weekly, agentic practice for witnessing the work you ship and growing a palace from it.*
+
+[![License: MIT](https://img.shields.io/badge/License-MIT-f4c97a.svg)](LICENSE)
+[![Built on SIP](https://img.shields.io/badge/Built%20on-SIP-c9b6ff.svg)](https://github.com/frankxai/Starlight-Intelligence-System)
+[![Blessing Protocol](https://img.shields.io/badge/Blessing%20Protocol-v0.1-f4c97a.svg)](SPEC.md)
+[![Validate](https://github.com/frankxai/bless/actions/workflows/validate.yml/badge.svg)](https://github.com/frankxai/bless/actions/workflows/validate.yml)
+[![PRs Welcome](https://img.shields.io/badge/PRs-welcome-c9b6ff.svg)](CONTRIBUTING.md)
+
+[**Why**](#why-this-exists) · [**The five files**](#the-five-files) · [**The weekly loop**](#the-weekly-loop) · [**Quick start**](#quick-start) · [**What blessing means**](#what-blessing-means-precise) · [**Spec**](SPEC.md) · [**Contribute**](CONTRIBUTING.md)
+
+</div>
+
+---
 
 > Work for six days. On the seventh, bless the work.
 
@@ -38,17 +54,14 @@ Lowercase by intent: these are the **public builder tier**. They reconcile with
 
 ## The weekly loop
 
-```
-   your GitHub + connectors
-            │   ingest  (agent reads the week)
-            ▼
-        bless.md  ──── witness the week, ratify what is whole
-            │   append
-            ▼
-       palace.md  ──── each blessed thing becomes a room
-            │   build
-            ▼
-        a palace  ──── HTML / React / Three.js — grows each Sunday
+Each Sunday, an agent reads the week, the ritual ratifies what is whole, and the palace accrues one ring of rooms.
+
+```mermaid
+graph TD
+    A["your GitHub + connectors"] -->|ingest · agent reads the week| B["bless.md<br/>witness the week, ratify what is whole"]
+    B -->|append| C["palace.md<br/>each blessed thing becomes a room"]
+    C -->|build| D["a palace<br/>HTML · React · Three.js — grows each Sunday"]
+    D -.->|next Sunday| A
 ```
 
 1. **Ingest.** An agent rolls your week's commits across repos and surfaces what changed.
@@ -81,10 +94,23 @@ You do not need the full toolchain to start. The minimum viable practice is `ble
 
 Blessing is not permanent and not a promotion. New facts can break wholeness; new ambition can compose new rooms. When that happens, the next week's witness records it. Until then, the blessing stands.
 
+The normative definition, the refusals the ritual must honor, the ledger and room schemas, and the SIP reconciliation all live in [`SPEC.md`](SPEC.md). The honest claim a practitioner may carry lives in [`ATTESTATION.md`](ATTESTATION.md).
+
 ---
 
 ## License
 
 MIT. The spec, the templates, the file contract — open forever. See [`LICENSE`](LICENSE).
 
-Built on SIP · The Blessing Protocol v0.1
+---
+
+## The Blessing family
+
+| Repo | Role |
+|---|---|
+| [**bless**](https://github.com/frankxai/bless) | The open standard — the Blessing Protocol |
+| [**mind-palace-agent-skills**](https://github.com/frankxai/mind-palace-agent-skills) | Portable agent skills — ingest · witness · grow |
+| [**frankx-mind-palace**](https://github.com/frankxai/frankx-mind-palace) | The mind — Frank's blessed work as data |
+| [**frankx-palace**](https://github.com/frankxai/frankx-palace) | The palace — the 3D memory palace that grows each Sunday |
+
+<sub>Built on SIP · The Blessing Protocol v0.1 · MIT</sub>