---
title: Be Civic — Spec amendment proposals
type: spec
status: process doc (transitional — see "Going forward" below)
date: 2026-05-21
parent_spec: ../README.md
---

# Amendment proposals

This folder holds the **historical record** of proposals to amend the spec. Reconciled proposals live in `archive/`; that archive is the audit trail of how the spec evolved through rounds 6, 7, W19–W25.

## Going forward (post-W26 foundation sprint)

When `bc-specs` is carved out of `bc-operations/specs/` (Phase 4 of the workspace foundation sprint, plan at `~/projects/be-civic/bc-bmd/plan-2026-05-21-portal-foundation.md`), **amendments become PRs against `bc-specs`**, not new files in this folder.

- **Design conversation** still happens in `bc-operations/docs/<date>-<topic>.md` (bc-operations remains the research/scratch repo).
- **The amendment IS the PR** — branch off `bc-specs` main, edit the canonical spec file directly, open a PR describing the change. The PR description carries what used to be the "proposal" content: which sections amend, what schema deltas, open questions.
- **Cross-batch reconciliation** runs as a `bc-spec-reconciler` agent check on the PR — if multiple in-flight amendment PRs propose conflicting or interdependent changes, the reconciler surfaces it.
- **No new files in this folder** after the carve-out completes. The folder migrates whole to `bc-specs` as the historical archive; the workflow lives in `bc-specs`'s PR convention going forward.

## Until the carve-out completes

The legacy workflow (active only for in-flight bc-operations work between now and the Phase 4 migration — which should be no new amendments given the operator's pause on product work):

1. **Design conversation** in `bc-operations/docs/<date>-<topic>.md` — questions, alternatives, decisions, open issues.
2. **Proposal** in this folder (`<date>-<topic>.md`) — section-by-section deltas to the spec, schema deltas, open questions for reconciliation. **Do not write directly to `specs/<doc>.md` from a proposal.**
3. **Reconciliation pass** — operator reviews the proposal, pulls accepted changes into `specs/<doc>.md` with a status bump.
4. **Post-reconciliation** — proposal moves to `archive/` with `status: reconciled YYYY-MM-DD`.

## Invariants

- A proposal in this folder is **not authoritative** until reconciled. The spec docs (`architecture.md`, `schemas.md`, etc.) are the source of truth.
- A proposal MUST link to its parent design conversation in `bc-operations/docs/`.
- A proposal MUST identify **which spec sections it amends or adds**.
- A proposal MUST list **open questions for reconciliation** explicitly — these are the unresolved choices the operator settles during reconciliation.
- A proposal SHOULD include worked examples sufficient for the V0 build sprint to author entries against.

## Current proposals

| Proposal | Status | Target spec sections | Build target |
|---|---|---|---|
| [archive/2026-05-12-path-directory-concept.md](archive/2026-05-12-path-directory-concept.md) | RECONCILED 2026-05-12 into spec v0.5 | Landed: §6.12 Path Directory + amendments to §6.1/§6.2/§6.5/§6.6/§6.7/§6.9/§6.11 in `schemas.md`; §24.9 path traversal + §17 S69–S77 in `architecture.md`; §15.7 obligations 17–18 + §15.8 invariant 9 in `skills.md`; §8.7.2.2/§8.9.6/§8.10.4 in `privacy.md`; §9.5/§11/§11.1 in `lifecycle.md`; §23.2.1 path MCP tools in `protocol.md`; §20.11/§20.12 in `website.md`. Side effects: bc-corpus-creator content (research-report.md + evals.json schemas, §15.1 tooling paragraph, §15.2 usage-enum paragraph) moved out of product spec into new `specs/build-tools.md`. | V0 catalogue + harness wiring in v1 (per reconciliation decision D19) |