@cassiomc1/forgeloop 2.0.0-rc.4 → 2.0.0

package/CONTRIBUTING.md

@@ -86,7 +86,9 @@ forwarded to Node. Unsupported options and unmatched selectors fail explicitly.
 Run `npm run complexity:check` with lint. Reductions are welcome; increases to
 the committed hotspot budget require an explicit explanation and review.
 TypeScript and YAML are development-only dependencies for packed-consumer and
-semantic workflow verification; the core runtime has no npm dependencies.
+semantic workflow verification. The core runtime exact-pins `@typesafe-ai/sdk`
+for the mandatory semantic decision plane and `smol-toml` for structural Cargo
+parsing; `scripts/check-dependency-policy.mjs` owns the allowlist.
 
 Filesystem transaction-payload maintenance is retired with the SQLite
 migration. Preserve legacy evidence for explicit migration and diagnosis. See

package/DOCS_INDEX.md

@@ -19,6 +19,7 @@ integration and guide context. Use this map before editing documentation.
 | Cross-harness continuity | [`docs/CROSS_HARNESS_CONTINUITY.md`](./docs/CROSS_HARNESS_CONTINUITY.md) | Operational resume guidance, immutable handoffs, and multi-tool resumption |
 | Agent bootstrap summary | [`docs/AGENT_PROTOCOL_SUMMARY.md`](./docs/AGENT_PROTOCOL_SUMMARY.md) | Generated concise navigation aid for protocol invariants and commands |
 | Agent Skill integration | [`docs/AGENT_SKILL.md`](./docs/AGENT_SKILL.md) | Generated portable, non-authoritative agent guidance and freshness contract |
+| Engineering guide maintenance | [`docs/GUIDE_MAINTENANCE.md`](./docs/GUIDE_MAINTENANCE.md) | Full catalog review scope, policy boundaries, source map, and revalidation procedure |
 | CLI command reference | [`docs/CLI_REFERENCE.md`](./docs/CLI_REFERENCE.md) | Full syntax, options, and JSON examples for all commands |
 | Repository Index and Search | [`docs/REPOSITORY_INDEX.md`](./docs/REPOSITORY_INDEX.md) | Mandatory managed engine, indexed search contract, lifecycle, resource, security, and benchmark behavior |
 | Persistent CLI search transport | [`docs/PERSISTENT_SEARCH_TRANSPORT.md`](./docs/PERSISTENT_SEARCH_TRANSPORT.md) | CLI-only local IPC, host lifecycle, ownership, recovery, bounds, privacy, and direct API/MCP boundary |
@@ -36,10 +37,12 @@ integration and guide context. Use this map before editing documentation.
 | Platform adapters | [`docs/PLATFORM_ADAPTERS.md`](./docs/PLATFORM_ADAPTERS.md) | Generic CI boundary and platform mapping guidance |
 | Universal integration API | [`docs/UNIVERSAL_INTEGRATION.md`](./docs/UNIVERSAL_INTEGRATION.md) | Programmatic integration subpath, envelope semantics, and consumer map |
 | Audit UX read model | [`docs/AUDIT_UX.md`](./docs/AUDIT_UX.md) | Bounded read-only task timeline, health, verification, ownership, and completion projection |
+| ForgeLoopAudit workspace | [`docs/FORGELOOP_AUDIT.md`](./docs/FORGELOOP_AUDIT.md) | In-repository Audit setup, project inspection, view walkthrough, screenshots and verification links |
 | Advisory context providers | [`docs/ADVISORY_CONTEXT.md`](./docs/ADVISORY_CONTEXT.md) | Optional external host context, non-evidence trust boundary, allowlist normalization, and safety rules |
 | Provider extension architecture | [`docs/PROVIDER_ARCHITECTURE.md`](./docs/PROVIDER_ARCHITECTURE.md) | Provider-neutral architecture, invocation lifecycle, strict snapshots, cancellation, trust, and authority boundaries |
 | Provider extension reference | [`docs/PROVIDERS.md`](./docs/PROVIDERS.md) | Capability discovery, provider kinds, common contract, limits, errors, and maintainer checklist |
 | Security Review provider | [`docs/SECURITY_REVIEW.md`](./docs/SECURITY_REVIEW.md) | Bounded host-injected observation API, strict findings, timeout/cancellation, and non-authority boundary |
+| Cloudflare security audit companion | [`docs/SECURITY_AUDIT_SKILL.md`](./docs/SECURITY_AUDIT_SKILL.md) | Pinned optional source-audit workflow, host setup, report validation, and ForgeLoop authority boundary |
 | Ripwire advisory adapter | [`docs/RIPWIRE_ADAPTER.md`](./docs/RIPWIRE_ADAPTER.md) | Ripwire-specific registration, process contract, JSON mapping, limits, and verification |
 | OpenSrc advisory adapter | [`docs/OPENSRC_ADAPTER.md`](./docs/OPENSRC_ADAPTER.md) | OpenSrc-specific registration, version qualification, cache containment, deterministic search, limits, and verification |
 | Agent Browser verification adapter | [`docs/AGENT_BROWSER_ADAPTER.md`](./docs/AGENT_BROWSER_ADAPTER.md) | Optional host-owned browser executable, bounded observation mapping, isolation, exact origins, screenshots, and trust boundary |

package/ENG/accessibility-eng.md

@@ -3,7 +3,7 @@ name: accessibility-eng
 language: en
 description: "Practical WCAG 2.2-oriented accessibility protocol for web, mobile, and desktop."
 version: "2026.09"
-last-reviewed: "2026-08-31"
+last-reviewed: "2026-10-17"
 guide-id: accessibility
 completion-evidence:
   - keyboard-navigation
@@ -15,7 +15,7 @@ completion-evidence:
 
 > Accessibility instructions adapted from the [A11Y.md](https://github.com/fecarrico/A11Y.md) project (Felipe A. Carriço, MIT license) — a validation protocol and persistent context system for building accessible software from the very first line of code, informed by **WCAG 2.2** and **ISO 9241-171**. It can support evidence for applicable **ADA** or **EAA** obligations, but does not itself determine legal compliance.
 > **Related documents**: for visual/UX direction (palettes, typography, motion), see [`design-code-eng.md`](./design-code-eng.md). For automated testing tools (axe-core, Lighthouse, visual regression), see [`test-code-eng.md`](./test-code-eng.md). For code quality/structure, see [`clean-code-eng.md`](./clean-code-eng.md). For HTML-based video and motion, also see [HyperFrames](https://hyperframes.heygen.com). This file is the canonical reference for **accessibility rules** (WCAG, ARIA, keyboard, focus, screen readers) — it does not repeat the content of the others.
-> **Tooling policy**: identify the stack, the stage, and the applicable checks; prefer an already available equivalent that produces compatible evidence. Ask for authorization before installing a tool or changing the environment. If no safe equivalent exists, record the required check as blocked and never claim that it passed. Do not install merely optional resources.
+> **Tooling policy**: identify the stack, the stage, and the applicable checks; prefer an already available equivalent that produces compatible evidence. Installation or environment changes require authority; reuse scoped authorization already given rather than asking again. If no safe equivalent exists, record the required check as blocked and never claim that it passed. Do not install merely optional resources.
 
 ## 0. Principle Zero: accessibility as a pre-condition
 
@@ -25,7 +25,7 @@ completion-evidence:
 
 ## 0.1. Compliance profiles
 
-This document's default implementation target is **Standard (AA)**. It supports WCAG-oriented implementation; it does not certify a product or establish automatic legal compliance. Certification and legal obligations depend on an assessment with defined scope, evidence, and the applicable jurisdiction. When generating or reviewing interface code, the agent **MUST ask** the user which profile to apply if not already specified:
+This document's default implementation target is **Standard (AA)**. Preserve a stronger existing requirement. If no profile is specified, record AA as a reversible assumption and continue; profile selection alone is not a user-approval gate. Ask only when a genuine blocking obligation cannot be established from project evidence, following Loop Engineering's decision classification. This guide supports WCAG-oriented implementation; it does not certify a product or establish automatic legal compliance. Certification and legal obligations depend on an assessment with defined scope, evidence, and the applicable jurisdiction.
 
 | Profile | Target | Contrast (text / UI) | Min font† | Min target | Use case |
 | :--- | :--- | :--- | :--- | :--- | :--- |
@@ -67,14 +67,14 @@ To ensure technical integrity, any AI interacting with the project **MUST**:
 
 ### Perceivable
 
-- **Contrast (SC 1.4.3, 1.4.11):** text **MUST** have 4.5:1; UI components and meaningful graphics **MUST** have 3:1. Prioritize real **luminance difference** (light vs dark) beyond hue.
+- **Contrast (SC 1.4.3, 1.4.6, 1.4.11):** at AA, normal text needs at least 4.5:1 and large-scale text at least 3:1; at AAA, those thresholds are 7:1 and 4.5:1. Use WCAG's large-scale definition and applicable exceptions, not an arbitrary heading label. Required non-text component/state and graphic contrast is 3:1 where SC 1.4.11 applies. Do not round a failing ratio up. See the [W3C contrast explanation](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html); prioritize luminance difference beyond hue.
 - **Alt text (SC 1.1.1):** informative images **MUST** have a functional description in `alt`; decorative images use `alt=""` or `aria-hidden="true"`.
 - **Channels beyond color (SC 1.4.1):** **MUST NOT** convey state, action, response, or information with color alone. Choose the additional channel appropriate to the meaning — visible text, icon, pattern, or programmatic semantics — without imposing the same visual redundancy in every case.
 - **Visual patterns:** when differentiation in charts or dashboards depends on color, patterns, labels, textures, or distinct line styles **MUST** enable users to distinguish series without color.
 
 ### Operable
 
-- **Keyboard (SC 2.1.1):** all functionality **MUST** be operable without a mouse. Where the function depends on the path of movement rather than only its endpoints, document why the WCAG exception applies and provide a practical alternative when possible. Avoid purely pointer-based listeners without keyboard event equivalents (`onKeyDown`).
+- **Keyboard (SC 2.1.1):** all functionality **MUST** be operable without a mouse. Prefer native controls and their built-in keyboard activation; do not add duplicate `onKeyDown` activation to a native button. Custom widgets need the complete applicable keyboard pattern. Where the function depends on the path of movement rather than only its endpoints, document why the WCAG exception applies and provide a practical alternative when possible.
 - **Focus (SC 2.4.7, 2.4.11):** focus **MUST** be visible, never entirely obscured by author content (e.g., sticky headers/footers), persistent, and never suppressed via CSS (`outline: none` without fallback is forbidden).
 - **SPA routing:** after client-side routing changes, focus **MUST** be managed and properly reset (e.g., sending focus to the top or an `h1`). Avoid lost focus on the screen.
 - **Focus order and lifecycle (SC 2.4.3):** the sequential keyboard path **MUST** preserve meaning and operability. Prefer alignment between DOM order, reading order, and visual order when divergence would create confusing or illogical navigation. Avoid positive `tabindex` as a ForgeLoop accessibility best practice; repair the document structure whenever practical. When content is inserted, removed, expanded, collapsed, replaced, or routed, define the next logical focus destination and do not leave focus on a removed or unavailable node.
@@ -118,7 +118,7 @@ These directives combine WCAG requirements where identified and this guide's erg
 When identifying an unmapped or highly complex component (e.g., charts, dynamic grids):
 
 1. **Identify:** look for a similar pattern in the [WAI-ARIA APG](https://www.w3.org/WAI/ARIA/apg/).
-2. **Validate:** request human validation with a screen reader — the AI **MUST NOT** claim this test was performed, nor fabricate its results.
+2. **Validate:** test the pattern in the supported screen-reader/browser combinations when available. If human validation is required and unavailable, record the exact unverified combination and owner action; continue independent work. An AI **MUST NOT** claim an unperformed test or fabricate its results.
 3. **Document:** document the expected behavior (keyboard and announcements).
 4. **Scale:** record the resolved pattern in `A11Y-DECISIONS.md` so future components reuse it instead of re-deriving it.
 

package/ENG/clean-code-eng.md

@@ -3,7 +3,7 @@ name: clean-code-eng
 language: en
 description: "Practices for readable, observable, secure code operated by AI agents."
 version: "2026.09"
-last-reviewed: "2026-08-10"
+last-reviewed: "2026-10-17"
 guide-id: clean
 ---
 
@@ -13,7 +13,7 @@ guide-id: clean
 >
 > **Related documents**: for language-specific testing frameworks and tools, see [`test-code-eng.md`](./test-code-eng.md). For security, see [`sec-code-eng.md`](./sec-code-eng.md), the canonical reference for secrets, authorization, cryptography, and sensitive-data redaction. For visual/UX guidelines, see [`design-code-eng.md`](./design-code-eng.md). For HTML-based video and motion, see [HyperFrames](https://hyperframes.heygen.com). This guide focuses on code quality, structure, and operation.
 >
-> **Tooling policy**: identify the stack, the stage, and the applicable checks; prefer an already available equivalent that produces compatible evidence. Ask for authorization before installing a tool or changing the environment. If no safe equivalent exists, record the required check as blocked and never claim that it passed. Do not install merely optional resources.
+> **Tooling policy**: identify the stack, the stage, and the applicable checks; prefer an already available equivalent that produces compatible evidence. Installation or environment changes require authority; reuse scoped authorization already given rather than asking again. If no safe equivalent exists, record the required check as blocked and never claim that it passed. Do not install merely optional resources.
 
 ## Context
 

package/ENG/design-code-eng.md

@@ -3,7 +3,7 @@ name: design-code-eng
 language: en
 description: "Visual direction, UX, motion, and perceived performance for premium digital experiences."
 version: "2026.09"
-last-reviewed: "2026-08-31"
+last-reviewed: "2026-10-17"
 guide-id: design
 requires-gates:
   - design
@@ -13,25 +13,25 @@ completion-evidence:
 
 # Web Design Premium v2 — Practical Guidelines
 
-> This guide provides strong defaults, not a blind recipe. Use its values, palettes, and snippets as a verifiable starting point; depart from them only for an explicit user/product requirement or a documented exception that preserves hierarchy, accessibility, and performance. Do not invent values "by eye".
+> This guide provides starting points for a coherent interface. Preserve the product's existing tokens, components, platform conventions, and brand before selecting a new palette or font. Numeric values, example layouts, aesthetic bans, and snippets below are contextual defaults, not universal compliance rules or approval gates. Record meaningful departures with a short rationale and validate hierarchy, accessibility, and performance.
 > **Related documents**: for the complete studio-level website production process, see [`premium-sites-studio-eng.md`](./premium-sites-studio-eng.md). For the quality/structure of the code that implements this design, see [`clean-code-eng.md`](./clean-code-eng.md). For accessibility/visual/E2E testing, see [`test-code-eng.md`](./test-code-eng.md). For form security, authentication, and client-side storage, see [`sec-code-eng.md`](./sec-code-eng.md). To translate visual direction into HTML video, see [HyperFrames](https://hyperframes.heygen.com). This file focuses exclusively on UI/UX/visuals — it does not repeat code, testing, or security rules.
 >
-> **Tooling policy**: identify the stack, the stage, and the applicable checks; prefer an already available equivalent that produces compatible evidence. Ask for authorization before installing a tool or changing the environment. If no safe equivalent exists, record the required check as blocked and never claim that it passed. Do not install merely optional resources.
+> **Tooling policy**: identify the stack, the stage, and the applicable checks; prefer an already available equivalent that produces compatible evidence. Installation or environment changes require authority; reuse scoped authorization already given rather than asking again. If no safe equivalent exists, record the required check as blocked and never claim that it passed. Do not install merely optional resources.
 
 ## How to use this guide (strong default process)
 
 Adopt this order as the default when creating a page from scratch; document an exception when the product, platform, or user requires a different sequence:
 
-1. **Choose 1 ready-made semantic palette** from the "Ready-made semantic palettes" section (do not mix palettes).
-2. **Choose 1 ready-made typographic combination** from the "Typographic Combinations" section.
-3. **Define the page's section list** using the "Premium Page Anatomy".
-4. **Apply the exact grid and spacing** from the "Layout & Spacing" section.
-5. **Apply components** (buttons, cards, nav) with the exact specs from the "Components" section.
-6. **Add motion** only according to the snippets in the "Motion" section — never "creative" motion outside the standard.
+1. **Confirm semantic color roles** from the existing design system; use a sample palette when no system exists.
+2. **Confirm typography roles and language coverage**; use a sample combination when appropriate.
+3. **Define the section list from the content and user journey**; use the anatomy as a reference.
+4. **Apply a coherent grid and spacing scale** with responsive content checks.
+5. **Reuse components and their interaction states**; adapt sample specifications to the product.
+6. **Add purposeful motion** only when it helps the experience, with reduced-motion and static fallbacks.
 7. **Run the Anti-Slop Checklist** before considering it ready.
-8. **Audit and polish the entire interface with Impeccable**: run `/impeccable audit` to identify quality issues and `/impeccable polish` to apply improvements. Evaluate the complete interface, not only one component, preserve the existing design system, and repeat the audit after the changes.
+8. **Audit and polish the affected experience** with the available project tools and direct browser/device inspection. Impeccable is an optional aid when installed and relevant; its availability is not a completion gate. Preserve the design system and recheck the changed states.
 
-Do not skip steps 1 and 2 without a documented exception. The biggest cause of an "amateur" result is mixing random palettes/fonts or using framework defaults (e.g., Bootstrap blue, Inter everywhere, generic shadow `box-shadow: 0 0 10px rgba(0,0,0,0.1)`).
+Keep color and type decisions intentional. A familiar font, framework default, or repeated component is not a defect by itself; assess its fit, readability, hierarchy, and consistency in the actual interface.
 
 > **This guide covers 3 contexts.** For web sites/products (desktop and mobile), follow the flow above normally. For **native mobile apps** (iOS/Android), go directly to the "Premium Mobile Apps" section. For **native desktop apps** (Windows/macOS), go to "Premium Desktop Apps". In the latter two cases, this guide's palettes and typography still serve as tone references, but platform guidelines (HIG, Material Design, Fluent) take priority over the generic values defined here.
 
@@ -227,7 +227,7 @@ When the output is a video, trailer, product demo, or motion graphic rendered fr
 - Prefer deterministic, frame-controllable animation with a paused/seekable timeline so preview, tests, and rendering reproduce the same result.
 - Keep text large enough for the output format, maintain AA contrast and safe areas, and do not make meaning depend on audio or motion.
 - Respect `prefers-reduced-motion` in interactive previews and provide a static or reduced-motion alternative when appropriate.
-- Start with the [official quickstart](https://hyperframes.heygen.com/quickstart) and use `npx hyperframes preview`, `npx hyperframes lint`, and `npx hyperframes render` in the quality loop when the project uses the CLI.
+- Start with the [official quickstart](https://hyperframes.heygen.com/quickstart). Use the project's pinned, already-installed CLI for `preview`, `lint`, `check`, and `render`, verifying the installed command help. Do not use an install-capable launcher merely to obtain a missing verifier; installation authority remains separate.
 
 Motion rules:
 
@@ -594,7 +594,7 @@ For React-specific supplemental diagnostics after implementation, including desi
 - [ ] Where the platform exposes contrast/transparency preferences, including `prefers-contrast` or `forced-colors` when applicable, the opaque/less-transparent variant works; without a reliable media query, there is an equivalent in-product control.
 - [ ] No item from the "Blacklist" is present.
 - [ ] Tested at 320 CSS px reflow and desktop (1440px).
-- [ ] Ran `/impeccable audit` and `/impeccable polish` across the entire interface and addressed applicable findings.
+- [ ] Reviewed the affected interface and states with available tools and browser/device evidence; optional Impeccable findings were addressed when that tool was used.
 
 ---
 

package/ENG/documentation-quality-eng.md

@@ -3,7 +3,7 @@ name: documentation-quality-eng
 language: en
 description: "Quality standards for accurate, task-oriented, maintainable, accessible, and verifiable technical documentation."
 version: "2026.09"
-last-reviewed: "2026-08-17"
+last-reviewed: "2026-10-17"
 guide-id: documentation
 ---
 
@@ -11,7 +11,7 @@ guide-id: documentation
 
 > **Related documents**: use [`clean-code-eng.md`](./clean-code-eng.md) when software behavior or code structure changes; [`test-code-eng.md`](./test-code-eng.md) for executable examples and verification strategy; [`sec-code-eng.md`](./sec-code-eng.md) for secrets, authentication, authorization, privacy, and sensitive examples; [`accessibility-eng.md`](./accessibility-eng.md) when a published documentation surface has additional accessibility requirements. This guide owns documentation architecture, factual quality, freshness, maintainability, and reader usability.
 >
-> **Tooling policy**: identify the documentation surface, canonical sources, and existing project checks first. Prefer already available project-native tools. Ask for authorization before installing tooling or changing the environment. If a required check cannot be executed, record it as blocked or `NOT_VERIFIED`; never claim it passed.
+> **Tooling policy**: identify the documentation surface, canonical sources, and existing project checks first. Prefer already available project-native tools. Installation or environment changes require authority; reuse scoped authorization already given rather than asking again. If a required check cannot be executed, record it as blocked or `NOT_VERIFIED`; never claim it passed.
 
 ## Context
 
@@ -128,6 +128,14 @@ Update affected documentation in the same task when the change is required for c
 
 ## Freshness and timeless wording
 
+When reviewing engineering guides, compare the full catalog with its registry,
+activation implementation, and metadata. Separate implemented capability from
+proposed integration, sample check names from required evidence identifiers,
+and contextual defaults from protocol or user-approval gates. A named tool
+does not become mandatory merely because an example uses it. Record the
+review's scope and unavailable consumer/platform checks; a fresh review date
+does not certify every referenced API or framework.
+
 Avoid time-sensitive words such as `new`, `currently`, `latest`, `now`, or `soon` in evergreen technical documentation when they will age without adding information.
 
 Use explicit versions or dates when history or compatibility requires them.

package/ENG/flutter-development-eng.md

@@ -3,7 +3,7 @@ name: flutter-development-eng
 language: en
 description: "Specialist guide for architecture, implementation, testing, performance, accessibility, platform integration, and release of production Flutter applications."
 version: "2026.09"
-last-reviewed: "2026-10-13"
+last-reviewed: "2026-10-17"
 guide-id: flutter
 ---
 # Flutter Development Engineering Guide
@@ -1922,39 +1922,13 @@ A Flutter task is complete only when the applicable items are satisfied.
 
 ## 53. ForgeLoop guide routing integration
 
-This file is designed to live at:
+The `flutter` guide is registered in `src/config/guides.json` and already
+participates in the canonical router. The bounded project detector confirms
+Flutter from a parsed `pubspec.yaml` with an actual Flutter SDK dependency,
+then matches the affected claims to that project root. It does not execute
+Flutter, Dart, package scripts, generators, or SDK discovery during routing.
 
-```text
-ENG/flutter-development-eng.md
-```
-
-To make the current ForgeLoop `GUIDE_ROUTER.md` select it automatically, the repository should add a canonical catalog entry similar to:
-
-```markdown
-| `flutter` | [Flutter development](ENG/flutter-development-eng.md) | Architecture, UI, state, platform integration, testing, performance, and release for Flutter applications |
-```
-
-Add a domain rule similar to:
-
-```markdown
-### `flutter` — Flutter application engineering
-
-Activate when: designing, implementing, testing, debugging, profiling, integrating, or releasing a Flutter or Dart application where Flutter is an actual project stack.
-
-Do not activate merely because: documentation mentions Flutter, a generated Flutter example exists, or a dependency name contains "flutter" without the affected application being a Flutter project.
-
-Usually combine with: `clean` and `test`; add `design` and `accessibility` for user-facing UI, `security` for networking/auth/data/plugins/release, and `performance` for rendering/startup/memory/network critical paths.
-
-    rg -n '^## |architecture|ViewModel|state|widget|layout|navigation|deep link|network|serialization|isolate|platform|plugin|FFI|web|accessibility|performance|test|release|Definition of Done' ENG/flutter-development-eng.md
-
-Expected evidence: Flutter/Dart version awareness, architecture-consistent implementation, analyzer/test evidence, accessibility/adaptive checks for UI, platform-boundary validation where changed, and an affected-target build when feasible.
-```
-
-The deterministic router may also need an explicit stack signal or routing rule if the current schema cannot identify Flutter from verified project manifests. Do not make natural-language string matching the sole proof that a project is Flutter. A strong deterministic signal is the presence and parsed content of `pubspec.yaml` with an actual Flutter SDK dependency, combined with affected surfaces/platform signals.
-
-## 54. Suggested deterministic Flutter stack evidence
-
-A repository can be classified as Flutter when evidence such as the following is confirmed:
+The primary manifest signal is:
 
 ```yaml
 dependencies:
@@ -1962,32 +1936,37 @@ dependencies:
     sdk: flutter
 ```
 
-Useful supporting signals:
-
-- `.metadata` identifies a Flutter project;
-- Flutter platform runners exist and are part of build/release configuration;
-- `flutter_test` is present under development dependencies;
-- CI invokes Flutter tooling.
-
-Do not classify as Flutter only because a lockfile contains a transitive package with "flutter" in its name.
-
-## 55. Suggested completion evidence identifiers
-
-If ForgeLoop's evidence schema is extended for Flutter, useful semantic identifiers may include:
-
-```text
-flutter-format
-flutter-analyze
-flutter-unit-widget-tests
-flutter-integration-tests
-flutter-target-build
-flutter-accessibility-validation
-flutter-performance-profile
-flutter-native-integration
-flutter-deep-link-validation
-```
-
-Do not add identifiers to ForgeLoop protocol schemas without updating validators, tests, documentation, and compatibility surfaces together.
+Pure Dart packages, platform runner directories, `.metadata`, `flutter_test`,
+CI tooling, generated examples, and transitive package names do not substitute
+for that primary Flutter identity. Preserve nested project ownership.
+
+For implementation, use the route returned by the current runtime and combine
+it with the guides selected for the actual surfaces and risks. UI may require
+design/accessibility checks; trust boundaries require security checks;
+performance work requires measured evidence. Do not manually invent a routed
+guide set or duplicate routing rules in a host integration.
+
+## 54. Discovery versus verification
+
+A confirmed manifest establishes project identity, not analyzer success,
+compilation, device support, accessibility, or release readiness. Inspect the
+repository's pinned SDK, dependency graph, platform configuration, and actual
+commands after routing. Collect those outcomes separately through the normal
+verification flow; missing SDKs, devices, signing, and platform checks remain
+explicitly unverified.
+
+## 55. Task-specific verification checks
+
+Choose check IDs that explain the observation, such as `flutter-analyze`,
+`flutter-unit-widget-tests`, `flutter-target-build`, or
+`flutter-deep-link-validation`, and bind each check to a requirement from the
+active contract or selected guide metadata. These are example check names,
+not new protocol enums or automatic completion requirements.
+
+This guide's frontmatter does not declare an extra Flutter-specific gate or
+completion-evidence ID. Required gates and evidence come from the actual
+contract, route, metadata, and canonical runtime. Record executed commands
+with `run-check`; a formatted check name or manifest match is not evidence.
 
 ## 56. Official documentation map
 

package/ENG/games-code-design-web-eng.md

@@ -3,7 +3,7 @@ name: games-code-design-web-eng
 language: en
 description: "Architecture, design, testing, and operation of 2D, 3D, and procedural web games."
 version: "2026.09"
-last-reviewed: "2026-08-10"
+last-reviewed: "2026-10-17"
 guide-id: games
 requires-gates:
   - simulation
@@ -18,7 +18,7 @@ completion-evidence:
 >
 > **Related documents**: for general code structure, naming, dependency injection, and debugging, see [`clean-code-eng.md`](./clean-code-eng.md). For test strategy and tools such as Vitest and Playwright, see [`test-code-eng.md`](./test-code-eng.md). For browser security, CSP, dependency scanning, and multiplayer threat models, see [`sec-code-eng.md`](./sec-code-eng.md). For budgets, profiling, WebAssembly, PWA, CDN, and device performance, see [`perf-code-eng.md`](./perf-code-eng.md). For visual direction, UX, motion, and responsive design, see [`design-code-eng.md`](./design-code-eng.md). For WCAG 2.2-oriented implementation, assistive technology, and manual testing, see [`accessibility-eng.md`](./accessibility-eng.md). For HTML-based gameplay trailers, devlogs, and demos, see [HyperFrames](https://hyperframes.heygen.com). This guide focuses on game architecture and delivery; it does not replace those documents.
 >
-> **Tooling policy**: identify the stack, the stage, and the applicable checks; prefer an already available equivalent that produces compatible evidence. Ask for authorization before installing a tool or changing the environment. If no safe equivalent exists, record the required check as blocked and never claim that it passed. Do not install merely optional resources.
+> **Tooling policy**: identify the stack, the stage, and the applicable checks; prefer an already available equivalent that produces compatible evidence. Installation or environment changes require authority; reuse scoped authorization already given rather than asking again. If no safe equivalent exists, record the required check as blocked and never claim that it passed. Do not install merely optional resources.
 
 ## How to use this guide (mandatory process)
 

package/ENG/perf-code-eng.md

@@ -3,7 +3,7 @@ name: perf-code-eng
 language: en
 description: "Performance measurement, diagnosis, and improvement for web, mobile, desktop, APIs, and data."
 version: "2026.09"
-last-reviewed: "2026-08-10"
+last-reviewed: "2026-10-17"
 guide-id: performance
 completion-evidence:
   - performance-validation
@@ -13,7 +13,7 @@ completion-evidence:
 
 > Practical instructions for designing, measuring, diagnosing, and improving performance in web, mobile (iOS/Android), desktop (Windows/macOS), APIs, infrastructure, and databases. Use this document to guide AI agents and developers. Performance must be measured in real scenarios before and after the change — do not optimize based on assumptions.
 > **Related documents**: for code structure and readability, see [`clean-code-eng.md`](./clean-code-eng.md). For functional, integration, and E2E testing, see [`test-code-eng.md`](./test-code-eng.md). For security and cache, secrets, and infrastructure trade-offs, see [`sec-code-eng.md`](./sec-code-eng.md). For perceived performance, UX, motion, and responsive design, see [`design-code-eng.md`](./design-code-eng.md). For HTML video preview and rendering performance, see [HyperFrames](https://hyperframes.heygen.com). This file is the canonical performance reference.
-> **Tooling policy**: identify the stack, the stage, and the applicable checks; prefer an already available equivalent that produces compatible evidence. Ask for authorization before installing a tool or changing the environment. If no safe equivalent exists, record the required check as blocked and never claim that it passed. Do not install merely optional resources.
+> **Tooling policy**: identify the stack, the stage, and the applicable checks; prefer an already available equivalent that produces compatible evidence. Installation or environment changes require authority; reuse scoped authorization already given rather than asking again. If no safe equivalent exists, record the required check as blocked and never claim that it passed. Do not install merely optional resources.
 
 ## General principles
 
@@ -22,7 +22,7 @@ completion-evidence:
 - **Optimize the critical path**: prioritize what blocks the first render, the first interaction, the most-used operation, or the flow that has the greatest impact on the user.
 - **Distribution metrics**: track median (p50), p75, p95, and p99. A healthy average can hide a minority of users with a very poor experience.
 - **Perceived performance matters**: immediate feedback, skeleton/loading state, streaming, and progressive updates can improve the experience without masking a slow operation.
-- **Do not block the main thread**: CPU work, I/O, parsing, serialization, and heavy processing should be asynchronous, parallelized, or moved to a worker/background when possible.
+- **Do not block the main thread**: use asynchronous APIs for I/O and bound parsing, serialization, and CPU-heavy work. An `async` function or Promise does not move CPU work off the event loop. Measure whether partitioning work or a bounded worker/background pool improves responsiveness, including transfer and scheduling cost. See [Node.js event-loop guidance](https://nodejs.org/en/learn/asynchronous-work/dont-block-the-event-loop).
 - **Less work is better than faster work**: eliminate unnecessary calls, renders, queries, allocations, payloads, and initializations before micro-optimizing an algorithm.
 - **Avoid speculative optimization**: do not add cache, pooling, memoization, or complexity without evidence of a bottleneck and without measuring invalidation, memory, and maintenance cost.
 - **Control concurrency and resources**: use timeouts, queue limits, backpressure, quotas, circuit breakers, and cancellation to prevent slowness from becoming resource exhaustion.

package/ENG/php-development-eng.md

@@ -3,7 +3,7 @@ name: php-development-eng
 language: en
 description: "Specialist guidance for production PHP applications, Composer packages, web services, and command-line workers."
 version: "2026.09"
-last-reviewed: "2026-10-13"
+last-reviewed: "2026-10-17"
 guide-id: php
 requires-gates:
   - threat-boundary
@@ -51,7 +51,7 @@ do not edit generated/vendor content as if it were application source.
 PHP extensions deserve special care: an extension or C-extension package may
 compose with the C specialist, but does not imply PHP implementation. Keep
 Composer-less source fallback limited to owned files with an executable
-`<?php` opening tag and do not promote generated/vendor trees.
+`<?php` or `<?=` opening tag and do not promote generated/vendor trees.
 
 ## Architecture and language semantics
 

package/ENG/premium-sites-studio-eng.md

@@ -3,7 +3,7 @@ name: premium-sites-studio-eng
 language: en
 description: "Complete process for building premium websites at major design-studio quality."
 version: "2026.09"
-last-reviewed: "2026-08-10"
+last-reviewed: "2026-10-17"
 guide-id: premium
 requires-gates:
   - design
@@ -19,7 +19,7 @@ completion-evidence:
 
 > This guide defines the production process. For detailed visual rules, also use [`design-code-eng.md`](./design-code-eng.md). For accessibility, code quality, testing, security, and performance, consult the related documents at the end. A high-end website is not only a beautiful interface: it is a coherent, useful, fast, accessible, measurable, and maintainable experience.
 >
-> **Tooling policy**: identify the stack, the stage, and the applicable checks; prefer an already available equivalent that produces compatible evidence. Ask for authorization before installing a tool or changing the environment. If no safe equivalent exists, record the required check as blocked and never claim that it passed. Do not install merely optional resources.
+> **Tooling policy**: identify the stack, the stage, and the applicable checks; prefer an already available equivalent that produces compatible evidence. Installation or environment changes require authority; reuse scoped authorization already given rather than asking again. If no safe equivalent exists, record the required check as blocked and never claim that it passed. Do not install merely optional resources.
 
 ## 1. Quality bar
 
@@ -49,6 +49,13 @@ Follow the gates in order. Within each gate, use the canonical [Loop Engineering
 
 Each gate must have a verifiable output. If a decision remains ambiguous, record the hypothesis, risk, owner, and next test; do not hide uncertainty behind aesthetics.
 
+These production stages do not create extra ForgeLoop lifecycle gates or
+mandatory user approvals. In autonomous work, resolve reversible brief,
+layout, and direction choices as recorded assumptions and continue. Ask only
+for a genuine blocking decision under Loop Engineering. Client approval and
+publication authority remain required when the actual engagement or requested
+external action requires them; a generic checklist cannot invent that boundary.
+
 ## 3. Gate 1 — Brief, strategy, and success
 
 Before choosing colors or components, produce a short brief:

package/ENG/python-development-eng.md

@@ -3,7 +3,7 @@ name: python-development-eng
 language: en
 description: "Specialist guidance for production Python applications, libraries, command-line tools, data pipelines, and native extensions."
 version: "2026.09"
-last-reviewed: "2026-10-13"
+last-reviewed: "2026-10-17"
 guide-id: python
 requires-gates:
   - threat-boundary
@@ -22,6 +22,12 @@ actual project from owned `.py` files and its packaging/build metadata, such as
 Do not infer Python project identity from documentation, editor settings,
 Jupyter output, a Python executable used only by CI, or a transitive package.
 
+This is reference guidance in ForgeLoop's catalog. The current structural
+project-evidence schema and router do not automatically detect Python or
+select this specialist from Python manifests. Load it explicitly when Python
+work is in scope, and inspect the canonical route for the selected guides;
+the presence of this document is not automatic-routing support.
+
 This guide is based on the official Python 3.15.0 documentation. Python 3.15.0
 was released as a stable release on 2026-10-09. Its release highlights include
 the `sentinel` and `frozendict` built-ins, UTF-8 as the default encoding,

package/ENG/rust-development-eng.md

@@ -3,7 +3,7 @@ name: rust-development-eng
 language: en
 description: "Specialist guidance for architecture, implementation, testing, security, performance, and release of production Rust applications, services, libraries, and workers."
 version: "2026.09"
-last-reviewed: "2026-10-13"
+last-reviewed: "2026-10-17"
 guide-id: rust
 requires-gates:
   - threat-boundary
@@ -113,37 +113,27 @@ does not change a project's declared MSRV, toolchain, or edition.
 
 ### Rust 1.99.0 release review
 
-The [Rust 1.99.0 release notes](https://releases.rs/docs/1.99.0/) report a
-stable release on 2026-10-01. Apply these changes only when the affected
-project's toolchain and compatibility policy permit them:
-
-- **Language and unsafe code:** C-variadic function definitions are stable;
-  naked C-variadic functions remain behind the nightly
-  `c_variadic_naked_functions` feature. The new
-  `raw_borrows_via_references` lint is allow-by-default, so it does not replace
-  an explicit lint policy. Review unsafe code that relies on `UnsafeCell`
-  access or reference-to-raw-borrow behavior alongside the release's adjusted
-  `invalid_reference_casting` lint; do not infer that these changes relax
-  aliasing or safety invariants.
-- **Cargo and workspaces:** Cargo adds a `debug` profile that is currently
-  identical to `dev` and prepares for a possible later profile transition.
-  On edition 2024 or later, a workspace member can override an inherited
-  dependency's `default-features`; on earlier editions,
-  `default-features = false` remains ignored with a warning. Check the edition
-  before relying on the override.
-- **Library APIs and targets:** the release stabilizes APIs including
-  `Vec::into_parts`/`Vec::from_parts`, `Box::into_non_null`/`Box::from_non_null`,
-  `String::from_utf8_lossy_owned`, `VecDeque::retain_back`, and
-  `std::fs::set_times`. `riscv64-unknown-linux-musl` is promoted to Tier 2
-  with host tools. Check each API's stabilization version and target support
-  against the package MSRV and supported deployment matrix before adoption.
-- **Compatibility checks:** legacy integral modules such as `std::i32` are
-  fully deprecated, `no_mangle_generic_items` is a hard error, and the safety
-  invariants of `Pin::new_unchecked` have changed slightly. Rust 1.99 also
-  disables Cargo incremental compilation by default in CI and expands the
-  non-local macro semicolon warning to macros from dependencies. Review these
-  changes when diagnosing new warnings, build-time shifts, or compatibility
-  failures.
+The [official Rust 1.99.0 announcement](https://blog.rust-lang.org/2026/10/01/Rust-1.99.0/)
+and its linked standard-library documentation describe the stable release on
+2026-10-01. Review changes against the project's toolchain and compatibility
+policy:
+
+- **FFI:** C-ABI variadic definitions are stable. Distinguish those from naked
+  variadic functions with non-C ABIs, which require inline assembly. Preserve
+  ABI, argument-type, and caller-safety invariants.
+- **Raw-pointer layout:** `Layout::for_value_raw`, `mem::size_of_val_raw`, and
+  `mem::align_of_val_raw` are stabilized; their availability does not remove
+  each API's unsafe preconditions.
+- **Ownership:** the standard-library guidance discourages leaking a `Box`
+  and later reconstructing it for deallocation. Use deliberate ownership
+  transfer through `Box::into_raw` or `Box::into_non_null` when appropriate.
+- **Library compatibility:** examples of stabilized APIs include
+  `Vec::into_parts`/`Vec::from_parts`, `Box::from_non_null`, and
+  `VecDeque::retain_back`. Check exact stabilization versions against MSRV.
+
+Consult the official detailed release notes for Cargo, target, compiler, and
+lint changes before changing profiles, features, flags, or supported targets.
+Do not infer such changes from a third-party release summary.
 
 These release notes are a version-specific review aid, not a reason to raise
 MSRV or change edition, lint levels, profiles, or targets without an explicit

package/ENG/sec-code-eng.md

@@ -3,7 +3,7 @@ name: sec-code-eng
 language: en
 description: "Verifiable security guidance for web, mobile, desktop, APIs, and the software supply chain."
 version: "2026.09"
-last-reviewed: "2026-08-10"
+last-reviewed: "2026-10-17"
 guide-id: security
 requires-gates:
   - threat-boundary
@@ -27,11 +27,27 @@ reference; secrets, authorization, cryptography, and OWASP rules live here,
 not in the other files.
 
 **Tooling policy**: identify the stack, stage, and applicable checks; prefer an
-already-available equivalent that produces compatible evidence. Ask for
-authorization before installing a tool or changing the environment. If no
+already-available equivalent that produces compatible evidence. Installation or environment changes require authority; reuse scoped
+authorization already given rather than asking again. If no
 safe equivalent exists, record the required check as blocked and never claim
 it passed. Do not install merely optional resources.
 
+## Optional source security audit workflow
+
+For security questions and focused vulnerability investigation, the optional
+Cloudflare [security-audit skill](https://github.com/cloudflare/security-audit-skill)
+provides source-first guidance. ForgeLoop ships a pinned copy under
+`skills/security-audit/` in its package and source checkout. See the
+[setup and authority boundaries](https://github.com/cassiomc1/forgeloop/blob/b9a16e9f665116306e9fca3b905b1f0fe2abd633/docs/SECURITY_AUDIT_SKILL.md)
+before enabling host discovery or requesting a full audit.
+
+Use guidance mode for focused work. Reserve the complete six-phase audit for
+an explicit audit or report request; it requires independent verification and
+the upstream execution isolation controls. Keep `confirmed`,
+`needs_validation`, and `rejected` distinct, and disclose missing capabilities.
+The companion neither installs itself into target projects nor replaces this
+guide's gates, negative tests, canonical evidence, or completion validation.
+
 ## General principles (valid for any platform)
 
 - **Secure by design**: think about security during the design phase, not as a "review" at the end. Perform threat modeling for sensitive features (login, payment, file upload).