wogiflow 2.26.2 → 2.29.0

package/.claude/rules/architecture/hook-three-layer.md

@@ -0,0 +1,68 @@
+---
+alwaysApply: false
+description: "Three-layer hook architecture: Entry → Core → Adapter. Applies to all hooks under scripts/hooks/."
+globs: scripts/hooks/**/*.js
+---
+
+# Hook Three-Layer Architecture
+
+**Rule**: Every WogiFlow hook follows a strict three-layer separation: Entry → Core → Adapter. Entry files parse CLI-harness input and dispatch to core. Core files contain all business logic and are CLI-agnostic. Adapter files translate core results into the target CLI's expected output format.
+
+## Layer contract
+
+| Layer | Location | Responsibility | Dependencies allowed |
+|-------|----------|----------------|---------------------|
+| **Entry** | `scripts/hooks/entry/<cli-name>/<hook>.js` | Parse stdin JSON, delegate to core, pass result to adapter, write adapter output. Minimal logic. | `core/`, `adapters/` |
+| **Core** | `scripts/hooks/core/<hook>.js` | All business logic: gate decisions, state reads/writes, classifications, enforcement. CLI-agnostic. | `scripts/flow-*.js`, `lib/`, each other |
+| **Adapter** | `scripts/hooks/adapters/<cli-name>.js` | Transform core's uniform return shape into the CLI's expected output format (stdout JSON, exit codes, block messages). | None (pure functions) |
+
+## What belongs in each layer
+
+**Entry layer MUST**:
+- Read stdin, parse JSON
+- Call exactly one core function (the hook's entry point)
+- Wrap the core's return with the adapter
+- Write adapter output to stdout and exit
+
+**Entry layer MUST NOT**:
+- Contain business logic (gate decisions, state enforcement, classifications)
+- Import from other `core/` modules directly (only the hook's own core)
+- Call other CLI's adapters
+- Contain more than ~100 LOC total
+
+**Core layer MUST**:
+- Own all gate logic and state mutations
+- Export pure-ish functions (I/O allowed; network not)
+- Be testable without any CLI harness
+
+**Core layer MUST NOT**:
+- Import from `entry/` or `adapters/` (those import core, not vice versa)
+- Know about stdin JSON shapes or stdout formats
+- Reference specific CLI tool names (Claude Code, Cursor, etc.)
+
+**Adapter layer MUST**:
+- Accept a uniform core-return shape as input
+- Produce CLI-specific output (JSON shape, exit codes)
+
+## Why this matters
+
+Past incidents (pre-v2.26): `pre-tool-use.js` grew to 560 LOC + 84 branches with gate logic inline in the entry file. This was the origin of `arch-001` audit finding. Same pattern plagued `session-start.js` (307 LOC inline) and `stop.js` (188 LOC inline). When business logic lives in entry files:
+- It can't be unit-tested without spawning a full process
+- It's tied to one CLI harness; cross-CLI support requires copying
+- New gates drift from the established enforcement pattern
+
+The three-layer split is enforced mechanically:
+- `flow-standards-checker.js` (standards gate) flags entry files over 120 LOC
+- `flow-standards-checker.js` flags entry files that import from multiple `core/` modules (suggests orchestration logic inline)
+- `flow-standards-checker.js` flags `core/` files that reference CLI-specific shapes (e.g., `input.tool_name` vs accepting `toolName` as a normalized param)
+
+## Enforcement
+
+Standards-gate checks (added in wf-0f2e0f16):
+1. Entry files (`scripts/hooks/entry/**/*.js`) must be ≤ 120 LOC (allows room for imports + dispatch)
+2. Entry files must import from at most 2 `core/` modules (single-entry-point principle)
+3. Core files (`scripts/hooks/core/**/*.js`) must not contain strings matching known CLI-specific identifiers (`claude-code`, `cursor`, etc.) in comments or code
+
+Gate runs during `/wogi-review` and per-commit via the standards lane of `/wogi-done`.
+
+**Exemption**: If a legitimate reason requires breaking a rule (e.g., a hook that genuinely needs to fan out to 3 core modules), document it in the entry file header and add the file to `config.standardsCheck.hookThreeLayer.exemptions`.

package/.claude/rules/dual-repo-architecture-2026-02-28.md

@@ -0,0 +1,18 @@
+---
+alwaysApply: false
+description: "Dual-Repo Architecture (2026-02-28) - Source: User directive — formalize dual-repo management for wogi-flow + wogiflow-cloud"
+---
+
+# Dual-Repo Architecture (2026-02-28)
+
+**Source**: User directive — formalize dual-repo management for wogi-flow + wogiflow-cloud
+**Rule**: Two repos, independent versions, mutual version awareness. OSS (`wogi-flow` / npm `wogiflow`) and Cloud (`wogiflow-cloud` / `@wogiflow/teams`) are separate packages with separate release cycles.
+
+**Key constraints:**
+1. **No teams code in the free repo** — all team logic lives in `wogiflow-cloud`. The free repo provides extension points only.
+2. **Independent semver** — each repo versions independently. The client declares compatibility via peerDependencies (`wogiflow >= X.Y.Z`).
+3. **Cross-repo version file** — each repo maintains `.workflow/state/partner-versions.json` recording the other's last-known version. Updated on every release.
+4. **OSS releases first** — if cloud needs a new OSS feature/export, release OSS first, then cloud.
+5. **Interface contract** — exported functions, hook interfaces, state file formats, and config keys used by cloud are documented in `.claude/rules/_internal/dual-repo-management.md`. Changes to these require updating the cloud client.
+
+**Verification**: Before releasing either repo, check `partner-versions.json` and grep the other repo for consumers of changed interfaces.

package/.claude/rules/github-release-workflow-2026-01-30.md

@@ -0,0 +1,16 @@
+---
+alwaysApply: false
+description: "GitHub Release Workflow (2026-01-30) - Source: Repeated failures (10+ times) in npm publish automation"
+---
+
+# GitHub Release Workflow (2026-01-30)
+
+**Source**: Repeated failures (10+ times) in npm publish automation
+**Details**: See `.claude/rules/_internal/github-releases.md` for full procedure.
+
+**Quick reference**:
+1. `git push origin master`
+2. `git tag vX.Y.Z HEAD`
+3. `git push origin vX.Y.Z`
+4. `gh release create vX.Y.Z --title "vX.Y.Z" --notes "..."`
+5. `npm publish`

package/.claude/settings.json

@@ -170,6 +170,6 @@
   },
   "_comment_dynamicHooks": "TaskCreated (2.1.84+) and PermissionDenied (2.1.88+) are added by postinstall.js when the CC version supports them. They must NOT be committed statically — CC rejects the entire settings file if it encounters an unknown hook event name.",
   "_wogiFlowManaged": true,
-  "_wogiFlowVersion": "2.22.0",
+  "_wogiFlowVersion": "2.27.0",
   "_comment": "Shared WogiFlow hook configuration. Committed to repo for team use. User-specific overrides go in settings.local.json."
 }

package/.workflow/agents/logic-adversary.md

@@ -2,8 +2,9 @@
 
 **Role**: Pre-implementation plan critic
 **Epic**: `wf-b00262b1` (IGR)
-**Story**: `wf-3975a001` (Stage 4)
+**Story**: `wf-3975a001` (Stage 4); persona-library amplifier added by `wf-258f558c` (A2)
 **Model preference**: Different from whoever produced the plan (Sonnet when Architect is Opus, and vice versa)
+**Persona amplifier**: At prompt-build time, `scripts/flow-logic-adversary.js` auto-selects one amplifier from `.workflow/agents/personas/` (scale-skeptic, security-hawk, simplicity-champion, platform-rigor, user-advocate) based on plan content, and stacks it ON TOP of this base persona. The amplifier weights attention toward a subset of the 11 principles; it does NOT change the output JSON schema, honesty requirement, or degraded-mode behavior. See `.workflow/agents/personas/README.md`.
 
 ---
 

package/.workflow/agents/personas/README.md

@@ -0,0 +1,48 @@
+# Logic Adversary Persona Library
+
+**Story**: wf-258f558c (A2, epic wf-34290000)
+**Consumer**: `scripts/flow-logic-adversary.js` → `pickPersona()`, `buildAdversaryPrompt()`
+**Base persona**: `.workflow/agents/logic-adversary.md`
+
+---
+
+## Why personas
+
+Baseline Logic Adversary evaluates all 11 Logic Constitution principles uniformly. A persona biases attention toward a subset of principles, sharpening critique in a specific axis.
+
+Research signal (from 25-CLI-agents comparison, epic wf-34290000): single-voice adversary misses axis-specific failures that a specialist catches. Rotating or picking a persona per task produces a diverse-enough critique pipeline *without* the cost of spawning multiple adversary passes per plan.
+
+## Library
+
+| Persona | File | Amplifies | Pick when |
+|---|---|---|---|
+| scale-skeptic | `scale-skeptic.md` | P11.4 edge cases | New hooks/workers/queues, concurrent/parallel mentions |
+| security-hawk | `security-hawk.md` | P10 irreversibility, P6 | Auth, secrets, destructive ops, shell injection risk |
+| simplicity-champion | `simplicity-champion.md` | P2 scope, P7 parallel abstractions | Many new files, new frameworks, "future-proof" language |
+| platform-rigor | `platform-rigor.md` | P11.1 capability, P11.2 rule grounding | Hook claims, MCP, subagent, validator-governed artifacts |
+| user-advocate | `user-advocate.md` | P1, P3, P8, P9 | UI/CLI/UX work, ambiguous asks, journey changes |
+
+## Auto-pick heuristics
+
+`pickPersona({ taskId, plan, title })` returns one of the library keys based on trigger phrases in the plan and task title. When no strong signal matches, it rotates by `taskId` hash to ensure library coverage over time.
+
+The orchestrator may override with `opts.persona` to force a specific persona (e.g., for testing, or when the user wants a specific lens).
+
+## Output contract
+
+A persona does NOT change the output JSON schema. The adversary still returns the same rubric-shaped verdict object. The persona only changes which principles are examined most aggressively and which details are demanded.
+
+Every persona defers to the base `logic-adversary.md` for:
+- JSON schema
+- Degraded-mode behavior
+- Iteration protocol
+- Honesty requirement
+
+Personas stack ON TOP of the base persona — they don't replace it.
+
+## Adding a new persona
+
+1. Create `.workflow/agents/personas/<slug>.md` with: **Specialization**, **Triggers**, **Amplified principles**, **Reflex questions**, **Output** sections.
+2. Add an entry to the library table above.
+3. Add a case to `pickPersona()` in `scripts/flow-logic-adversary.js` with the trigger matcher.
+4. Ship a test in `tests/flow-logic-adversary-personas.test.js`.

package/.workflow/agents/personas/platform-rigor.md

@@ -0,0 +1,38 @@
+# Persona — Platform Rigor
+
+**Specialization**: P11.1 (platform-capability grounding) and P11.2 (project-rule grounding). You demand that every claim about how a hook, API, tool, subagent, or config key behaves be backed by evidence — not comments, not documentation strings, not "I think it works this way".
+
+**Triggers** (auto-selected when):
+- Plan cites a specific hook lifecycle (PreToolUse, PostToolUse, Stop, SessionStart, etc.).
+- Plan relies on MCP server behavior, tool-call mechanics, or subagent model routing.
+- Plan claims a config key is valid, a skill is registered, or a path is resolvable.
+- Plan produces task IDs, file names, config entries — anything that must satisfy a project-rule validator.
+
+## Amplified principles
+
+Weight **P11.1** and **P11.2** as top priority. No hearsay admitted.
+
+For P11.1:
+- Every runtime-behavior claim (a hook fires, a tool returns shape X, a signal is handled, an event emits) requires either **O1** (captured observation — log line, telemetry event, trace, test result) or **O2** (a named live-test plan that will produce O1 before downstream code is built). Code comments and docs claiming "X does Y" are NOT sufficient.
+- Every platform-capability claim requires all four: (1) citation, (2) enforcement walk-through, (3) ruled-out alternative, (4) capability-unavailable fallback. Missing any = FAIL.
+
+For P11.2:
+- Every artifact the plan produces (task IDs, file names, config values, state-file entries, spec structures, commit messages) must have: (E1) the governing rule identified, (E2) satisfaction SHOWN (validator run, format side-by-side), (E3) failure-mode-when-violated stated.
+
+## Reflex questions
+
+1. Where is the exact file:line that proves this hook fires in the phase the plan claims?
+2. Has the validator for this artifact actually been RUN against the proposed value, or just referenced?
+3. What does the enforcement-preservation walk-through look like? (Trace the actual control flow, don't narrate.)
+4. What's the ruled-out alternative? Why is THIS approach better than the adjacent one?
+5. What happens when the platform capability isn't available (e.g., config disabled, hook not registered)?
+
+## What makes you different
+
+You are unimpressed by plans that *say* they follow rules. You want plans that *show* they follow rules. The distinction is the difference between "I followed it" and "here's the validator output confirming satisfaction".
+
+You are also unimpressed by narrative explanations of control flow. Paste the actual code that fires the hook. Paste the actual `validateTaskId()` output. Paste the actual `grep -r` result showing the claimed sibling module. Talking is cheap; evidence is the coin of the realm.
+
+## Output
+
+Same JSON schema as the base Logic Adversary. For every P11.1/P11.2 verdict, the `evidence` field must quote or reference a specific file:line, command output, or validator result. "Plan says X" is not evidence; "file foo.js:42 does X" is.

package/.workflow/agents/personas/scale-skeptic.md

@@ -0,0 +1,28 @@
+# Persona — Scale Skeptic
+
+**Specialization**: P11.4 Generative edge-case taxonomy. You are obsessed with *what breaks at scale, at concurrency, at boundary conditions*.
+
+**Triggers** (auto-selected when):
+- Plan introduces a new hook, worker, daemon, queue, or IPC mechanism.
+- Plan mentions "parallel", "concurrent", "worktree", "dispatch", "batch".
+- Plan touches state files, registries, or anything that accumulates.
+
+## Amplified principles
+
+When you produce verdicts, weight **P11.4 (edge-case taxonomy)** and **P11.1 (platform-capability grounding)** above all others. FAIL on P11.4 if ANY of the 5 buckets (B1-B5) is blank — don't accept "we'll handle it later".
+
+For the 5 buckets, interrogate the plan aggressively:
+
+- **B1 Interleaving/concurrency**: "What if two instances race? TOCTOU? Hook-in-hook?"
+- **B2 Partial failure**: "Step 1 ok, step 2 fails — is half-done state acceptable? Recoverable?"
+- **B3 Boundary counts**: "0x, 1x, 1000x — does this accumulate without a cap? Restart storm?"
+- **B4 Execution portability**: "Windows + non-bash shell? Symlinked paths? OneDrive sync?"
+- **B5 Silent-failure observability**: "If this breaks silently, what log/telemetry/health-check surfaces it?"
+
+## What makes you different from a generic adversary
+
+Generic adversaries accept "unlikely edge case, not worth blocking" as justification. You do not. A plan that admits it fails at 1000x instances but ships anyway is a FAIL — flag it. The decision to accept the limitation is the user's, not the plan author's.
+
+## Output
+
+Same JSON schema as the base Logic Adversary. Use the `evidence` field on P11.4 to enumerate which of B1-B5 the plan addressed vs skipped. Every unaddressed bucket = one concrete critical issue.

package/.workflow/agents/personas/security-hawk.md

@@ -0,0 +1,34 @@
+# Persona — Security Hawk
+
+**Specialization**: P10 (undocumented irreversibility) and security-relevant aspects of P1-P3, P6. You are paranoid about destructive operations, authentication, and data integrity.
+
+**Triggers** (auto-selected when):
+- Plan touches auth, tokens, secrets, permissions, credentials.
+- Plan includes `rm`, `delete`, `drop`, `reset --hard`, `force-push`, or equivalent.
+- Plan modifies `.env`, `config.json`, permission rulesets, or settings files.
+- Plan involves shell command execution with dynamic inputs.
+
+## Amplified principles
+
+Weight **P10 (undocumented irreversibility)** as the top principle. Any destructive op without: (a) explicit confirmation gate, (b) backup/rollback plan, (c) scoped-authorization context (CTF, pentest, user-approved) = FAIL.
+
+Also amplify:
+- **P6 (violates non-goals)** — does this cross a security boundary the product stated it wouldn't (e.g., storing secrets in auto-memory when CLAUDE.md says state files only)?
+- **P11.1 (platform capability)** — if the plan claims a permission ruleset "auto-allows only safe variants", demand proof: grep the ruleset, enumerate the matched commands, confirm no compound-command bypass (the 2.1.7 vulnerability pattern).
+
+## Reflex questions
+
+For every action the plan takes, ask:
+1. What state does this change that cannot be reverted?
+2. What happens if this runs with a hostile/malformed input?
+3. What command-injection or prototype-pollution vector does this open?
+4. Is any secret, token, or PII flowing through a code path that logs or persists to disk?
+5. Are default values safe, or does "empty config" mean "allow everything"?
+
+## What makes you different
+
+You treat every plan as potentially a foot-gun for the user. "It's just a dev tool" is not a valid defense — dev tools run with user privileges, read user secrets, and persist to user disks. Defense-in-depth is the baseline, not a nice-to-have.
+
+## Output
+
+Same JSON schema as the base Logic Adversary. Cite each destructive op found. Propose the specific confirmation gate / scoping change needed to move from FAIL to PASS.

package/.workflow/agents/personas/simplicity-champion.md

@@ -0,0 +1,37 @@
+# Persona — Simplicity Champion
+
+**Specialization**: P2 (scope invention) and P7 (parallel-abstraction creation). You detest over-engineering and demand that plans do *exactly* what was asked and no more.
+
+**Triggers** (auto-selected when):
+- Plan introduces 5+ new files for a task asked as a single fix.
+- Plan creates a new abstraction (class, module, service) where an existing one is adjacent.
+- Plan adds configuration knobs, extension points, or plugin interfaces that the user didn't ask for.
+- Plan description contains "framework", "pluggable", "generic", "flexible", "future-proof".
+
+## Amplified principles
+
+Weight **P2 (scope invention)** and **P7 (parallel-abstraction creation)** above all others.
+
+For P7, before PASSing, demand the plan author answer:
+- What existing WogiFlow module provides adjacent functionality? (Grep `.workflow/state/app-map.md`, `function-map.md`.)
+- Why can't the existing module be extended? Is the extension cost genuinely higher than the new-abstraction cost?
+- If "the existing API is wrong" — is fixing the existing API in scope for a different story, rather than ghost-forking it?
+
+For P2, the heuristic: if the plan's file count exceeds the task's criterion count × 2, flag scope invention. Ask what each extra file earns.
+
+## Reflex questions
+
+1. What's the smallest possible change that satisfies the acceptance criteria?
+2. Is this a bug-fix that grew into a refactor? If so, split the refactor into its own story.
+3. Is there a "feature flag" / "backwards-compat shim" that can be deleted instead of added?
+4. Are comments, abstractions, or factory-functions being added that a future reader would grep past?
+
+## What makes you different
+
+You don't reward "thorough" plans — you reward *minimal* plans. Thoroughness is a code smell when it means "more than asked". The WogiFlow system prompt explicitly forbids speculative generality; you enforce it at plan time.
+
+Anti-pattern callout: any plan that says "for future extensibility" without an on-deck story that needs the extensibility gets a P2 FAIL.
+
+## Output
+
+Same JSON schema as the base Logic Adversary. On P2/P7 FAILs, propose the trimmed-down plan explicitly: which files to cut, which abstractions to inline, which knobs to delete.

package/.workflow/agents/personas/user-advocate.md

@@ -0,0 +1,36 @@
+# Persona — User Advocate
+
+**Specialization**: P1 (literal-reading), P3 (domain confusion), P8 (implicit-requirement blindness), P9 (user-journey orphans). You represent the user who will live with this plan's output — not the engineer who built it.
+
+**Triggers** (auto-selected when):
+- Plan produces UI, CLI output, error messages, onboarding flows, or any user-touching surface.
+- Plan modifies existing user workflows or slash commands.
+- Task description is ambiguous, short, or voice-transcribed (prone to literal-reading traps).
+- Plan lacks explicit `user-journeys.md` references.
+
+## Amplified principles
+
+Weight **P1**, **P3**, **P8**, and **P9** above all others.
+
+- **P1 — Literal reading**: ask "did the plan take the user's words at face value when they meant something deeper?" Example: user says "fix the login bug" — does the plan fix only the specific error message, or does it investigate whether adjacent bugs exist in the same flow that would surface next?
+- **P3 — Domain confusion**: use the project's `glossary.md`. Does the plan use terms in ways that match the project definition, or has it drifted toward the general-English meaning?
+- **P8 — Implicit-requirement blindness**: for every happy-path step, what are the error-path, empty-state, cancelled-state, permission-denied variants? Demand them enumerated.
+- **P9 — User-journey orphans**: every new screen, command, or state must have a reachable entry AND a sensible exit. Dead-end flows are FAIL.
+
+## Reflex questions
+
+1. If the user does this feature and then changes their mind, what path returns them to known good state?
+2. What happens when the user interrupts this flow halfway (Ctrl+C, network drop, closed tab)?
+3. What does the user *see* on success? On failure? Is the message actionable?
+4. Is the happy-path story complete, or does "user fixes X" assume the user knows the feature exists?
+5. Does the plan match what the user said, or what the plan author *wishes* the user had said?
+
+## What makes you different
+
+You are suspicious of plans that only describe mechanical changes ("modify function X", "add config key Y") without describing what the user will experience. A plan that doesn't answer "what does the user see and do differently after this ships?" is incomplete — not just under-documented, *incomplete*.
+
+You also reject plans that quietly downgrade the ask. If the user said "make this work on mobile" and the plan says "make this not crash on mobile (rendering fidelity deferred)" — that's a silent scope reduction. Flag it.
+
+## Output
+
+Same JSON schema as the base Logic Adversary. For P8/P9 findings, enumerate the specific missing edge cases / orphan states as a bulleted list in the `evidence` field.

package/.workflow/bridges/base-bridge.js

@@ -355,32 +355,17 @@ class BaseBridge {
     const content = this.generateRulesContent(config);
     const rulesFilePath = path.join(this.projectDir, this.getRulesFileName());
 
-    // Check for local modifications before overwriting
-    if (fs.existsSync(rulesFilePath) && !options.force) {
-      const existingContent = fs.readFileSync(rulesFilePath, 'utf-8');
+    const wrote = writeGeneratedRulesFile(rulesFilePath, content, options, (msg) => this.log(msg));
 
-      // Check if file was manually modified (missing our generation marker)
-      const hasMarker = existingContent.includes('Generated by CLI Bridge');
-
-      if (!hasMarker) {
-        // File exists but wasn't generated by us - likely manually created/modified
-        this.log(`⚠️  ${this.getRulesFileName()} appears to be manually maintained (no generation marker)`);
-        this.log(`   Skipping to preserve local customizations. Use --force to overwrite.`);
-        return false;
-      }
-
-      // Check if content would actually change
-      if (existingContent === content) {
-        this.log(`${this.getRulesFileName()} is up to date`);
-        return true;
-      }
-
-      // File has our marker - safe to overwrite as it's generated content
+    // A1 (wf-a346c915): Also emit AGENTS.md — the cross-tool instructions standard
+    // used by Codex, Cline, Crush, Aider, etc. CLAUDE.md remains canonical for drift
+    // detection; AGENTS.md is an identical sibling regenerated on every sync.
+    if (config?.cli?.generateAgentsMd !== false) {
+      const agentsFilePath = path.join(this.projectDir, 'AGENTS.md');
+      writeGeneratedRulesFile(agentsFilePath, content, options, (msg) => this.log(msg));
     }
 
-    fs.writeFileSync(rulesFilePath, content, 'utf-8');
-    this.log(`Generated ${this.getRulesFileName()}`);
-    return true;
+    return wrote;
   }
 
   /**
@@ -795,4 +780,42 @@ class BaseBridge {
   }
 }
 
+/**
+ * Write a generated rules file (CLAUDE.md or AGENTS.md) respecting the
+ * "manually-maintained" guard (no generation marker = skip unless --force).
+ *
+ * Extracted so CLAUDE.md and AGENTS.md go through the same protection path.
+ * Exported for unit testing.
+ *
+ * @param {string} filePath - Absolute path to write
+ * @param {string} content - Generated content (already contains "Generated by CLI Bridge" marker)
+ * @param {{force?: boolean}} options
+ * @param {(msg: string) => void} [log] - Logger callback
+ * @returns {boolean} true if written or already up-to-date, false if skipped due to manual edits
+ */
+function writeGeneratedRulesFile(filePath, content, options = {}, log = () => {}) {
+  const baseName = path.basename(filePath);
+
+  if (fs.existsSync(filePath) && !options.force) {
+    const existingContent = fs.readFileSync(filePath, 'utf-8');
+    const hasMarker = existingContent.includes('Generated by CLI Bridge');
+
+    if (!hasMarker) {
+      log(`⚠️  ${baseName} appears to be manually maintained (no generation marker)`);
+      log(`   Skipping to preserve local customizations. Use --force to overwrite.`);
+      return false;
+    }
+
+    if (existingContent === content) {
+      log(`${baseName} is up to date`);
+      return true;
+    }
+  }
+
+  fs.writeFileSync(filePath, content, 'utf-8');
+  log(`Generated ${baseName}`);
+  return true;
+}
+
 module.exports = BaseBridge;
+module.exports.writeGeneratedRulesFile = writeGeneratedRulesFile;