Files
dotfiles/claude/memory/feedback-mechanical-vs-architectural.md
T
David F GliddenandClaude Opus 4.8 3f9a89b00c chore(memory): Basic Memory trial begins — sync normalization baseline (283 files)
Basic Memory v0.21.6 first sync over the live memory dir (steward-authorized
live-dir trial, Option A 2026-06-06): adds permalink: to frontmatter, refolds
long YAML description lines, strips final newlines. Bodies untouched —
verified via full diff classification. From this commit forward, any diff in
claude/memory shows only what Basic Memory or the session writes.

Trial design: MemPalace untouched as incumbent; git status check on this dir
at every wrap; end-of-day evaluation (recall quality, sync robustness,
rebuild-from-files, malformed-file behavior).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-06 09:52:17 +02:00

4.2 KiB

name, description, type, originSessionId, permalink
name description type originSessionId permalink
Mechanical vs architectural — scope of executor-authored fixes on L1 territory Steward principle (2026-04-19) distinguishing fixes the steward+executor can author together on L1 code from fixes that belong to Seb or steward-with-Seb. Mechanical fixes are in scope; architectural changes are not. feedback a3ddbf34-da48-4129-acba-658f2f869783 claude-memory/feedback-mechanical-vs-architectural

Mechanical vs architectural — scope principle for L1 work

Under the new territory framing (steward joined Seb on L1 production), executor-authored fixes on BetterMemories.io code are scoped to mechanical changes. Architectural changes remain Seb's or steward-with-Seb's call, not executor-authored.

Why: Steward verbatim (2026-04-19): "For example, I would not touch an Architectural element, but mechanical, etc yes". The principle keeps code authorship aligned with the reviewer who has the design-shape intuition. Mechanical fixes are safe to author because their correctness is locally verifiable; architectural changes need the codebase author's perspective on design fit.

Classification

Mechanical (in scope for executor + steward):

  • Bug fixes to localized logic with no design-shape implication (e.g., #126's min-max degenerate case — a 3-line guard on existing logic).
  • Comment corrections when code reveals the comment is factually wrong.
  • Type-signature fixes, import path fixes, dead-code removal.
  • Test additions for known bugs.
  • Small defensive guards (null checks, range checks) that don't change behavior semantics on the happy path.
  • Minor refactors that preserve exact behavior (renames, extract-function, inline).

Architectural (out of scope — Seb's territory or escalated):

  • Design-shape changes: introducing a new mode, new state, new contract, new dispatch path.
  • Decisions about "what should happen when X" (error vs empty vs fallback vs degrade).
  • Cross-cutting invariant changes (L1/L2 boundary, logchain contract, module independence).
  • Integration shape between subsystems (hooks ↔ recall, slot graduation, etc.).
  • Performance strategy choices (O(N²) vs async post-hoc vs cap-batch vs cheap classifier).
  • Environment/runtime-state coupling decisions (battery-aware behavior, resource pressure responses).

Gray zone (flag explicitly, ask before acting):

  • Fixes that are mechanically small but have design implication (e.g., H3's ?? 'temporal_stats' fallthrough — 3-line fix but the new behavior is a design call).
  • Changes to defaults (env vars, threshold values) — mechanical to edit but semantic to decide.
  • Adding logging/telemetry — usually mechanical but can reveal PII or shift operational semantics.

How to apply

  • Before authoring a fix on BMF code: classify it as mechanical or architectural.
  • Mechanical: implement → test → PR as steward → Seb reviews.
  • Architectural: surface as [PROPOSAL] or brief note, let Seb author the fix (he has design-shape intuition we don't).
  • Gray zone: surface with the design question explicit, let steward decide whether to author or route to Seb.

Worked examples from 2026-04-19 L1 audit

Finding Classification Rationale
H1 / #126 min-max normalize clobber Mechanical Known edge case, 3-line guard on existing logic
BM25 score-range comment at query-router.ts:542-543 Mechanical Doc correction, zero behavior impact
H3 temporal ?? 'temporal_stats' fallthrough Gray zone Fix is tiny but "what SHOULD happen" is a design call
H2 battery suppression silent failure Architectural Whether/how to surface, fall back, or degrade is design
H4 agent events entering WM Architectural Hook integration shape, not a local bug
Entity O(N²) relationship inference Architectural Fix-space is wide (A-F options from forensic doc); choice is design
  • Territory framing: project-focus-april-may.md — steward joined Seb on L1.
  • Authorization-taxonomy: [FIX] (in scope) vs [PROPOSAL] / [ESCALATE] (architectural) per ~/CLAUDE.md.
  • Independent-review discipline: feedback-independent-specialist-authorization.md — always audit sub-agent returns via Symmetria.