stack/docs/design/framework-constitution/debate/rebuttal-steward.md

# Rebuttal — OSS Steward & Security/Compliance Lens

**Author role:** OSS Steward & Security/Compliance

**Responding to:** position-architect.md, position-coder.md, position-contrarian.md,
position-devex.md, position-moonshot.md, position-aiml.md

**My original position:** position-steward.md

---

## Part 1 — Strongest Ideas from Other Personas Worth Keeping

### 1a. The DevEx lens on enforcement tiers is the most important cross-cutting insight

position-devex.md §DQ4 names something my position paper acknowledged but underweighted: **there
are two fundamentally different enforcement models in use today, and only one of them actually
enforces anything.** Pi gets the contract as a true system prompt via `--append-system-prompt`.
Claude, Codex, and OpenCode get a "please read these files" instruction in a user-editable memory
file. The DevEx paper (and the AIML paper independently) makes the enforcement-asymmetry concrete:
`runtime/claude/RUNTIME.md:30-32` already documents this lesson with respect to the memory-write
hook — "the rule alone proved insufficient — the hook is the hard gate." That sentence should be
promoted to Constitution doctrine, exactly as the DevEx paper proposes.

From a security posture: a hard gate enforced only by prose is not a hard gate. My position paper
proposed that "Constitution must be injection-resistant by position, not by instruction"
(position-steward.md §DQ4), but the DevEx paper gives this the operational teeth it needs —
specifically, that `mosaic claude` should inject L0 via `--append-system-prompt` and that
`~/.claude/CLAUDE.md` should be explicitly documented as a weaker fallback for bare `claude`
launches, not the primary enforcement path. This is strictly additive to my proposals and I
endorse it.

The capability-manifest idea (`adapters/<h>.capabilities.json`) is also worth keeping. My position
treated the adapter boundary as documentation; the DevEx formulation treats it as a machine-readable
contract that makes cross-harness gaps visible and auditable. This aligns directly with my S10
proposal (CI lint for deduplication) and extends it to per-gate enforcement coverage.

### 1b. The Contrarian on subtraction-first and the "rails" vs "tools" path drift

position-contrarian.md §DQ5 is right that adding a Constitution document without deleting the
four existing restatements produces five law files instead of four. The Contrarian is also the
only other paper that calls out the stale `rails/git/` path in `templates/agent/AGENTS.md.template`
as a concrete behavior-degrading bug — agents following the template's queue-guard command get
"no such file" on a live install because `install.sh:193` deletes the `rails` symlink. This is
exactly the kind of failure mode my lens exists to catch, and the Contrarian caught it more
explicitly than I did.

The Contrarian's hard cap of ~40 lines for L0 (versus my "~500 tokens target" in position-steward.md
§DQ5) is also the right order of magnitude and the more disciplined constraint. I accept it.

The "subtraction before structure" principle, while contrarian in framing, is security-consistent:
a shorter Constitution has fewer maintenance sites, fewer drift opportunities, and fewer lines
that can carry personal data under future commits. Deletion is a compliance control.

### 1c. The AIML lens on the `{{PLACEHOLDER}}` failure class

position-aiml.md §DQ2 introduces a failure class my sanitization section did not address:
a half-rendered template is *worse* than no file for an LLM. If `mosaic init` fails mid-render,
an agent that loads `You are **{{AGENT_NAME}}**` from `SOUL.md` may adopt the literal string
"{{AGENT_NAME}}" as a persona or treat the braces as an instruction artifact. The proposed
`mosaic-doctor` hard-fail on unrendered `{{...}}` or `${...}` tokens in any resident file is a
cheap, mechanical control that closes an entire failure class. I am adding it to my recommendation
set as S13 (below in §Part 3).

---

## Part 2 — Weakest or Riskiest Proposals

### 2a. The Moonshot's YAML front matter and hash-check launcher (position-moonshot.md §DQ1)

The Moonshot proposes adding `mosaic-layer:`, `mosaic-owner:`, and `mosaic-override:` YAML front
matter to each deployed file, with the launcher performing a content-hash check and refusing to
start if a layer-0 file has been structurally overridden.

This is the most dangerous-sounding "safety" proposal in the set, and my lens rejects it:

**Failure mode 1: the launcher is not the agent.** The hash-check-before-launch mechanism only
works if every agent session is launched through `mosaic <harness>`. A direct `claude` launch,
a Codex session launched through the platform's own tooling, or any future harness without a
wrapper binary bypasses the check entirely and silently. The DevEx paper already established that
three of four current harnesses enforce the contract only as a memory-file pointer — adding a
hash gate that those three harnesses cannot enforce is security theater that creates false
confidence.

**Failure mode 2: YAML front matter in an LLM context file is an injection surface.** A model
that reads front matter including `mosaic-override: forbidden` now has "forbidden" in its context
as a property of a rule. Adversarial prompt injection that adds `mosaic-override: allowed` to
a lower-layer file would read as a structural property to a naive parser, not as a contradiction
to check against the Constitution. The Constitution's injection-resistance guardrail
(currently `defaults/SOUL.md:48`, which I proposed promoting to L0) is the correct mitigation —
but it must not be undermined by teaching the model that override rules are expressed as parseable
properties.

**Failure mode 3: it blocks the alpha without adding OSS hygiene value.** A content-hash
check requires that the installed Constitution binary-match the shipped version. This breaks the
legitimate use case of a deployment that needs a localized version (translated docs, domain-specific
addendum to the gate list). My three-layer model already handles this by making L0 always-overwrite
on upgrade — that is the upgrade-safety mechanism, not hash enforcement. The Moonshot's mechanism
should be rejected for the alpha and reconsidered only after the simpler layer/directory boundary is
proven to work.

**Resolution:** keep the Moonshot's goal (detecting tampering with L0) but implement it via the
Contrarian's simpler mechanism: L0 is never in `PRESERVE_PATHS`, always overwritten, and
`mosaic doctor --check-constitution` compares checksums after-the-fact rather than blocking
launches. Advisory warnings are appropriate here; hard launch gates are not.

### 2b. The Architect's five-layer model and per-layer version stamps (position-architect.md §DQ1, §DQ3)

The Architect proposes five distinct layers (Constitution, Standards, Persona, Operator Policy,
Deployment/Runtime) with separate version stamps per layer (`constitution.version`,
`standards.version`, `user-schema.version`) and a three-way merge for user-seeded files.

The per-layer version stamp proposal has a concrete failure mode: **combinatorial migration matrix.**
If Constitution is at v5 and User schema is at v2, the installer must have tested and validated
the migration path for every `(constitution=N, user-schema=M)` combination where `N > M`. For a
project with a single maintainer shipping an alpha, this is a maintenance cliff. The Contrarian
named it: "Per-file pins create a combinatorial matrix of (framework vN, user pinned vM) states
that no one will test." The Architect's mechanism is correct in theory but wrong for an alpha
audience.

The five-layer model also introduces ambiguity about where the "operator policy" layer sits.
The Architect's smoking gun example — `defaults/AGENTS.md:37` ("Policy: Jason, 2026-06-11") —
is real and the fix is correct (move operator policy out of the Constitution), but creating a
dedicated `policy/*.md` layer for it adds a fourth always-resident file class when "USER.md has
a `## Operator Policy` section" is sufficient and simpler. The complexity should be justified by a
failure mode that a simpler design cannot handle. No one in this debate has named one.

**Resolution:** three layers (Constitution, Persona, Operator Profile) with a single
`FRAMEWORK_VERSION` integer plus the directory-boundary upgrade mechanism are sufficient for the
alpha. The Architect's per-layer stamps and three-way merge are good roadmap items for post-1.0.

### 2c. The DevEx on symlinks as the copy-on-link fix (position-devex.md §DQ3)

The DevEx paper proposes inverting the `mosaic-link-runtime-assets` policy to symlink
framework-owned runtime pointers and copy only user-editable surfaces. The principle is correct
(single source of truth, zero drift), but the concrete symlink proposal introduces a security
consideration that the paper acknowledges but does not fully resolve: Windows symlink support.

More critically for OSS hygiene: symlinks that point from `~/.claude/CLAUDE.md` into
`~/.config/mosaic/runtime/claude/RUNTIME.md` mean that the user's Claude harness now has a
persistent pointer into the mosaic config directory. If the mosaic config directory is mounted or
shared (e.g., in a container, in a dotfiles repo, in a shared dev environment), the symlink
exposes the entire `~/.config/mosaic/` tree to any process that can follow symlinks from the
Claude config location. The copy model, despite its drift risk, provides a natural isolation
boundary.

**Resolution:** keep the copy model as the default; add a `MOSAIC_SYMLINK_RUNTIME=1` opt-in
for users who understand the implications. This is already the DevEx paper's own caveat
(`MOSAIC_NO_SYMLINK=1` for Windows) — I am proposing it as the default rather than the
exception, because the privacy/isolation boundary matters more than the drift-elegance tradeoff
at alpha.

---

## Part 3 — Sharpened Key Disagreement: Who Bears Responsibility for PII Re-contamination

Every paper in this debate agrees on the diagnosis: personal data in shipped files, CI gate to
prevent it. There is no disagreement on the *what*. The disagreement my lens must sharpen is on
the *who bears ongoing responsibility and how the framework enforces it structurally, not procedurally.*

### The core disagreement

The Coder paper (position-coder.md §DQ2) describes the contamination as "surgical, not structural"
— approximately three files plus stray guide references. The DevEx paper counts 51 hits across 29
files. My position paper's evidence table lists 9 categories of violation. The Contrarian counts
55 raw occurrences across 30 files. **The disagreement about the contamination's extent reflects a
disagreement about the threat model:** is this a one-time cleanup or a structural re-contamination
risk?

The Moonshot names the ongoing risk most explicitly (position-moonshot.md §Biggest Risk): agents
running with the operator's SOUL.md and USER.md in context will generate framework-improvement PRs
that embed operator-specific terminology. The self-evolution rules in `defaults/AGENTS.md:136-139`
explicitly encourage this. Without a structural firewall, the framework re-contaminates itself
through its own best-practice enforcement.

### My lens's resolution

The re-contamination threat is structural, not one-time, because **the primary author of framework
improvements is an agent that always runs with operator-specific context.** This means:

1. **The CI grep is necessary but not sufficient.** Every paper agrees on the CI grep (denylist of
   `jarvis|jason|woltje|PDA` over `packages/mosaic/framework/` excluding `examples/` and test
   fixtures). That is S5 in my original proposals and it must be in the alpha DoD. But it only
   catches the operator's *current* identity tokens. A future operator who also runs Mosaic daily
   will contaminate the framework with *their* tokens, and no denylist written today will catch it.

2. **The structural fix is a "no operator context in framework PRs" rule enforced by the
   framework's own scaffolding.** Concretely: the `defaults/AGENTS.md` self-evolution rules
   (lines 136-139) must include a new hard constraint:

   > When capturing a `framework-improvement` or `tooling-gap` pattern to OpenBrain or proposing
   > a framework PR, you MUST NOT include content derived from SOUL.md, USER.md, or any
   > operator-specific context. Framework proposals must be operator-agnostic by construction.
   > If you cannot express the improvement without operator-specific language, that is a signal
   > the improvement belongs in `policy/` or a project `AGENTS.md`, not in the Constitution.

   This rule belongs in the Constitution (Layer 0) because it gates framework evolution, not
   just current sessions.

3. **The denylist must include a structural-category check, not just known tokens.** The CI grep
   should also fail on patterns like `~/src/<word>`, `/home/<word>/`, and any absolute home-dir
   path — not just the current operator's identifiers. This closes the class of violation, not
   just the current instances.

4. **The `CONTRIBUTING.md` I proposed (S12) must be written before the alpha tag, not deferred
   to pre-stable.** Contribution guidelines are the only mechanism that governs PRs from community
   contributors who are not running the CI grep locally. The BRIEF's backward-compatibility
   constraint and the "solid alpha release" goal both imply external contributors are in scope.
   A `CONTRIBUTING.md` without a section on operator-data hygiene is an invitation to
   re-contaminate.

5. **The missing LICENSE (my S1/S2) remains a blocker for everything else.** No other hygiene
   measure matters if the package has no legal open-source status. Under the Berne Convention,
   a publicly accessible repository without a license is "all rights reserved." Community
   contributors who submit PRs without a CLA or DCO have unclear IP status. This is the highest-
   severity finding in my original position and no other paper disputes it. It must be resolved
   before the alpha tag, because after the alpha tag there will be downstream users whose code
   depends on this package, and retroactively adding a license creates ambiguity about the
   pre-license period. **Ship with MIT + DCO on day zero.**

### Additional proposal from rebuttal review: S13

Based on the AIML paper's finding (position-aiml.md §DQ2), I am adding:

**S13 — mosaic-doctor hard-fail on unrendered tokens in resident files.** `mosaic-doctor` must
fail non-advisorily if any file in the resident set (`CONSTITUTION.md`/`AGENTS.md`, `SOUL.md`,
`USER.md`, `TOOLS.md`, any `RUNTIME.md`) contains a `{{...}}` or `${VAR}` token (excluding
documented `${VAR:-default}` safe-defaults tagged with `# safe-default:`). This closes the
half-rendered-template failure class, which is a security-adjacent concern: a mis-rendered SOUL
with placeholder tokens could cause an agent to adopt an arbitrary string as its governing
identity.

---

## Summary of Top Contentions

1. **LICENSE + DCO is a blocker for the alpha — no other proposal matters without it.** A
   public repository without a license is not open source. Ship MIT + a DCO CI check before
   the alpha tag; there is no valid reason to defer this.

2. **CI PII grep must close the structural contamination class, not just the current tokens.** The
   denylist must include absolute home-dir patterns (`~/src/<word>`, `/home/<user>/`) in addition
   to operator-specific identifiers. The self-evolution rules in AGENTS.md must prohibit operator
   context from entering framework PRs by explicit Constitution rule, not just by convention.

3. **The Moonshot's hash-check launcher gate is security theater for three of four harnesses and
   should be replaced by the simpler always-overwrite-L0 + post-hoc doctor check.** A launch-time
   guard that only works when `mosaic <harness>` is the entry point provides false confidence about
   direct launches, where the Constitution is weakest anyway.

4. **The Architect's five-layer model and per-layer version stamps are roadmap items, not alpha
   requirements.** Three layers (Constitution, Persona, Operator) with directory-level ownership and
   a single `FRAMEWORK_VERSION` integer are sufficient for the alpha and do not create a
   combinatorial migration test matrix.

5. **CONTRIBUTING.md and the re-contamination rule in AGENTS.md must ship with the alpha.** The
   self-evolution mechanism that allows agents to propose framework changes is a structural
   re-contamination risk. Procedure (contributing guide) and rule (Constitution constraint on
   framework-improvement proposals) are both required; neither alone is sufficient.