scene-capability-engine 3.6.65 → 3.6.67

package/scripts/release-posture-report.js

@@ -0,0 +1,262 @@
+#!/usr/bin/env node
+'use strict';
+
+const fs = require('fs');
+const path = require('path');
+
+const { auditDeprecatedEntry } = require('./deprecated-entry-audit');
+const { auditReleaseDocs } = require('./release-doc-version-audit');
+
+const STABLE_CORE_MARKERS = [
+  'npm run test:release',
+  'npm run audit:clarification-first',
+  'npm run audit:agent-governance',
+  'npm run audit:release-docs',
+  'npm run gate:git-managed',
+  'npm run gate:errorbook-release',
+  'npm run gate:errorbook-registry-health',
+  'Publish to npm'
+];
+
+const EXTENDED_EVIDENCE_MARKERS = [
+  'moqui',
+  'matrix-regression',
+  'interactive-matrix-signals',
+  'weekly ops',
+  'release-evidence',
+  'release-risk-remediation',
+  'state-migration-reconciliation'
+];
+
+function parseArgs(argv = process.argv.slice(2)) {
+  const options = {
+    projectPath: process.cwd(),
+    json: false,
+    failOnBlocking: false,
+    requireStable: false,
+    out: null
+  };
+
+  for (let index = 0; index < argv.length; index += 1) {
+    const token = argv[index];
+    const next = argv[index + 1];
+    if (token === '--project-path' && next) {
+      options.projectPath = path.resolve(next);
+      index += 1;
+      continue;
+    }
+    if (token === '--json') {
+      options.json = true;
+      continue;
+    }
+    if (token === '--fail-on-blocking') {
+      options.failOnBlocking = true;
+      continue;
+    }
+    if (token === '--require-stable') {
+      options.requireStable = true;
+      continue;
+    }
+    if (token === '--out' && next) {
+      options.out = path.resolve(next);
+      index += 1;
+      continue;
+    }
+    if (token === '--help' || token === '-h') {
+      printHelpAndExit(0);
+    }
+  }
+
+  return options;
+}
+
+function printHelpAndExit(code) {
+  const lines = [
+    'Usage: node scripts/release-posture-report.js [options]',
+    '',
+    'Options:',
+    '  --project-path <path>   Project root to inspect (default: current directory)',
+    '  --json                  Print JSON payload',
+    '  --fail-on-blocking      Exit code 2 when blocking issues are found',
+    '  --require-stable        Exit code 2 unless posture resolves to stable',
+    '  --out <path>            Write JSON payload to file',
+    '  -h, --help              Show this help'
+  ];
+  console.log(lines.join('\n'));
+  process.exit(code);
+}
+
+function countMarkers(content, markers) {
+  return markers.reduce((count, marker) => {
+    const regex = new RegExp(marker.replace(/[.*+?^${}()|[\]\\]/g, '\\$&'), 'gi');
+    const matches = content.match(regex);
+    return count + (matches ? matches.length : 0);
+  }, 0);
+}
+
+function auditReleasePosture(options = {}) {
+  const projectPath = path.resolve(options.projectPath || process.cwd());
+  const releaseWorkflowPath = path.join(projectPath, '.github', 'workflows', 'release.yml');
+  const blockers = [];
+  const warnings = [];
+  const signals = {
+    stable_core_markers_found: 0,
+    stable_core_markers_expected: STABLE_CORE_MARKERS.length,
+    extended_evidence_marker_count: 0,
+    release_workflow_exists: fs.existsSync(releaseWorkflowPath)
+  };
+
+  let workflowContent = '';
+  if (!signals.release_workflow_exists) {
+    blockers.push({
+      code: 'missing_release_workflow',
+      message: 'Release workflow is missing.'
+    });
+  } else {
+    workflowContent = fs.readFileSync(releaseWorkflowPath, 'utf8');
+    signals.stable_core_markers_found = STABLE_CORE_MARKERS.filter((marker) => workflowContent.includes(marker)).length;
+    signals.extended_evidence_marker_count = countMarkers(workflowContent, EXTENDED_EVIDENCE_MARKERS);
+
+    if (signals.stable_core_markers_found < STABLE_CORE_MARKERS.length) {
+      blockers.push({
+        code: 'stable_core_markers_missing',
+        message: `Release workflow only exposes ${signals.stable_core_markers_found}/${STABLE_CORE_MARKERS.length} stable-core markers.`
+      });
+    }
+
+    if (signals.extended_evidence_marker_count > 0) {
+      blockers.push({
+        code: 'release_workflow_mixes_extended_evidence',
+        message: 'Release workflow still mixes stable-core gates with extended evidence generation.'
+      });
+    }
+  }
+
+  const deprecatedEntry = auditDeprecatedEntry({ projectPath });
+  const releaseDocs = auditReleaseDocs({ projectPath });
+
+  if (!deprecatedEntry.passed) {
+    blockers.push({
+      code: 'deprecated_entry_drift',
+      message: `Deprecated entry audit found ${deprecatedEntry.violation_count} violation(s).`
+    });
+  }
+
+  if (!releaseDocs.passed) {
+    blockers.push({
+      code: 'release_doc_drift',
+      message: `Release doc audit found ${releaseDocs.error_count} error(s).`
+    });
+  }
+
+  if (signals.release_workflow_exists && !workflowContent.includes('audit:deprecated-entry')) {
+    warnings.push({
+      code: 'deprecated_entry_audit_not_wired',
+      message: 'Release workflow does not yet run deprecated-entry audit.'
+    });
+  }
+
+  if (signals.release_workflow_exists && !workflowContent.includes('gate:git-managed')) {
+    warnings.push({
+      code: 'git_managed_gate_not_wired',
+      message: 'Release workflow does not yet run git-managed gate.'
+    });
+  }
+
+  if (signals.release_workflow_exists && !workflowContent.includes('gate:errorbook-release')) {
+    warnings.push({
+      code: 'errorbook_release_gate_not_wired',
+      message: 'Release workflow does not yet run errorbook release gate.'
+    });
+  }
+
+  let posture = 'stable';
+  if (blockers.some((item) => item.code === 'missing_release_workflow' || item.code === 'stable_core_markers_missing')) {
+    posture = 'preview';
+  } else if (blockers.length > 0) {
+    posture = 'rc-candidate';
+  }
+
+  return {
+    mode: 'release-posture-report',
+    project_path: projectPath,
+    posture,
+    passed: blockers.length === 0,
+    blocking_count: blockers.length,
+    warning_count: warnings.length,
+    stable_required_checks: [
+      'test:release',
+      'clarification-first-audit',
+      'agent-governance-baseline-audit',
+      'release-doc-version-audit',
+      'git-managed-gate',
+      'errorbook-release-gate',
+      'errorbook-registry-health-gate',
+      'publish-to-npm'
+    ],
+    advisory_checks: [
+      'deprecated-entry-audit',
+      'interactive-governance-report',
+      'release-asset-integrity',
+      'state-migration-reconciliation'
+    ],
+    extended_evidence_examples: [
+      'moqui-*',
+      'matrix-regression',
+      'weekly ops',
+      'release-evidence bundles'
+    ],
+    signals,
+    blockers,
+    warnings,
+    deprecated_entry_audit: {
+      passed: deprecatedEntry.passed,
+      violation_count: deprecatedEntry.violation_count
+    },
+    release_doc_audit: {
+      passed: releaseDocs.passed,
+      error_count: releaseDocs.error_count
+    }
+  };
+}
+
+function writeReportIfNeeded(report, outPath) {
+  if (!outPath) {
+    return;
+  }
+  const resolved = path.resolve(outPath);
+  fs.mkdirSync(path.dirname(resolved), { recursive: true });
+  fs.writeFileSync(resolved, `${JSON.stringify(report, null, 2)}\n`, 'utf8');
+}
+
+function main() {
+  const options = parseArgs(process.argv.slice(2));
+  const report = auditReleasePosture(options);
+  writeReportIfNeeded(report, options.out);
+
+  if (options.json) {
+    process.stdout.write(`${JSON.stringify(report, null, 2)}\n`);
+  } else {
+    console.log(`[release-posture-report] posture=${report.posture} blockers=${report.blocking_count} warnings=${report.warning_count}`);
+  }
+
+  if ((options.failOnBlocking && report.blocking_count > 0) || (options.requireStable && report.posture !== 'stable')) {
+    process.exitCode = 2;
+  }
+}
+
+if (require.main === module) {
+  try {
+    main();
+  } catch (error) {
+    console.error(`[release-posture-report] ${error.message}`);
+    process.exit(1);
+  }
+}
+
+module.exports = {
+  STABLE_CORE_MARKERS,
+  EXTENDED_EVIDENCE_MARKERS,
+  parseArgs,
+  auditReleasePosture
+};

package/template/.sce/README.md

@@ -1,248 +1,82 @@
-# Project Development Guide
-
-> **AI Tools: Read this first!** This project follows Spec-driven development methodology powered by sce (Scene Capability Engine).
-
----
-
-## 🎯 How This Project Works
-
-This project uses **Spec-driven development** - a structured approach where:
-- Every feature starts with a **Spec** (requirements + design + tasks)
-- All work is tracked and documented
-- AI tools help implement features according to Specs
-
-**Your role as AI:**
-- When user requests a feature → Check if Spec exists, if not, help create one
-- When implementing → Follow the Spec's requirements and design
-- When stuck → Read the Spec documents for context
-- When business scene/module/page/entity is unclear → Clarify scope first; do not replace missing understanding with blanket disable
-- Track progress by updating task status
-
----
-
-## 🚀 sce Capabilities
-
-**IMPORTANT**: After installing or updating sce, read this section to understand all available capabilities. Using the right tool for the job ensures efficient, high-quality development.
-
-### Core: Spec-Driven Development
-- `sce adopt` — Initialize sce in a project (creates `.sce/` structure)
-- `sce create-spec <name>` — Create a new Spec (requirements + design + tasks)
-- `sce status` — Show project status and Spec progress
-- `sce workflows` — List available Specs and workflows
-- `sce context export <spec-name>` — Export Spec context for AI consumption
-- `sce prompt generate <spec> <task>` — Generate task-specific prompt
-
-### Task Management
-- `sce task claim <spec> <task-id>` — Claim a task for execution
-- `sce task list <spec>` — List claimed tasks
-- Task status tracking in `tasks.md`: `[ ]` not started, `[-]` in progress, `[x]` completed
-
-### Spec Locking (Multi-User)
-- `sce lock acquire <spec>` — Lock a Spec to prevent conflicts
-- `sce lock release <spec>` / `sce unlock <spec>` — Release lock
-- `sce lock status` — Check lock status
-- `sce lock cleanup` — Remove stale locks (24h timeout)
-- `sce lock whoami` — Show machine identifier
-
-### Workspace Management
-- `sce workspace create/list/switch/info/remove` — Manage multiple sce projects
-- Global state: `~/.sce/workspace-state.json`
-
-### Environment Configuration
-- `sce env list/switch/info/register/unregister/rollback/verify/run` — Multi-environment management
-- Automatic backup before each switch, instant rollback support
-
-### Multi-Repository Management
-- `sce repo init [--nested]` — Auto-discover Git repositories
-- `sce repo status [--verbose]` — Status of all repositories
-- `sce repo exec "<command>"` — Execute command across all repos
-- `sce repo health` — Check repository health
-
-### Spec-Level Collaboration
-- `sce collab init/status/assign/verify/integrate/migrate` — Coordinate parallel Spec development
-- Master Spec + Sub-Specs with dependency management
-- Interface contracts for cross-Spec compatibility
-
-### Multi-Agent Parallel Coordination
-When multiple AI agents work on the same project simultaneously:
-- **AgentRegistry** (`lib/collab`) — Agent lifecycle with heartbeat monitoring
-- **TaskLockManager** (`lib/lock`) — File-based task mutual exclusion
-- **TaskStatusStore** (`lib/task`) — Concurrent-safe tasks.md updates with retry
-- **SteeringFileLock** (`lib/lock`) — Steering file write serialization
-- **MergeCoordinator** (`lib/collab`) — Git branch isolation per agent
-- **Coordinator** (`lib/collab`) — Central task assignment (optional)
-- Config: `.sce/config/multi-agent.json` (default `enabled: true`; set `enabled: false` to opt out)
-- If a project opts out with `enabled: false`, all components fall back to single-agent no-op behavior
-- See `docs/multi-agent-coordination-guide.md` for full API reference
-
-### Spec-Level Steering & Context Sync
-Fourth steering layer (L4) and Spec lifecycle coordination for multi-agent scenarios:
-- **SpecSteering** (`lib/steering`) — Per-Spec `steering.md` CRUD with template generation, Markdown ↔ structured object roundtrip
-- **SteeringLoader** (`lib/steering`) — Unified L1-L4 four-layer steering loader with merged output
-- **ContextSyncManager** (`lib/steering`) — Multi-agent CURRENT_CONTEXT.md maintenance with Spec progress table, SteeringFileLock-protected writes
-- **SpecLifecycleManager** (`lib/collab`) — Spec state machine (planned → assigned → in-progress → completed → released) with auto-completion detection
-- **SyncBarrier** (`lib/collab`) — Agent Spec-switch synchronization barrier (uncommitted changes check, steering reload)
-- **Coordinator Integration** — `completeTask` auto-checks Spec completion; `assignTask` runs SyncBarrier
-- If needed, a project can still opt out by setting `enabled: false`, which restores single-agent no-op behavior
-- See `docs/multi-agent-coordination-guide.md` for full API reference
-
-### Autonomous Control
-- `sce auto create <description>` — Create and execute Spec autonomously
-- `sce auto run <spec>` — Execute existing Spec tasks autonomously
-- `sce auto status/resume/stop/config` — Manage autonomous execution
-- Intelligent error recovery, checkpoint system, learning from history
-
-### Agent Orchestrator — Multi-Agent Spec Execution
-Automate parallel Spec execution via Codex CLI sub-agents (replaces manual multi-terminal workflow):
-- `sce orchestrate run --specs "spec-a,spec-b,spec-c" --max-parallel 3` — Start multi-agent orchestration
-- `sce orchestrate status` — View orchestration progress (per-Spec status, overall state)
-- `sce orchestrate stop` — Gracefully stop all sub-agents
-- **OrchestratorConfig** (`lib/orchestrator`) — Configuration management (agent backend, parallelism, timeout, retries) via `.sce/config/orchestrator.json`
-- **BootstrapPromptBuilder** (`lib/orchestrator`) — Builds bootstrap prompts with Spec path, steering context, execution instructions
-- **AgentSpawner** (`lib/orchestrator`) — Process manager for Codex CLI sub-agents with timeout detection, graceful termination (SIGTERM → SIGKILL)
-- **StatusMonitor** (`lib/orchestrator`) — Codex JSON Lines event parsing, per-Spec status tracking, orchestration-level aggregation
-- **OrchestrationEngine** (`lib/orchestrator`) — DAG-based dependency analysis, batch scheduling, parallel execution (≤ maxParallel), failure propagation, retry mechanism
-- Prerequisites: Codex CLI installed, `CODEX_API_KEY` environment variable set
-- 11 correctness properties verified via property-based testing
-
-### Scene Runtime (Template Engine + Quality + ERP)
-- **Template Engine**: `sce scene template-validate/resolve/render` — Variable schema, multi-file rendering, 3-layer inheritance
-- **Package Registry**: `sce scene publish/unpublish/install/list/search/info/diff/version` — Local package management
-- **Quality Pipeline**: `sce scene lint/score/contribute` — 10-category lint, quality scoring, one-stop publish
-- **Ontology**: `sce scene ontology show/deps/validate/actions/lineage/agent-info` — Semantic relationship graph
-- **Moqui ERP**: `sce scene connect/discover/extract` — ERP integration and template extraction
-- **Registry Ops**: `sce scene deprecate/audit/owner/tag/lock/stats` — Advanced registry management
-
-### Document Governance
-- `sce docs diagnose/cleanup/validate/archive/hooks` — Document lifecycle management
-- Automatic compliance checking and cleanup
-
-### DevOps Integration
-- `sce ops init/validate/audit/takeover/feedback` — Operations Spec management
-- Progressive AI autonomy levels (L1-L5)
-
-### Knowledge Management
-- `sce knowledge init/add/list/search/show/delete/stats` — Personal knowledge base
-
----
-
-## 📋 Development Workflow
-
-### When User Asks You to Implement a Feature
-
-**Step 1: Check if Spec exists**
-```
-Look in .sce/specs/ directory
-```
-
-**Step 2: If Spec exists**
-- Read `requirements.md` - understand what to build
-- Read `design.md` - understand how to build it
-- Read `tasks.md` - see implementation steps
-- Implement according to the Spec
-- Update task status as you complete work
+# Project Delivery Guide
 
-**Step 3: If no Spec exists**
-- Suggest creating a Spec first
-- Help user define requirements
-- Help design the solution
-- Break down into tasks
-- Then implement
+> Read this file first after SCE takes over a project.
 
-### When Working in Multi-Agent Mode
+This project is governed by SCE. Work is not managed as a loose chat transcript. It is managed through governed project, channel, scene, spec, task, and evidence objects.
 
-By default `.sce/config/multi-agent.json` is provisioned with `enabled: true`:
-1. Register with AgentRegistry before starting work
-2. Acquire task locks before modifying any task
-3. Use TaskStatusStore for concurrent-safe tasks.md updates
-4. Use SteeringFileLock when updating steering files
-5. Deregister when done (auto-releases all locks)
+## Operating Baseline
 
----
-
-## 📁 Project Structure
-
-```
-.sce/
-├── README.md                  # This file - project development guide
-├── specs/                     # All Specs live here
-│   └── {spec-name}/           # Individual Spec
-│       ├── requirements.md    # What we're building
-│       ├── design.md          # How we'll build it
-│       ├── tasks.md           # Implementation steps
-│       ├── steering.md        # Spec-level steering (L4, multi-agent)
-│       ├── lifecycle.json     # Spec lifecycle state (multi-agent)
-│       └── locks/             # Task lock files (multi-agent)
-├── steering/                  # Development rules (auto-loaded by AI)
-│   ├── CORE_PRINCIPLES.md     # Core development principles
-│   ├── ENVIRONMENT.md         # Project environment
-│   ├── CURRENT_CONTEXT.md     # Current work context
-│   └── RULES_GUIDE.md         # Rules index
-├── config/                    # Configuration files
-│   ├── multi-agent.json       # Multi-agent coordination config
-│   ├── agent-registry.json    # Active agent registry
-│   └── coordination-log.json  # Coordinator assignment log
-└── tools/                     # Tool configurations
-```
+- Read `.sce/steering/CORE_PRINCIPLES.md` first
+- Read `.sce/steering/RULES_GUIDE.md` for execution baselines
+- Treat `.sce/steering/CURRENT_CONTEXT.md` as a summary, not the truth source
+- Use the active Spec files as the primary work contract
+- Keep all generated artifacts under governed Spec directories
 
-**Key files:**
-- `.sce/steering/CORE_PRINCIPLES.md` - Development principles for this project
-- `.sce/steering/CURRENT_CONTEXT.md` - What we're currently working on
-- `.sce/specs/{spec-name}/` - Feature specifications
+## Core Model
 
----
+- `project -> scene -> spec`
+- `project -> channel/session -> (scene + spec focus) -> task -> event`
+- `scene` is the semantic continuity boundary
+- `channel/session` is the collaboration unit
+- `spec` is the governed work package
+- `task` is the smallest user-facing execution unit
 
-## 📖 What is a Spec?
+One project may host multiple collaboration channels in parallel by default.
 
-A Spec is a complete feature definition with three parts:
+- Do not assume there is only one current session
+- `focusedChannelId` only marks the current UI focus
+- Every `project + channel/session` must preserve its own `scene/spec/doc/session/tabs/tree/draft/runState`
+- Never collapse other channels back into one global current-context slot
 
-### 1. requirements.md - WHAT we're building
-- User stories, functional requirements, acceptance criteria
+## How To Execute Work
 
-### 2. design.md - HOW we'll build it
-- Architecture, component design, API design, technology choices
+1. Understand the real user goal first, then verify facts in code/spec/state before deciding.
+2. Bind the work to the correct scene/spec path before implementation.
+3. Keep changes, evidence, and follow-up under the active Spec.
+4. Use `spec pipeline` and `spec gate` to keep delivery governed.
+5. Use project/semantic supervision views to inspect cross-spec or cross-channel drift.
 
-### 3. tasks.md - Implementation steps
-- Ordered task list with dependencies and implementation notes
-- Status: `- [ ]` Not started | `- [-]` In progress | `- [x]` Completed
+If the request is not yet tied to a concrete Spec, create or route it through governed planning first.
 
----
+```bash
+sce studio plan --goal "clarify and stage work" --json
+sce spec bootstrap --name 01-00-example --scene scene.example --non-interactive
+sce spec pipeline run --spec 01-00-example --scene scene.example
+sce spec gate run --spec 01-00-example --scene scene.example --json
+```
 
-## 💡 Working with This Project
+## Mandatory Execution Behaviors
 
-### DO:
-- ✅ Check for existing Specs before starting work
-- ✅ Follow requirements and design in Specs
-- ✅ Update task status as you work
-- ✅ Read steering rules for project-specific guidelines
-- ✅ Use task locks in multi-agent mode
-- ✅ Run tests before marking tasks complete
+- Supreme-principle layer is `Four Teachings + Little Nine`
+- All agent-generated logs, reports, debug artifacts, and test scripts default into the active Spec subtree
+- If there is no explicit active Spec yet, use a governed general Spec
+- Temporary analysis documents should be removed after the work is complete
+- Do not let documents spread outside governed Spec locations
+- After more than two failed localization rounds, record/update the `errorbook` incident and use bisection-style debug logs to halve the search scope
+- Do not throw unresolved blocking analysis back to the user until you have actively decomposed and localized it
 
-### DON'T:
-- ❌ Start implementing without understanding requirements
-- ❌ Ignore the design document
-- ❌ Create files in wrong locations (use Spec directories)
-- ❌ Skip updating task status
-- ❌ Modify tasks.md without locks in multi-agent mode
+## Useful Commands
 
----
+```bash
+sce status
+sce studio plan --goal "continue current work" --json
+sce task ref --json
+sce project supervision show --json
+sce semantic progress --json
+```
 
-## 🔍 Finding Information
+## Project Layout
 
-| Need | Where |
-|------|-------|
-| Feature requirements | `.sce/specs/{spec-name}/requirements.md` |
-| Implementation design | `.sce/specs/{spec-name}/design.md` |
-| What to work on | `.sce/specs/{spec-name}/tasks.md` |
-| Project context | `.sce/steering/CURRENT_CONTEXT.md` |
-| Development rules | `.sce/steering/CORE_PRINCIPLES.md` |
-| Project status | `sce status` |
-| Multi-agent setup | `.sce/config/multi-agent.json` |
-| Full documentation | `docs/` directory |
+```text
+.sce/
+├── README.md
+├── steering/
+├── config/
+├── specs/
+└── state/sce-state.sqlite
+```
 
----
+The active truth is in the current project state plus the active Spec subtree, not in historical chat output.
 
-**Project Type**: Spec-driven development  
-**sce Version**: 3.6.65  
-**Last Updated**: 2026-03-22
-**Purpose**: Guide AI tools to work effectively with this project
+**sce Version**: 3.6.67
+**Last Updated**: 2026-03-29

package/template/.sce/config/semantic-shared-sources.json

@@ -0,0 +1,5 @@
+{
+  "enabled": true,
+  "mirror_root": ".sce/knowledge/semantic-shared",
+  "sources": []
+}

package/template/.sce/config/supreme-principles-policy.json

@@ -0,0 +1,105 @@
+{
+  "schema_version": "1.0",
+  "enabled": true,
+  "allow_planning_actions": [
+    "allow",
+    "clarify",
+    "rewrite",
+    "narrow"
+  ],
+  "allow_execution_actions": [
+    "allow",
+    "rewrite",
+    "narrow"
+  ],
+  "clarify_question": "请先明确你真正要达成的业务目标、作用对象和约束边界。",
+  "refuse_message": "该请求不符合 SCE 的最高道德规范，不能直接执行。",
+  "rewrite_message": "原始请求存在失范或越界风险，已收敛为可正当执行的目标。",
+  "narrow_message": "原始请求风险过高，已收缩为审查、备份、验证优先的安全目标。",
+  "refuse_rules": [
+    {
+      "id": "credential-theft",
+      "keywords": [
+        "steal password",
+        "dump token",
+        "exfiltrate",
+        "keylogger",
+        "phish",
+        "窃取密码",
+        "盗取令牌",
+        "导出凭证"
+      ],
+      "reason": "请求明显指向凭证盗取、数据外流或钓鱼等恶意行为。"
+    },
+    {
+      "id": "malware-abuse",
+      "keywords": [
+        "malware",
+        "ransomware",
+        "backdoor",
+        "payload",
+        "木马",
+        "勒索软件",
+        "后门"
+      ],
+      "reason": "请求明显指向恶意控制、破坏或持久化投毒。"
+    },
+    {
+      "id": "audit-evasion",
+      "keywords": [
+        "delete logs to hide",
+        "evade audit",
+        "disable audit trail",
+        "清除日志掩盖",
+        "绕过审计",
+        "删除审计日志"
+      ],
+      "reason": "请求明显指向规避责任、破坏审计或掩盖痕迹。"
+    }
+  ],
+  "rewrite_rules": [
+    {
+      "id": "auth-bypass-to-safe-test-fixture",
+      "keywords": [
+        "disable auth",
+        "bypass auth",
+        "skip login",
+        "skip approval",
+        "关闭认证",
+        "绕过认证",
+        "跳过登录",
+        "跳过审批"
+      ],
+      "replacement": "Design a dev/test-only mechanism with explicit scope guard, audit trail, rollback plan, and no production bypass of authentication or approval controls.",
+      "reason": "将越界的“绕过保护”目标改写为受边界约束的测试/诊断机制。"
+    },
+    {
+      "id": "remove-audit-to-safe-observability",
+      "keywords": [
+        "remove audit",
+        "turn off audit",
+        "delete logs",
+        "关闭审计",
+        "删除日志",
+        "去掉审计"
+      ],
+      "replacement": "Design a safe observability adjustment that preserves required auditability, keeps retention boundaries, and reduces noise without deleting accountability evidence.",
+      "reason": "将“去掉审计/日志”改写为保留责任边界的可观测性优化目标。"
+    }
+  ],
+  "narrow_rules": [
+    {
+      "id": "destructive-production-change",
+      "keywords": [
+        "drop database",
+        "delete production data",
+        "truncate table",
+        "删除生产数据",
+        "清空数据表",
+        "删库"
+      ],
+      "replacement": "Review the destructive change request, produce backup and rollback steps, verify scope, and require explicit confirmation before any irreversible data operation.",
+      "reason": "高风险破坏性操作必须先收缩为审查、备份和回滚准备。"
+    }
+  ]
+}