David F GliddenandClaude Opus 4.8
3f9a89b00c
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>
62 lines
4.2 KiB
Markdown
62 lines
4.2 KiB
Markdown
---
|
|
name: Mechanical vs architectural — scope of executor-authored fixes on L1 territory
|
|
description: 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.
|
|
type: feedback
|
|
originSessionId: a3ddbf34-da48-4129-acba-658f2f869783
|
|
permalink: 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 |
|
|
|
|
## Related
|
|
|
|
- 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. |