@cassiomc1/forgeloop 1.11.1 → 1.13.0

package/GUIDE_ROUTER.md

@@ -52,6 +52,18 @@ project commands.
 | `accessibility` | [Accessibility](./ENG/accessibility-eng.md) | WCAG, keyboard access, focus, semantics, and assistive technology |
 | `games` | [Web games](./ENG/games-code-design-web-eng.md) | Architecture and operation of 2D, 3D, and procedural web games |
 | `documentation` | [Documentation quality](./ENG/documentation-quality-eng.md) | Accuracy, architecture, freshness, accessibility, and verifiable technical documentation |
+| `flutter` | [Flutter application engineering](./ENG/flutter-development-eng.md) | Architecture, implementation, testing, performance, accessibility, platform integration, and release of production Flutter applications |
+| `dotnet` | [.NET and ASP.NET Core development engineering](./ENG/dotnet-aspnetcore-development-eng.md) | Architecture, implementation, testing, performance, security, data access, hosting, observability, and release of production .NET applications |
+| `nodejs` | [Node.js backend development engineering](./ENG/nodejs-backend-development-eng.md) | Architecture, implementation, testing, security, performance, observability, and release of production Node.js services and workers |
+| `c` | [C development engineering](./ENG/c-development-eng.md) | Memory-safe-by-contract C libraries, services, native interfaces, security, testing, and reproducible toolchains |
+| `cpp` | [C++ development engineering](./ENG/cpp-development-eng.md) | Ownership, RAII, concurrency, ABI, native interoperability, testing, and reproducible C++ systems |
+| `java` | [Java development engineering](./ENG/java-development-eng.md) | JVM services, libraries, workers, build compatibility, concurrency, security, testing, and release |
+| `sql` | [SQL development engineering](./ENG/sql-development-eng.md) | Schemas, queries, migrations, transactions, database security, performance, and compatibility |
+| `go` | [Go development engineering](./ENG/go-development-eng.md) | Modules, services, workers, concurrency, cancellation, security, testing, and release |
+| `typescript` | [TypeScript development engineering](./ENG/typescript-development-eng.md) | Type-system/compiler contracts, runtime boundaries, module compatibility, testing, and release |
+| `php` | [PHP development engineering](./ENG/php-development-eng.md) | Composer applications, web services, workers, runtime constraints, security, testing, and deployment |
+| `swift` | [Swift development engineering](./ENG/swift-development-eng.md) | SwiftPM/Xcode applications, concurrency, platform boundaries, interoperability, testing, and release |
+| `rust` | [Rust development engineering](./ENG/rust-development-eng.md) | Architecture, implementation, testing, security, performance, reproducibility, and release of production Rust applications, services, libraries, and workers |
 
 ## Domain rules
 
@@ -205,6 +217,287 @@ rg -n '^## |accuracy|completeness|Diátaxis|tutorial|how-to|reference|explanatio
 
 **Expected evidence:** documentation purpose and audience are clear, factual claims are cross-checked against canonical project sources, changed documentation surfaces are complete, relevant examples/links/builds are validated when available, and unavailable required checks are recorded as `NOT_VERIFIED`.
 
+### `flutter` — Flutter application engineering
+
+**Activate when:** a confirmed project root has a structurally parsed `pubspec.yaml` with `dependencies.flutter.sdk: flutter`, and the task scope intersects that root. Once the root is confirmed, every claim under it matches, including lockfiles, localization/configuration files, source, tooling, and native platform configuration; confirmed nested project roots remain isolated. The guide then provides the Flutter-specific architecture, implementation, testing, performance, accessibility, platform integration, and release context.
+
+**Do not activate merely because:** prose, Markdown, a lockfile, a transitive package name, an arbitrary directory name, a hosted package named `flutter`, or an unrelated monorepo project mentions Flutter. `flutter_test` and platform/source signals are supporting evidence only; they cannot replace the primary SDK dependency signal.
+
+**Usually combine with:** `clean` and `test`; add `design`, `accessibility`, `security`, or `performance` when the affected surface or risk requires them.
+
+The route command obtains this evidence from `src/core/project-detection.js`. It walks bounded, non-symlinked project manifests, parses dependency structure, and matches task write claims against confirmed project roots. An unscoped route can inspect all detected projects; an explicit claim that does not reach a Flutter project produces `NO_FLUTTER_SCOPE_MATCH` and does not activate the guide. Documentation and UI-copy exclusions remain routing decisions, not project-detection heuristics.
+
+```bash
+rg -n '^## |architecture|testing|performance|accessibility|platform|release|Flutter' ENG/flutter-development-eng.md
+```
+
+**Expected evidence:** a confirmed affected Flutter project, a scoped route, platform-appropriate tests, measured performance or accessibility checks when relevant, and honest `NOT_VERIFIED` reporting for unavailable Flutter tooling.
+
+### `dotnet` — .NET and ASP.NET Core development engineering
+
+**Activate when:** a confirmed project root has a structurally parsed SDK-style `*.csproj`, `*.fsproj`, or `*.vbproj` using one of the supported SDKs below, and the task scope intersects that root:
+
+- `Microsoft.NET.Sdk`, `Microsoft.NET.Sdk.Web`, `Microsoft.NET.Sdk.Worker`,
+  `Microsoft.NET.Sdk.Razor`, or `Microsoft.NET.Sdk.BlazorWebAssembly`;
+- `Aspire.AppHost.Sdk` or `MSTest.Sdk`;
+- the equivalent `<Sdk Name="..." />` declaration in the project XML.
+
+Web, Razor, or Blazor SDKs, or `FrameworkReference Include="Microsoft.AspNetCore.App"`, confirm ASP.NET Core context. A `Volo.Abp.*` package reference adds the ABP overlay while retaining the single `dotnet` guide ID.
+
+**Do not activate merely because:** prose, Markdown, source snippets, a Dockerfile, a lockfile, an arbitrary directory name, a package cache, or an unrelated monorepo project mentions .NET, ASP.NET Core, or ABP. A malformed, oversized, non-SDK-style, or unsupported project file fails closed. Shared `Directory.Build.*`, `Directory.Packages.props`, `global.json`, and NuGet files apply only to descendant .NET projects in their directory scope; `.sln`/`.slnx` claims use exact solution membership.
+
+**Usually combine with:** `clean` and `test`; add `security` for trust-boundary or dependency changes, `performance` for measured cost or critical paths, `documentation` for technical documentation, and the UI guides for Razor/Blazor or other user-facing changes.
+
+The route command obtains this evidence from `src/core/project-detection.js`. It walks bounded, non-symlinked project manifests, parses direct XML SDK/target/reference structure without evaluating the full MSBuild graph, and matches task claims against project roots, shared configuration scope, or exact solution membership. ASP.NET Core and ABP are routing reasons on the specialist guide, not additional guide IDs.
+
+Project discovery is fail-closed and bounded by default: at most 256 project
+manifests, 64 solution files, 1 MiB per manifest, 256 supporting source files
+with 512 KiB per source file, 4,096 visited directories, and 20,000 visited
+entries. Symlinks and common generated/vendor directories are skipped. When a
+budget is exhausted, the detector does not claim reliable project evidence.
+These limits bound discovery work; they do not cap task ownership discovery.
+
+The .NET routing reasons are `PROJECT_DOTNET_SDK_PROJECT`,
+`PROJECT_DOTNET_BASELINE`, `PROJECT_ASPNETCORE_CONFIRMED`, and
+`PROJECT_ABP_CONFIRMED`. The corresponding exclusions are
+`NO_DOTNET_PROJECT_EVIDENCE`, `NO_DOTNET_SCOPE_MATCH`,
+`NO_DOTNET_PRIMARY_EVIDENCE`, and `NO_DOTNET_EXECUTABLE_WORK`. The route
+validator also requires `aspnetcore` and `abp` project-evidence overlays to be
+accompanied by `dotnet`; it rejects standalone overlays rather than creating a
+second specialist guide.
+
+```bash
+rg -n '^## |architecture|dependency injection|middleware|endpoints|configuration|authentication|authorization|EF Core|testing|WebApplicationFactory|workers|Blazor|ABP|publish|troubleshooting' ENG/dotnet-aspnetcore-development-eng.md
+```
+
+**Expected evidence:** a confirmed affected .NET project, a scoped route, compatible SDK/runtime decisions, focused and integration checks for changed boundaries, and honest `NOT_VERIFIED` reporting for unavailable .NET tooling or runtime environments.
+
+### `nodejs` — Node.js backend development engineering
+
+**Activate when:** a confirmed project root has a valid `package.json` with an
+allowlisted runtime backend dependency (`express`, `fastify`, `@nestjs/core`,
+`koa`, or `@hapi/hapi`), a direct `node`/`node.exe` runtime script, or bounded
+source evidence importing or re-exporting a Node server/network built-in such
+as `node:http`, `node:https`, `node:http2`, `node:net`, `node:tls`, or `node:dgram`
+from a plausible runtime application surface, and the task scope intersects
+that root.
+
+**Do not activate merely because:** a `package.json`, `engines.node`, `type`,
+`packageManager`, lockfile, `.nvmrc`, `.node-version`, `@types/node`,
+TypeScript, `tsx`, Dockerfile, CI setup, frontend dependency, Next-only
+dependency, prose mention, or development-only framework dependency exists.
+Malformed or oversized manifests fail closed. The detector never executes
+scripts or source code, follows symlinks, installs packages, or accesses the
+network.
+
+**Usually combine with:** `clean` and `test`; add `security` for input,
+authentication, authorization, dependency, secret, external-service, or
+publication risks; add `performance` for measured latency, throughput,
+memory, event-loop, queue, or database work; add `documentation` when the API,
+configuration, or operational contract changes.
+
+The route command obtains this evidence from
+`src/core/project-detection.js`. It walks bounded, non-symlinked manifests and
+source files, isolates nested project roots across Flutter, .NET, Node.js, and
+Rust,
+recognizes workspace-root and shared lockfile scope, and preserves
+`projectEvidence.schemaVersion: 1`. Node source evidence ignores comments,
+template text, `import type`/`export type`, inline type-only specifiers,
+declaration files, tooling/configuration filenames, and non-runtime directories
+such as tests, fixtures, examples, docs, build output, scripts, tools, codegen,
+and package caches. A mixed declaration counts only when a runtime value
+specifier is safely recognized; unsupported complex declarations fail closed.
+Runtime re-exports with a value specifier are included because the specialist
+covers Node.js server/runtime library surfaces as well as services and workers.
+Node.js execution used only for build, test, or configuration tooling is not
+sufficient backend/runtime evidence. Mixed Flutter/.NET/Node repositories
+retain each confirmed framework; claims and shared files stop at the same
+nested ownership boundaries. A claim that does not reach a confirmed Node
+project produces `NO_NODEJS_SCOPE_MATCH` or leaves the specialist excluded.
+
+```bash
+rg -n '^## |activation|runtime|architecture|Express|Fastify|NestJS|security|testing|performance|deployment|Definition of Done' ENG/nodejs-backend-development-eng.md
+```
+
+**Expected evidence:** a confirmed affected Node project, a scoped route,
+validated inputs and configuration, bounded trust and resource controls,
+focused plus integration/adversarial checks, observable failure and shutdown
+behavior, and honest `NOT_VERIFIED` reporting for unavailable Node tooling.
+
+### `c` — C development engineering
+
+Activate for explicit C language declarations in CMake or Meson, a native
+Bazel rule with owned .c source, or a direct claim to owned .c source. Headers,
+Makefiles, compiler images, flags, generated trees, and prose are not enough.
+C and C++ may compose at one root. Detection is bounded and static; it never
+runs native build tools, compilers, linkers, generators, or tests. Repository
+flags, compiler mode, ABI, C library, and platform contracts decide the
+effective C standard; C23 is only the current published reference.
+
+Expected evidence is a confirmed affected root, scoped ownership, explicit
+memory/resource contracts, failure-path tests, and separately recorded
+toolchain checks. See ENG/c-development-eng.md for the specialist contract.
+
+### `cpp` — C++ development engineering
+
+Activate for explicit C++ language declarations in CMake or Meson, a native
+Bazel rule with owned .cc, .cpp, .cxx, or .c++ source, or a direct claim to
+owned C++ source. Headers remain ambiguous without explicit build context.
+Makefiles, compiler versions, flags, generated trees, and vendored code do not
+establish C++ identity. The detector never executes native build logic.
+
+C++23 is the published baseline reference; compiler support for C++26 is not
+permission to change the repository standard or ABI. See
+ENG/cpp-development-eng.md for ownership, RAII, ABI, concurrency, and testing
+guidance.
+
+### `java` — Java development engineering
+
+Activate for owned Java source with structural Maven, Gradle, or Bazel
+evidence, an unambiguous Java compiler/platform declaration, or a direct .java
+claim. A POM, Gradle wrapper/settings, generic aggregator, JDK image, or
+setup-java CI step alone is not an application; explicit recognized Java
+plugins/rules are structural evidence, including `java-gradle-plugin`. Gradle
+topology uses only unconditional top-level literal includes; conditional,
+interpolated, or executable expressions remain unresolved. Unsafe XML
+DTD/entity constructs fail closed; Maven, Gradle, Bazel, plugins, annotation
+processors, tests, and Java code are never executed.
+
+Keep source level, release/target, build JDK, runtime JDK, preview features,
+framework minimums, and vendor distribution separate. Repository configuration
+wins over current JDK availability. See ENG/java-development-eng.md.
+
+### `sql` — SQL development engineering
+
+Activate as an overlay for a directly claimed meaningful SQL artifact or a
+bounded statement in an owned db, database, migration, migrations, schema, or
+sql directory. SQL composes with its host language specialist and dialect is
+not a public framework value. Comments, strings, prose, drivers, connection
+strings, empty files, generated/vendor content, and database images are not
+evidence.
+
+The detector masks lexical noise and never connects to a database, executes
+queries, applies migrations, reads credentials, or introspects schemas. Single-
+quoted string values are masked, while double-quoted, backtick-quoted, and
+bracket-quoted identifiers are preserved as internal neutral identifier tokens
+for structural matching. It recognizes bounded statement families only when
+structural tokens are present, and common CTE shapes, without claiming full
+dialect parsing; PostgreSQL JSON operators such as `#>` and `#>>` remain SQL
+tokens, not comments. ISO/IEC
+9075:2023 is a portability reference; the actual engine and version govern
+dialect behavior. See
+ENG/sql-development-eng.md.
+
+### `go` — Go development engineering
+
+Activate for a valid bounded go.mod module or a go.work connected to known
+repository-local modules. A go.work without a usable module, .go source alone,
+go.sum, vendor metadata, Docker image, or setup-go CI step is insufficient.
+The go minimum-version and toolchain directives remain distinct. Detection
+resolves only known manifests and never runs Go, downloads modules, evaluates
+build tags, or executes generators. `ignore` directives in `go.mod` are
+retained as module metadata (including single and block forms); they do not
+change project identity, and `go.work` does not accept them. See
+ENG/go-development-eng.md.
+
+### `typescript` — TypeScript development engineering
+
+Activate for a valid bounded JSONC tsconfig.json. A custom tsconfig.*.json is
+primary only when directly claimed or referenced by a confirmed config.
+jsconfig.json, .ts snippets, declaration files, compiler dependencies, and CI
+compiler setup are not TypeScript project identity. `extends` may be a string
+or array; local shared configs route claims to their consuming configs and do
+not become independent roots merely because they are named as bases. Local
+references are checked only against discovered configs; the compiler and
+config files are never executed.
+
+TypeScript is runtime-neutral, so a co-located Node package may select both
+typescript and nodejs. See ENG/typescript-development-eng.md.
+
+### `php` — PHP development engineering
+
+Activate for a valid bounded composer.json with package/require/autoload
+identity or a direct claim to executable PHP source. Composer lockfiles,
+vendor, PHP version strings, Docker/CI setup, static HTML, and README examples
+are not enough. Composer scripts/plugins, PHP, autoload generation, and
+network resolution are never run. PHP extension roots may compose with C.
+strict_types remains a per-file call-site rule. See ENG/php-development-eng.md.
+
+### `swift` — Swift development engineering
+
+Activate for a valid Package.swift tools-version/PackageDescription/Package
+structure with Swift target evidence, explicit Swift in CMake/Meson, bounded
+Xcode Swift markers, or a direct .swift claim. A direct Package.swift claim
+also selects Swift guidance for a native-only package manifest. Package.resolved,
+vendor/generated source, Docker/CI setup, and package execution are not
+evidence. Invalid Package.swift files contribute no SwiftPM-derived C/C++
+composition. SwiftPM may compose Swift with C or C++ at one root. Swift
+`mobile-ui` work remains executable Swift work. Swift 6.3 is the stable
+reference snapshot; beta documentation is not an automatic target.
+See ENG/swift-development-eng.md.
+
+### `rust` — Rust development engineering
+
+**Activate when:** a confirmed project root has a bounded, structurally parsed
+`Cargo.toml` with a valid `[package]` and/or `[workspace]` table, and the task
+scope intersects that root. A package workspace and a virtual workspace are
+both valid when the virtual workspace has at least one resolvable package
+member; an empty or unresolved virtual workspace fails closed. A virtual
+workspace contributes its confirmed package members as public project roots. A
+package workspace may contain both tables, but `package.workspace` is mutually
+exclusive with `[workspace]` and associates a package with another workspace.
+
+**Do not activate merely because:** a `.rs` file, `Cargo.lock`,
+`rust-toolchain`/`rust-toolchain.toml`, `.cargo/config.toml`, rustfmt or Clippy
+configuration, a Tokio/Axum/Actix/other dependency name, a Dockerfile, CI
+toolchain setup, or repository prose exists. `target/` and `vendor/` are
+ignored. Build scripts, proc-macro crates, generated code, and native tooling
+remain runtime/build context rather than a replacement for Cargo identity.
+
+Cargo inheritance such as `package.edition.workspace = true` and
+`package.rust-version.workspace = true` is accepted as package metadata;
+`[workspace.package]` may enrich supporting signals. Workspace membership uses
+only known discovered manifests and bounded `members`/`exclude` patterns: `*`
+and `?` stay within one path segment, `**` may cross segments, and absolute or
+parent-directory escape paths are rejected. Local package `path` dependencies
+and explicitly used inherited workspace dependencies can associate a known
+package with a workspace, while `[workspace.dependencies]` declarations alone
+do not create active dependency edges. A valid `package.workspace` association
+may point to a known workspace outside the package's directory subtree, but not
+outside the repository; no additional traversal is triggered.
+
+**Usually combine with:** `clean` and `test`; add `security` for unsafe/FFI,
+untrusted input, secrets, dependencies, external services, or publication;
+add `performance` for measured CPU, memory, latency, allocation, executor,
+queue, or I/O work; add `documentation` when public APIs, configuration, or
+operational contracts change.
+
+The route command obtains this evidence from
+`src/core/project-detection.js` and the conservative TOML recognizer in
+`src/core/rust-project.js`. It performs bounded, non-symlinked discovery and
+manifest reads, never runs Cargo or source code, and treats `Cargo.toml` as
+primary evidence while edition, MSRV, resolver, features, dependencies,
+lockfiles, toolchains, and configuration are supporting signals. Explicit
+workspace members/excludes, nested workspaces, and confirmed Flutter, .NET,
+Node.js, and Rust roots constrain claims and shared-file ownership. `Cargo.lock`
+and configuration files apply only to their owning package/workspace scope; a
+parent cannot absorb a child's shared file merely because its path is a
+descendant.
+
+Rust has no Node-style LTS channel. Keep active toolchain, MSRV
+(`package.rust-version`), edition, and compilation target separate, and use
+version-matched official Rust and Cargo documentation. Current stable is a
+dated observation, not a universal migration target.
+
+```bash
+rg -n '^## |Cargo|toolchain|MSRV|edition|ownership|async|unsafe|FFI|security|testing|release|Definition of Done' ENG/rust-development-eng.md
+```
+
+**Expected evidence:** a confirmed affected Cargo package or workspace, a
+scoped route, compatible toolchain/MSRV/edition/target decisions, focused plus
+workspace checks, explicit resource and trust controls, and honest
+`NOT_VERIFIED` reporting for unavailable Rust targets or toolchains.
+
 ## Work-type matrix
 
 | Work | Primary guide | Common complements | Exclude when |
@@ -214,6 +507,17 @@ rg -n '^## |accuracy|completeness|Diátaxis|tutorial|how-to|reference|explanatio
 | Code or bug without UI | `clean` | `test`; risk may add `security` or `performance` | The surface is unchanged |
 | Backend, API, or data | `clean` | `test`, `security`; `performance` for a critical path | That layer does not exist |
 | Web, mobile, or desktop UI | `design` | `accessibility`, `clean`, `test`; risk defines the rest | Users cannot observe the change |
+| Flutter application | `flutter` | `clean`, `test`; add `design`, `accessibility`, `security`, or `performance` as applicable | No primary Flutter SDK dependency in the affected project scope |
+| .NET / ASP.NET Core application | `dotnet` | `clean`, `test`; add `security`, `performance`, `documentation`, or UI guides as applicable | No supported SDK-style .NET project in the affected project scope |
+| Node.js backend, API, worker, or server runtime | `nodejs` | `clean`, `test`; add `security`, `performance`, or `documentation` as applicable | No primary Node.js backend/runtime evidence in the affected project scope |
+| Rust application, service, library, or worker | `rust` | `clean`, `test`; add `security`, `performance`, or `documentation` as applicable | No valid Cargo package/workspace in the affected project scope |
+| C or C++ native project | `c`, `cpp` | `clean`, `test`; add `security`, `performance`, or `documentation` as applicable | No explicit/owned native implementation evidence |
+| Java service, library, or worker | `java` | `clean`, `test`; add `security`, `performance`, or `documentation` as applicable | No structural Java build/source evidence |
+| Go module, service, or worker | `go` | `clean`, `test`; add `security`, `performance`, or `documentation` as applicable | No valid discovered Go module/workspace |
+| TypeScript project | `typescript` | `clean`, `test`; add `security`, `performance`, or `documentation` as applicable | No valid or referenced tsconfig project |
+| PHP application, package, or worker | `php` | `clean`, `test`; add `security`, `performance`, or `documentation` as applicable | No Composer or scoped executable PHP evidence |
+| Swift application, package, or service | `swift` | `clean`, `test`; add `security`, `performance`, or `documentation` as applicable | No SwiftPM/Xcode/build/source evidence |
+| SQL schema, query, or migration | `sql` | `clean`, `test`, `security`; add `performance` for measured query/migration risk | No meaningful owned SQL artifact |
 | Complete website | `premium` | `design`, `accessibility`, `clean`, `test`, `security`, `performance` | The deliverable is not a complete site |
 | Web game | `games` | `clean`, `test`, `security`, `performance`, `accessibility`; `design` with UI | The product is not a game |
 | HTML video or motion | `design` | `accessibility`, `performance`, `test`, `security` | There is no audiovisual composition |
@@ -226,7 +530,9 @@ HyperFrames is optional and may be used only when requested or already available
 The active agent may classify natural language, but it must pass declared
 signals to the deterministic evaluator in `src/core/router.js`. The evaluator
 does not parse natural language, call a model, or infer a stack from a word in
-the repository.
+the repository. `runRoute` may also pass `projectEvidence` from
+`src/core/project-detection.js`; that evidence is produced by structural
+manifest parsing and scope intersection, not by prose or model confidence.
 
 The first routing contract is versioned as `schemaVersion: 1`. It accepts:
 
@@ -243,19 +549,63 @@ The first routing contract is versioned as `schemaVersion: 1`. It accepts:
 - `platforms`: `web`, `mobile`, `desktop`, `server`, `ci`, or
   `cross-platform`;
 - optional boolean `behaviorChange` and `executableChange` signals.
+- optional `projectEvidence` with a schema version, a scope result, detected
+  framework IDs, affected project roots, primary signals, and supporting
+  signals. The current framework IDs are `flutter`, `dotnet`, `aspnetcore`,
+  `abp`, `nodejs`, `rust`, `c`, `cpp`, `java`, `sql`, `go`, `typescript`,
+  `php`, and `swift`. Flutter's primary signal is an affected
+  `dependencies.flutter.sdk: flutter` entry in `pubspec.yaml`. .NET's primary
+  signal is a supported SDK-style project manifest; ASP.NET Core and ABP are
+  structural overlays. Node.js primary signals are an allowlisted runtime
+  dependency, direct Node runtime script, or narrow server-builtin source
+  import in a valid `package.json` project. The C/C++, Java, Go, TypeScript,
+  PHP, and Swift specialists use bounded structural build/config or owned
+  source evidence; SQL is a bounded owned-file overlay. Rust's primary
+  signals are a valid structural `[package]` and/or `[workspace]` table in
+  `Cargo.toml`; Rust source, lockfiles, toolchain files, and dependencies
+  are supporting context.
 
 Rule precedence is deterministic: the work type establishes the primary
 closure; affected surfaces add mandatory complements; risks add security,
 performance, or accessibility; executable/behavior changes add clean and
 test; required rules win over optional exclusions; and the evaluator preserves
-canonical insertion order. Unknown or duplicate signals fail with a routing
-error.
+canonical insertion order. A matching Flutter project adds `flutter` plus the
+  `clean`/`test` baseline before ordinary work-type complements; documentation
+  and UI-copy work do not activate the specialist. A matching .NET project adds
+  `dotnet` plus the `clean`/`test` baseline and records ASP.NET Core/ABP reasons
+  on that guide. A matching Node.js project adds `nodejs` plus the `clean`/`test`
+  baseline and records `PROJECT_NODEJS_CONFIRMED`; dependency, direct-script,
+  and server-runtime reasons are optional enrichments when the corresponding
+  primary signals are present. A matching Rust project adds `rust` plus the
+  `clean`/`test` baseline and records `PROJECT_RUST_CONFIRMED`; package and
+  workspace roles are optional reason enrichments. The public `frameworks` field remains the
+  authority for the confirmed framework; the router does not reverse-engineer
+  Node selection from private signal substrings. Unknown or duplicate signals
+  fail with a routing error.
 
 Every selected guide has stable reason codes such as
 `WORK_COMPLETE_WEBSITE`, `SURFACE_UI`, `RISK_UNTRUSTED_INPUT`, and
 `CHANGE_EXECUTABLE_CONFIG`. Exclusions use stable codes such as
 `NO_TRUST_BOUNDARY`, `NO_MEASURABLE_PERFORMANCE_RISK`, and
-`NO_DOCUMENTATION_SURFACE`.
+  `NO_DOCUMENTATION_SURFACE`. Flutter uses
+  `PROJECT_FLUTTER_SDK_DEPENDENCY`, `PROJECT_FLUTTER_BASELINE`,
+  `NO_FLUTTER_PRIMARY_EVIDENCE`, `NO_FLUTTER_SCOPE_MATCH`, and
+  `NO_FLUTTER_EXECUTABLE_WORK`.
+  Node.js uses `PROJECT_NODEJS_CONFIRMED`,
+  `PROJECT_NODEJS_BACKEND_FRAMEWORK`,
+  `PROJECT_NODEJS_RUNTIME_SCRIPT`, `PROJECT_NODEJS_SERVER_RUNTIME`,
+  `PROJECT_NODEJS_BASELINE`, `NO_NODEJS_PRIMARY_EVIDENCE`,
+  `NO_NODEJS_SCOPE_MATCH`, and `NO_NODEJS_EXECUTABLE_WORK`. Rust uses
+  `PROJECT_RUST_CONFIRMED`, `PROJECT_RUST_CARGO_PACKAGE`,
+  `PROJECT_RUST_CARGO_WORKSPACE`, `PROJECT_RUST_BASELINE`,
+  `NO_RUST_PRIMARY_EVIDENCE`, `NO_RUST_SCOPE_MATCH`, and
+  `NO_RUST_EXECUTABLE_WORK`.
+
+The .NET specialist uses `PROJECT_DOTNET_SDK_PROJECT` and
+`PROJECT_DOTNET_BASELINE`; confirmed ASP.NET Core and ABP overlays add
+`PROJECT_ASPNETCORE_CONFIRMED` and `PROJECT_ABP_CONFIRMED`. Exclusions are
+`NO_DOTNET_PROJECT_EVIDENCE`, `NO_DOTNET_SCOPE_MATCH`,
+`NO_DOTNET_PRIMARY_EVIDENCE`, and `NO_DOTNET_EXECUTABLE_WORK`.
 
 Platform signals are contextual, not automatic guide activators:
 
@@ -280,6 +630,65 @@ Negative routing guarantees:
 - a backend refactor does not activate `design` or `accessibility`;
 - static UI copy does not activate `security` without a trust-boundary signal;
 - a package file alone does not prove that Node is an affected task surface;
+- a valid `package.json` without an allowlisted runtime dependency, direct Node
+  runtime script, or narrow server-builtin import from a plausible runtime
+  surface does not activate `nodejs`;
+- React/Vite, Next-only, engines-only, `@types/node`-only, devDependency-only,
+  lockfile-only, Docker-only, and CI-only evidence does not activate `nodejs`;
+- Node.js detection does not execute package scripts, import source, install
+  dependencies, follow symlinks, read unbounded files, or make network calls;
+- comments, template text, `import type`/`export type`, inline type-only
+  specifiers, declaration files, tooling/configuration files, and
+  test/fixture/example/documentation/build/script/tool/codegen/cache directories
+  do not create Node.js runtime evidence;
+- a `MATCH` or `UNSCOPED` public `projectEvidence` object whose frameworks
+  include `nodejs` selects the Node.js guide for executable work even when its
+  primary signal list is empty; signal details only enrich the reason list;
+- a workspace root may scope confirmed Node descendants, but a frontend or
+  unrelated nested package remains isolated, and nested project boundaries are
+  applied consistently to Flutter, .NET, Node source scans, claims, and shared
+  files;
+- documentation, UI-copy, and mobile-only work do not activate the Node.js
+  specialist even when the repository contains a confirmed Node package;
+- `flutter_test`, a Flutter word in documentation, or a lockfile package does
+  not replace the primary Flutter SDK dependency signal;
+- a .NET word in documentation, a `Dockerfile`, `project.assets.json`, a
+  package-lock file, or an arbitrary package name does not activate `dotnet`;
+- a standalone `aspnetcore` or `abp` project-evidence overlay is invalid;
+- a worker or library SDK selects the .NET specialist without claiming it is
+  an ASP.NET Core application; web/Razor/Blazor SDK or framework-reference
+  evidence is required for the ASP.NET Core reason;
+- a malformed, oversized, unsupported, or non-SDK-style project manifest does
+  not provide primary .NET evidence;
+- ABP guidance is not added for a plain ASP.NET Core project without a
+  structural `Volo.Abp.*` package reference;
+- a shared MSBuild/NuGet file does not activate unrelated projects outside its
+  directory scope, and a solution claim does not activate non-members;
+- a `.rs` file, `Cargo.lock`, Rust toolchain/configuration file, or Rust
+  dependency name does not replace a valid Cargo package/workspace manifest;
+- a C/C++ header, Makefile, compiler image, or generic native build file does
+  not replace explicit language or owned implementation evidence;
+- a Java POM/Gradle wrapper, Go source or go.sum, jsconfig, Composer lockfile,
+  Package.resolved, or generic build metadata alone does not establish the
+  corresponding specialist;
+- SQL is selected only from a meaningful claimed or owned migration/schema
+  artifact and overlays the host project; comments, strings, and credentials
+  are never evidence;
+- build/package/compiler tools are never executed during project detection,
+  and all eight language specialists preserve bounded reads, traversal, and
+  same-root composition;
+- a virtual workspace root is not exposed as a public package root, excluded
+  workspace members remain out of an explicit workspace claim, and nested
+  Cargo workspaces remain ownership boundaries;
+- Rust shared files (`Cargo.lock`, toolchain, `.cargo/config*`, rustfmt, and
+  Clippy configuration) apply only to their owning package/workspace scope;
+- a `MATCH` or `UNSCOPED` public `projectEvidence` object whose frameworks
+  include `rust` selects the Rust guide for executable work even when its
+  primary signal list is empty; public framework identity is authoritative;
+- documentation and UI-copy work do not activate the Rust specialist even
+  when the repository contains a confirmed Cargo project;
+- an unrelated monorepo project does not activate Flutter when task claims do
+  not intersect its confirmed project root; nested project roots remain isolated;
 - an explicit executable-change signal adds `clean` and `test` even when the
   semantic work type is documentation.
 
@@ -323,6 +732,48 @@ Verify the game loop, authoritative server, reconciliation, input, assets, fallb
 
 Verify Markdown, links, paths, commands, and examples.
 
+### Flutter application feature
+
+<!-- route:flutter-app-feature=flutter,clean,test -->
+
+Verify the affected `pubspec.yaml` contains the Flutter SDK dependency, confirm
+the task claim reaches that project, and cover widget/state behavior, platform
+integration, accessibility, performance, and release checks according to the
+changed surface. Supporting signals alone must leave `flutter` excluded.
+
+### .NET / ASP.NET Core application feature
+
+<!-- route:dotnet-app-feature=dotnet,clean,test -->
+
+Verify the affected project uses a supported SDK-style .NET manifest, confirm
+the claim scope or exact solution membership, and cover DI lifetimes, pipeline
+ordering, endpoint contracts, validation, authorization, cancellation, data
+access, observability, and integration behavior according to the changed
+surface. A worker/library project remains on the same specialist guide but
+does not receive an ASP.NET Core claim without structural web evidence.
+
+### Node.js backend feature
+
+<!-- route:nodejs-backend-feature=nodejs,clean,test -->
+
+Verify the affected package has primary Node.js evidence, confirm the claim
+reaches the correct package root or workspace descendant, and cover runtime and
+module-system compatibility, input/configuration validation, authentication and
+authorization, middleware order, timeouts/cancellation, persistence and
+external-service boundaries, observability, shutdown, and adversarial tests.
+Supporting package metadata and lockfiles alone must leave `nodejs` excluded.
+
+### Rust application feature
+
+<!-- route:rust-app-feature=rust,clean,test -->
+
+Verify the affected `Cargo.toml` contains a valid `[package]` or `[workspace]`
+table, confirm the claim reaches the correct package/workspace scope, and
+cover toolchain/MSRV/edition/target compatibility, ownership and cancellation,
+resource limits, unsafe/FFI/dependency boundaries, focused tests, and the
+workspace checks required by the repository. Cargo metadata and Rust tooling
+files alone must leave `rust` excluded.
+
 ## Route changes
 
 If investigation reveals a new surface, update the guide set before editing that area. Record only the concise reason; do not create a versioned task log.

package/LOOP_SYSTEM_DESIGN.md

@@ -242,7 +242,7 @@ presented as a completed protocol state.
 
 ### `ENG/*.md`
 
-Nine canonical guides cover:
+Eleven canonical guides cover:
 
 - clean code;
 - testing;
@@ -252,7 +252,9 @@ Nine canonical guides cover:
 - accessibility;
 - premium website production;
 - web games;
-- contextual frontend taste.
+- contextual frontend taste;
+- technical documentation quality;
+- Flutter application engineering.
 
 Each guide has exact English frontmatter and a stable guide ID.
 
@@ -265,6 +267,7 @@ Records external provenance, trademarks, licenses, and reuse boundaries. It is r
 | Work type | Guide set |
 | --- | --- |
 | Documentation | Related domain and documentation checks |
+| Flutter application | `flutter` with `clean` and `test`; add surface-specific guides as needed |
 | General code or bug fix | `clean`, `test`; add `security` or `performance` when the surface requires it |
 | Backend, API, authentication, or data | `clean`, `test`, `security`; add `performance` for critical paths |
 | Web, mobile, or desktop interface | `clean`, `test`, `design`, `accessibility`; add `security` and `performance` according to product risk |
@@ -418,7 +421,7 @@ The documentation workflow verifies:
 
 - every file referenced by an adapter exists;
 - repository-relative links resolve;
-- exactly nine canonical English guides exist;
+- exactly eleven canonical English guides exist;
 - guide IDs, filenames, frontmatter keys, and `language: en` match the catalog;
 - no legacy language tree or bilingual metadata remains;
 - all route contracts contain valid guide IDs;
@@ -428,14 +431,15 @@ The documentation workflow verifies:
 - secrets and credential-like assignments are absent;
 - `THIRD_PARTY_NOTICES.md` is present.
 
-The validator also exercises six routing scenarios:
+The validator also exercises seven routing scenarios:
 
 1. premium landing page;
 2. authenticated API;
 3. bug fix without UI;
 4. mobile app with UI;
 5. multiplayer web game;
-6. documentation-only change.
+6. documentation-only change;
+7. Flutter application feature with a primary SDK dependency signal.
 
 ## Distribution
 
@@ -527,7 +531,7 @@ is orthogonal to lifecycle phases and does not authorize the receiving harness.
 - The repository and its maintained content are English-only.
 - Common project instruction surfaces and generic bootstrap mechanisms have a
   documented entry into one canonical loop.
-- The router selects every relevant guide and excludes irrelevant guides in the six defined scenarios.
+- The router selects every relevant guide and excludes irrelevant guides in the seven defined scenarios.
 - The profile contains verifiable facts, sources, and real commands without secrets.
 - The loop requires evidence before completion claims and exits safely when blocked.
 - Structural, Markdown, link, and secret checks pass locally and in CI.

package/QUALITY_SCORECARD.md

@@ -94,6 +94,8 @@ are both present:
 | Dimension | Implementation evidence | Executable evidence |
 | --- | --- | --- |
 | Routing | `src/core/router.js`, route schemas, stable reason codes, and exclusions | `tests/router.test.js`, `tests/fixtures/routes/` |
+| Flutter project detection and routing | `src/core/project-detection.js`, `src/core/router.js`, `src/config/guides.json`, and scoped manifest evidence | `tests/project-detection.test.js`, `tests/guide-registry.test.js`, `tests/router.test.js` |
+| Rust project detection and routing | `src/core/project-detection.js`, `src/core/rust-project.js`, `src/core/router.js`, `src/config/guides.json`, and scoped Cargo evidence | `tests/rust-project-detection.test.js`, `tests/guide-registry.test.js`, `tests/router.test.js` |
 | Observability | `src/core/receipt.js`, `src/core/inspect.js`, `src/core/evidence.js`, and schema health | `tests/observability.test.js`, `tests/receipt-semantics.test.js`, `tests/schema-health.test.js` |
 | Resume/checkpoint | `src/core/work-state.js`, `EXECUTION_STATE.md`, shared loaded-state classifier, contract/artifact classifiers, and atomic writes | `tests/work-state.test.js`, `tests/checkpoint-freshness.test.js`, status, validate-state, and validate-protocol tests |
 | Delegation | `src/core/delegation.js`, delegation-set validator, and `DELEGATION_PROTOCOL.md` | `tests/delegation.test.js`, `tests/delegation-set.test.js` |