@hongmaple0820/scale-engine 0.26.0 → 0.27.1

package/docs/AI_ENGINEERING_OS_POSITIONING.md

@@ -0,0 +1,560 @@
+# SCALE Engine Strategic Positioning
+
+> Date: 2026-05-20  
+> Status: strategic direction with a v0.27.0 runtime baseline
+> Audience: maintainers, contributors, roadmap reviewers, and product-facing documentation owners
+
+SCALE Engine should be positioned as an **Agent Governance Runtime** evolving toward an **AI Engineering OS**.
+
+The project is no longer best described as a prompt toolbox. Its durable value is the runtime layer around AI coding agents:
+
+- workflow state machines
+- hard gates and verification evidence
+- hook-based tool interception
+- role and permission boundaries
+- artifact persistence
+- context budgets
+- memory provider routing
+- skill, MCP, CLI, and adapter orchestration
+
+The core thesis is:
+
+> Use system constraints, evidence, and runtime gates to replace agent self-discipline.
+
+This positioning is intentionally stronger than "prompt engineering", but it must stay evidence-backed. SCALE can describe the direction as AI Engineering OS; it should only describe measurable gains after benchmark, eval, or runtime evidence exists.
+
+## Reference Inputs
+
+This document consolidates:
+
+- the current SCALE Engine architecture and documentation surfaces
+- maintainer review of SCALE as an Agent Governance Runtime
+- the external Harness Engineering framing in [SCALE OS v10.0: AI 编码的认知操作系统](https://segmentfault.com/a/1190000047756584)
+
+External performance claims from ecosystem articles are positioning inputs, not SCALE Engine release claims. Public SCALE claims should still be backed by local evals, runtime evidence, or release reports.
+
+## 1. Market Category
+
+SCALE sits between four emerging categories:
+
+| Category | SCALE relationship |
+| --- | --- |
+| AI Engineering OS | Long-term positioning: one governed operating layer for agent-driven engineering |
+| Agent Governance Runtime | Current strongest fit: gates, hooks, evidence, role boundaries, and policy enforcement |
+| Workflow Orchestration Runtime | Current fit: FSM, phase commands, artifacts, verification, and ship flow |
+| Harness Engineering Infrastructure | Methodology fit: constraints + feedback + workflow + continuous improvement |
+
+SCALE should avoid being framed as only:
+
+- prompt templates
+- agent rules
+- a Claude/Cursor/Codex config generator
+- an AutoGPT-style chain executor
+- a generic skills catalog
+
+Those may exist around the project, but they are not the core defensible layer.
+
+## 2. Problem Definition
+
+AI coding failures are not only model-quality failures. They are engineering runtime failures:
+
+| Failure mode | Typical prompt-only response | SCALE response |
+| --- | --- | --- |
+| Fake completion | "Please verify before finishing" | verification gates and final evidence checks |
+| Skipped tests | reminder text | FSM and verification status before completion |
+| Repeated blind retries | "try a different approach" | retry and behavior detectors |
+| Context overload | longer instructions | context budgets, lazy loading, scoped packs |
+| Agent drift | more rules | persisted workflow state and phase boundaries |
+| Hallucinated delivery | review prompt | runtime evidence ledger and ship gates |
+| Lost learning | chat history | memory artifacts, failure replay, lessons, rule candidates |
+| Multi-agent confusion | role descriptions | role gateway and tool permission boundaries |
+| Tool overreach | trust agent judgment | hook interception and policy gateway |
+
+The strategic target is not to make the model "more obedient". The target is to make non-compliant behavior observable, blockable, and recoverable.
+
+## 3. Current Strengths
+
+### 3.1 Runtime Constraints
+
+SCALE already has the right architectural instinct: lower critical rules from prompt text into runtime checks.
+
+Relevant surfaces:
+
+- `docs/ENGINEERING_STANDARDS.md`
+- `docs/RUNTIME_EVIDENCE.md`
+- `docs/DEPENDENCY_AUDIT.md`
+- `src/workflow/gates/GateSystem.ts`
+- `src/guardrails/Gateway.ts`
+- `src/artifact/fsm.ts`
+
+This is the primary moat. Prompt rules can be ignored; runtime gates can block progress.
+
+### 3.2 Workflow State Machine
+
+The workflow is driven by artifact state, not by chat momentum.
+
+Strategic value:
+
+- prevents premature completion
+- forces phase-specific evidence
+- makes stalled or skipped phases visible
+- supports resume and handoff across long sessions
+- gives agent platforms a shared lifecycle model
+
+The FSM should remain strict at phase boundaries and flexible inside each phase.
+
+### 3.3 Hook and Gateway Layer
+
+Hooks, pre-tool checks, post-tool checks, stop checks, and role-aware gateway decisions form the AI runtime interceptor layer.
+
+Strategic value:
+
+- agents do not receive raw, unlimited tool authority
+- unsafe operations can be blocked before execution
+- tool output can be converted into evidence
+- repeated failure patterns can be detected outside the model
+
+This layer makes SCALE closer to an admission controller than a prompt pack.
+
+### 3.4 Evidence-Backed Delivery
+
+SCALE's strongest anti-hallucination capability is engineering hallucination control:
+
+- no test evidence means no verified claim
+- no runtime evidence means no product-smoke claim
+- no reviewed file scope means no governed ship
+- no dependency audit evidence means weaker security confidence
+
+This reduces fake completion more reliably than instruction text.
+
+It does not fully solve reasoning hallucination. Architecture decisions, root-cause analysis, and technical tradeoffs still need evaluator intelligence.
+
+### 3.5 Adapter and Platform Surface
+
+The agent-platform adapters let SCALE act as a shared governance layer for different coding agents.
+
+Strategic value:
+
+- one governance model across Claude Code, Codex, Cursor, Gemini, Windsurf, Kiro, Cline, and related tools
+- fewer duplicated rule files
+- lower switching cost between agents
+- consistent evidence and workflow semantics
+
+Adapter expansion should not become the main roadmap by itself. The strategic value comes from shared governance semantics, not from the count of supported agents.
+
+## 4. Honest Capability Assessment
+
+SCALE can already claim:
+
+- stronger engineering governance than prompt-only rules
+- structured workflow execution with phase and artifact state
+- hard verification gates for delivery claims
+- evidence-based runtime reporting
+- first-class supply-chain audit direction
+- growing adapter coverage
+- memory and skill orchestration foundations
+
+SCALE should not yet overclaim:
+
+- fully autonomous self-evolution
+- human-level long-term memory
+- guaranteed token reduction percentages
+- guaranteed hallucination reduction percentages
+- adaptive cognitive planning
+- universal skill routing intelligence
+
+Use target ranges only in roadmap or evaluation documents, not as product claims, until eval evidence supports them.
+
+## 5. Current Gaps
+
+### 5.1 Memory Architecture
+
+Current state is closer to engineering knowledge persistence than true cognitive memory.
+
+Existing strengths:
+
+- artifacts persist decisions and work state
+- memory brain stores evidence-backed learnings
+- failure replay can preserve incidents
+- provider routing gives the right extension point
+
+Missing layers:
+
+| Memory type | Target meaning |
+| --- | --- |
+| Working memory | short-lived task context with strict token budget |
+| Episodic memory | past task episodes, failures, fixes, and outcomes |
+| Semantic memory | stable project facts and domain concepts |
+| Procedural memory | reusable ways of doing work |
+| Strategy memory | learned routing, verification, and recovery strategies |
+
+The next memory work should focus on provider-backed retrieval quality, not more local file accumulation.
+
+### 5.2 Context Compiler
+
+SCALE has context structure and budgets. It does not yet have a full context compiler.
+
+Current capability:
+
+- categorize context
+- budget context
+- lazy-load selected material
+- assemble role/task-specific packs
+
+Target capability:
+
+- rank relevance
+- slice semantically
+- compress adaptively
+- route retrieval by task intent
+- explain why each context item was included
+- measure token saved vs evidence lost
+
+This is the highest-leverage path for token reduction.
+
+### 5.3 Adaptive Workflow
+
+The current workflow is mostly rule-driven.
+
+The target workflow should adapt based on:
+
+- task risk
+- code ownership boundaries
+- prior failure rate
+- changed-file blast radius
+- missing evidence
+- tool reliability
+- agent capability confidence
+
+The system should not make every task heavy. It should apply stricter gates when risk rises and keep small documentation or config changes lightweight.
+
+### 5.4 Skill Routing Intelligence
+
+SCALE already models skills, MCP, CLI, browser, desktop automation, and evidence requirements.
+
+The missing layer is strategy:
+
+- when to call a skill
+- why that skill is preferred
+- what evidence it must produce
+- what to do when it fails
+- when to switch to MCP or CLI
+- when to avoid tool use entirely
+
+Skill routing should become a planned execution graph, not an ad hoc recommendation list.
+
+### 5.5 Evaluator Intelligence
+
+Current gates are strong for engineering completion, but weaker for reasoning quality.
+
+Needed evaluator layers:
+
+- critique loop for architecture and root cause
+- uncertainty scoring
+- adversarial review on high-risk changes
+- tradeoff comparison
+- failure hypothesis ranking
+- "evidence is insufficient" verdicts
+
+This is the path to reducing reasoning hallucination rather than only delivery hallucination.
+
+### 5.6 Self-Optimization Loop
+
+Evolution should mean more than summarizing lessons.
+
+The target loop:
+
+```text
+failure evidence
+  -> defect record
+  -> root-cause classification
+  -> lesson candidate
+  -> rule candidate
+  -> hook or gate proposal
+  -> shadow validation
+  -> regression check
+  -> promoted governance behavior
+```
+
+The promotion step must remain evidence-backed. Automatically generating rules without validation risks turning mistakes into permanent friction.
+
+## 6. Roadmap Direction
+
+### 6.1 Planning Principle
+
+The roadmap has two horizons:
+
+| Horizon | Purpose | Claim boundary |
+| --- | --- | --- |
+| One-week closure | deliver a runnable AI OS beta loop that can be tested in real repositories | "usable beta", not "stable final OS" |
+| Long-range vision | keep SCALE moving toward an AI Engineering OS with memory, context, governance, and tool intelligence | directional until backed by eval data |
+
+The near-term work should be aggressive, but public wording must stay precise. SCALE can ship beta capabilities quickly; it should only claim stable, industry-leading AI OS behavior after repeated project evidence, benchmarks, and upgrade validation.
+
+### 6.2 0.27.0: Cognitive Runtime Layer
+
+Theme: make context, memory, and skill use more intelligent and explainable.
+
+Core work:
+
+| Module | Outcome |
+| --- | --- |
+| Context Compiler | relevance-ranked, budgeted, explainable context packs |
+| Memory Provider Runtime | gbrain, agentmemory, code memory, and local memory as provider choices |
+| Skill Routing Engine | task-intent routing with evidence requirements and fallback decisions |
+| Governance ROI | quantify token cost, evidence quality, and gate friction |
+
+Implemented baseline in v0.27.0:
+
+```bash
+scale ai-os plan \
+  --task-id TASK-123 \
+  --task "Fix OAuth callback auth token handling and verify browser flow" \
+  --level L \
+  --files src/auth/oauth.ts,src/ui/callback.tsx \
+  --budget 8000 \
+  --json
+```
+
+The command returns one runtime plan containing:
+
+- `governance`: progressive mode, risk signals, required behaviors
+- `context`: Context Compiler ranking, included sections, omitted sections, token savings
+- `memory`: provider order, selected providers, fallback status, recalled items, memory context pack
+- `skillPlan`: detected intents plus executable skill/artifact/verification steps
+- `adaptiveWorkflow`: risk-adaptive gates and exit criteria for the task
+- `roi`: benefit and overhead modules for context, memory, skill routing, and governance
+
+Exit criteria:
+
+- each context item has an inclusion reason: baseline implemented by `ContextCompiler`
+- memory recall has provider, score, and evidence source: baseline implemented by Memory Provider Router
+- skill recommendations include why, when, and required proof: baseline implemented by skill execution plans
+- context pack generation reports token budget and omissions: baseline implemented by `context.pack.compiler`
+
+### 6.3 0.27.x: One-Week AI OS Beta Closure
+
+Theme: turn `ai-os plan` into a runnable beta loop.
+
+Target timebox: one week.
+
+Core work:
+
+| Module | Outcome |
+| --- | --- |
+| `scale ai-os run` | execute the unified plan through workflow, context, memory, skill routing, and verification steps |
+| Memory Provider Bridge | make gbrain, agentmemory, code memory, and local memory selectable through one provider contract |
+| Context Compiler v2 | merge task intent, risk level, files, memory recall, and role into one explainable context pack |
+| Skill Router v2 | create an execution graph for skills, MCP tools, CLIs, artifacts, and required evidence |
+| Adaptive Workflow Profiles | choose light, standard, or strict gates from risk and changed-file signals |
+| Failure Learning | convert failed gates, test failures, and missing evidence into lesson and rule candidates |
+| AI OS Dashboard CLI | summarize gate health, memory hits, context budget, skill evidence, and ROI |
+| Upgrade/Migration | migrate older `.scale` state and warn about incompatible local governance files |
+| AI OS Doctor | check runtime directories, run history, dashboard health, and benchmark freshness before adoption or release |
+| Bilingual DX | keep key CLI help, errors, README guidance, and tutorials readable in Chinese and English |
+| Benchmark Pack | run fixed samples for token budget, recall, gate pass rate, and skill-routing evidence |
+
+Exit criteria:
+
+- `scale ai-os run` can complete at least one documentation task and one code task in dry-run or guarded execution mode
+- execution output records context decisions, memory provider choices, skill decisions, gate results, and failure lessons
+- benchmark output compares context token budget against a full-load baseline
+- beta docs clearly state what is automated, what is proposed, and what still requires human approval
+
+Current landing status:
+
+- `scale ai-os run --dry-run` exists as the first beta slice.
+- It reuses `createAiOsPlan`, expands it into run steps, evidence requirements, next actions, and a persisted `.scale/ai-os/runs/<task-id>.json` report.
+- `scale ai-os run --mode guarded --verify "<command>"` executes explicit verification commands through the safe command runner, records each command as runtime evidence, and blocks the run when verification fails.
+- `scale ai-os dashboard` summarizes persisted run reports into ready/blocked counts, guarded verification health, pending evidence, failure learning candidates, and next recommendations.
+- `scale ai-os benchmark` runs fixed beta scenarios and reports context token use, estimated savings, memory recall, skill steps, governance modes, and the current dashboard health snapshot.
+- `scale ai-os migrate` creates or verifies the `.scale/ai-os` runtime directories and writes an idempotent migration report.
+- `scale ai-os doctor --lang zh|en` checks AI OS runtime readiness without mutating the project and blocks adoption when required directories or dashboard health are broken.
+- `scale upgrade check/plan` includes AI OS readiness, so existing projects see migration and doctor steps through the normal upgrade workflow.
+- It does not yet create PRs or mutate source files; richer skill execution remains the next implementation slice.
+
+Explicitly deferred:
+
+- default automatic PR creation or merge without review
+- deep dynamic dependency sandboxing beyond audit, lockfile diff, and high-risk pattern checks
+- full VLM visual judgment beyond screenshot capture and interface placeholders
+- claims of human-level long-term memory or fully autonomous engineering
+
+### 6.4 0.29.0: Memory, Context, and Skill Intelligence
+
+Theme: make the beta loop measurably smarter rather than only broader.
+
+Core work:
+
+| Module | Outcome |
+| --- | --- |
+| Memory Quality Scoring | score recall precision, contradiction risk, accepted memory rate, and stale-memory risk |
+| Provider Fallback Policy | choose between gbrain, agentmemory, code memory, local memory, or no memory with an explicit reason |
+| Context Compression | summarize low-risk context while preserving high-risk evidence verbatim |
+| Skill Strategy Learning | learn preferred tools from successful evidence, failures, and user overrides |
+| Workflow Eval Integration | turn benchmark results into release-gate evidence |
+
+Exit criteria:
+
+- memory recall has acceptance/rejection feedback
+- context packs show savings, omissions, and evidence-loss warnings
+- skill routing decisions can be compared against outcome quality
+- release notes include measured deltas instead of aspirational percentages
+
+### 6.5 0.30.0: Enterprise Governance and Upgrade Maturity
+
+Theme: deepen adaptive governance beyond the v0.27.0 baseline.
+
+Core work:
+
+| Module | Outcome |
+| --- | --- |
+| Adaptive Workflow Router | production policy controls for dynamic gate profiles beyond the v0.27.0 planning output |
+| Evaluator Intelligence | critique and uncertainty gates for architecture/root-cause work |
+| Tool Strategy Planner | cost, retry, fallback, and evidence graph for tools |
+| Evolution Shadow Promotion | lessons become rules only after validation |
+
+Exit criteria:
+
+- small tasks can stay lightweight with evidence
+- risky tasks escalate automatically
+- reasoning-heavy tasks get critique/evaluator gates
+- evolution proposals can be traced to failure evidence and validation results
+
+### 6.6 1.0.0 Beta: AI Engineering OS
+
+Theme: integrate governance, memory, context, and tools into an operating layer.
+
+Target capabilities:
+
+- unified agent workspace policy
+- provider-neutral memory and code intelligence
+- cross-agent execution ledger
+- adaptive workflow templates
+- measurable token and quality reports
+- ecosystem-safe skill and MCP lifecycle governance
+
+Release criteria:
+
+- install, upgrade, run, dashboard, benchmark, and migration flows work on clean projects
+- at least three representative project types have documented smoke results
+- failure learning produces reviewed rule candidates without silently hardening bad rules
+- bilingual docs explain the core workflow without requiring maintainer context
+- public claims are tied to `WORKFLOW_EVAL`, benchmark output, or release evidence
+
+### 6.7 Long-Range Vision: 3-12 Months
+
+This is the strategic north star, not the one-week beta promise.
+
+| Time horizon | Target state | Evidence required before public claim |
+| --- | --- | --- |
+| 8-12 weeks | AI Engineering OS beta: usable end-to-end loop across planning, execution, verification, memory, and dashboard | repeatable demo projects and benchmark reports |
+| 3-6 months | stable governance runtime: upgrades, adapters, memory providers, and eval gates are reliable in real repositories | release-to-release regression data and field reports |
+| 6-12 months | industry-leading agent engineering layer: adaptive workflows, strategy memory, tool intelligence, and cross-agent governance mature together | comparative evals, sustained issue closure, external adoption evidence |
+
+Long-range capability themes:
+
+- Cognitive memory: working, episodic, semantic, procedural, and strategy memory with explicit source and freshness controls.
+- Adaptive orchestration: workflows selected by risk, ownership, failure history, and tool reliability instead of one fixed path.
+- Tool intelligence: skills, MCP, CLIs, browser automation, and agent adapters treated as governed capabilities with cost, evidence, and fallback policy.
+- Evaluator intelligence: critique loops, uncertainty scoring, adversarial review, and evidence insufficiency verdicts for reasoning-heavy tasks.
+- Governance economics: token cost, gate friction, verification quality, and maintenance overhead measured as first-class product metrics.
+- Ecosystem governance: external skills, memory providers, adapters, and templates integrated through attribution, license, source pinning, and supply-chain checks.
+
+Non-negotiable boundary:
+
+> The long-range vision can guide architecture, but it must not be used as a release claim until the corresponding evidence exists.
+
+## 7. Measurement Plan
+
+Strategic claims must be tied to measurement.
+
+| Claim | Required metric |
+| --- | --- |
+| Fewer fake completions | final-check failure rate before/after gates |
+| Fewer skipped steps | FSM blocked transition count and successful recovery rate |
+| Fewer blind retries | repeated-command detector hits and fix iteration count |
+| Lower token use | context pack token count vs baseline full-context load |
+| Better memory | recall precision, accepted memory rate, contradiction count |
+| Better skill use | recommended skill acceptance rate and evidence completion rate |
+| Better workflow quality | pass@1, average fix iterations, failure replay closure rate |
+| Safer dependencies | dependency audit block count and reviewed baseline count |
+
+Target ranges can be tracked internally, but public claims should use measured values from `WORKFLOW_EVAL`, runtime evidence, or release reports.
+
+## 8. Messaging Rules
+
+Use:
+
+- "Agent Governance Runtime"
+- "AI Engineering OS direction"
+- "runtime constraints instead of prompt-only discipline"
+- "evidence-backed workflow gates"
+- "provider-based memory and context orchestration"
+
+Avoid:
+
+- "fully autonomous engineer"
+- "guaranteed 90% AI coding rate"
+- "eliminates hallucination"
+- "zero human governance"
+- "universal memory"
+- "all tools are safe by default"
+
+The product message should be ambitious, but the engineering message must stay falsifiable.
+
+## 9. Non-Goals
+
+SCALE should not try to own every layer.
+
+Non-goals:
+
+- replacing all agent platforms
+- building a full IDE
+- becoming a generic automation shell
+- implementing every memory backend internally
+- copying external skills without attribution
+- turning every task into heavyweight enterprise ceremony
+
+The correct posture is:
+
+> Govern agent engineering work, integrate external capability providers, and require evidence at the boundaries.
+
+## 10. Documentation Placement
+
+Recommended documentation split:
+
+| Surface | Content |
+| --- | --- |
+| `README.md` / `README.en.md` | concise positioning, installation, core value, current capabilities |
+| `docs/AI_ENGINEERING_OS_POSITIONING.md` | strategic category, gaps, roadmap, messaging rules |
+| `docs/CONTEXT_BUDGET.md` | context budget and compiler mechanics |
+| `docs/MEMORY_BRAIN.md` / `docs/MEMORY_FABRIC.md` | memory provider and recall behavior |
+| `docs/SKILL_RADAR.md` / `docs/TOOL_ORCHESTRATION.md` | skill and tool routing behavior |
+| `docs/WORKFLOW_EVAL.md` | measurable evidence and improvement claims |
+
+README should not absorb this whole strategy. It should link here and keep the first screen user-focused.
+
+## 11. Strategic Summary
+
+SCALE's strongest current differentiator is not more prompts. It is a runtime governance model for AI engineering:
+
+```text
+Agent intent
+  -> governed workflow state
+  -> scoped context
+  -> role/tool policy
+  -> evidence-producing execution
+  -> verification gates
+  -> memory and evolution feedback
+```
+
+The next stage is to make this runtime more cognitive:
+
+- compile context, do not just load it
+- route memory, do not just store it
+- plan skill use, do not just recommend it
+- adapt workflow, do not just enforce one path
+- validate evolution, do not just summarize lessons
+
+If these are implemented with measurable evidence, SCALE can credibly move from "AI workflow engine" to "AI Engineering OS".

package/docs/CONTEXT_BUDGET.md

@@ -43,6 +43,40 @@ scale context pack \
   --json
 ```
 
+Build the unified AI OS runtime plan that embeds the context pack with memory, skill routing, adaptive workflow, and ROI:
+
+```bash
+scale ai-os plan \
+  --task-id TASK-123 \
+  --task "Review frontend route with browser evidence" \
+  --level L \
+  --files src/routes/upload.tsx \
+  --budget 8000 \
+  --json
+```
+
+The context pack now uses the baseline Context Compiler. Each candidate section is scored by category, task/file relevance, risk level, and budget fit. The JSON output includes compiler metadata so callers can explain why a section was loaded or omitted:
+
+```json
+{
+  "compiler": {
+    "strategy": "relevance-budget-v1",
+    "budget": 4000,
+    "totalCandidateTokens": 6200,
+    "estimatedTokenSavings": 2200,
+    "ranking": [
+      {
+        "id": "runtime-evidence",
+        "included": true,
+        "score": 292,
+        "matchedSignals": ["evidence", "high-risk-evidence"],
+        "reason": "Evidence is needed for completion and verification claims."
+      }
+    ]
+  }
+}
+```
+
 Evaluate progressive governance mode:
 
 ```bash
@@ -109,5 +143,13 @@ This is not a replacement for verification. It only decides which governance beh
 
 ## Governance ROI
 
-`scale governance roi` reports both benefit and overhead. Early ROI is estimated from context budget and risk signals. Later versions should replace estimates with measured eval data such as file reads saved, tool calls saved, fix iterations reduced, and human corrections avoided.
+`scale governance roi` reports both benefit and overhead. In v0.27.0, `scale ai-os plan` also attaches ROI modules for:
+
+- `context-budget`
+- `context-compiler`
+- `memory-provider-runtime`
+- `skill-routing-engine`
+- `progressive-governance`
+
+Early ROI is still estimated from context budget, compiler savings, recall count, skill evidence steps, and risk signals. Later versions should replace estimates with measured eval data such as file reads saved, tool calls saved, fix iterations reduced, and human corrections avoided.
 

package/docs/DEPENDENCY_AUDIT.md

@@ -28,6 +28,28 @@ scale dependency audit --changed-packages left-pad,@scope/tool --json
 
 The command exits non-zero when the active mode has blocking findings.
 
+## Verification Command Safety
+
+SCALE verification commands are security-sensitive because they are often run in CI.
+The core verification paths (`verify-task`, phase verification, workflow eval attempts, and gate commands) execute configured commands without shell expansion by default.
+
+Allowed by default:
+
+```bash
+npm run build
+npm test -- --runInBand
+node scripts/check.js --changed
+```
+
+Blocked by default:
+
+```bash
+npm test && curl https://example.com
+node scripts/check.js | tee out.txt
+```
+
+Shell metacharacters such as `&&`, `|`, `;`, `<`, `>`, backticks, and unquoted `$` are rejected before execution. Use package scripts or checked-in helper scripts for composed commands. `SCALE_ALLOW_SHELL_COMMANDS=1` re-enables shell execution only for trusted local runs and must not be enabled for untrusted PR or user-controlled CI inputs.
+
 ## G7 Integration
 
 `SecurityGate` now emits two first-class evidence sources:
@@ -82,8 +104,15 @@ The first implementation detects:
 - install lifecycle scripts
 - executable bin scripts
 - deprecated packages from lockfile metadata
+- built-in ownership/provenance watchlist matches
 - dynamic code execution: `eval`, `new Function`
 - shell execution patterns
 - suspicious network access patterns
 
+The built-in ownership/provenance watchlist currently blocks exact versions that were flagged by external package behavior analysis:
+
+- `content-type@2.0.0`
+- `type-is@2.1.0`
+- `type-js@2.1.0` (kept as a defensive alias for reports that use this package name)
+
 Future network-backed checks can add npm registry metadata and `npm audit --json` ingestion, but they should stay optional and evidence-backed.

package/docs/MEMORY_FABRIC.md

@@ -122,6 +122,7 @@ Commands:
 scale memory provider init
 scale memory provider status --json
 scale memory provider recall "OAuth callback Redis state" --json
+scale ai-os plan --task "Fix OAuth callback Redis state" --files src/auth/oauth.ts --json
 ```
 
 Provider rules:
@@ -130,5 +131,6 @@ Provider rules:
 - External providers are read-only by default. Writes require an explicit provider policy change.
 - `scale-local` remains the fallback provider through Memory Brain and only promotes reviewed, evidence-backed memory.
 - `memory pack` automatically includes a `provider-memory` section when provider recall returns relevant active memories.
+- `ai-os plan` includes both the provider recall summary and the Memory Fabric context pack, so agents can route memory before planning without pretending external memory is always available.
 
 This keeps agents flexible: they can ask the router for memory before planning, verification, review, or release, while SCALE still records which provider was used and why fallback was required.

package/docs/README.md

@@ -36,6 +36,7 @@
 | [CODE_INTELLIGENCE.md](CODE_INTELLIGENCE.md) | CodeGraph、Graphify 和显式 fallback 的代码智能与探索 ROI |
 | [WORKFLOW_EVAL.md](WORKFLOW_EVAL.md) | Workflow Eval、pass@k 指标、Failure Replay 和改进候选 |
 | [SKILL_RADAR.md](SKILL_RADAR.md) | Skill Radar、能力置信度、证据要求和供应链安全检查 |
+| [AI_ENGINEERING_OS_POSITIONING.md](AI_ENGINEERING_OS_POSITIONING.md) | Agent Governance Runtime / AI Engineering OS 方向、`scale ai-os plan/run/dashboard/benchmark/migrate/doctor` runtime 入口、一周 beta 闭环和 3-12 个月远景路线 |
 | [THIRD_PARTY_SKILLS.md](THIRD_PARTY_SKILLS.md) | 第三方 skill 致谢、授权边界、引用方式和 vendoring 策略 |
 | [EXTERNAL_REFERENCES.md](EXTERNAL_REFERENCES.md) | 外部项目、skills、MCP、CLI 和适配器引用的完整清单 |
 | [UPGRADE_MANAGEMENT.md](UPGRADE_MANAGEMENT.md) | SCALE CLI、governance pack、skills、MCP 和 CLI 工具的安全升级流程 |