@cassiomc1/forgeloop 1.12.0 → 1.14.0

package/GUIDE_ROUTER.md

@@ -53,6 +53,17 @@ project commands.
 | `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
 
@@ -222,6 +233,271 @@ rg -n '^## |architecture|testing|performance|accessibility|platform|release|Flut
 
 **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 |
@@ -232,6 +508,16 @@ rg -n '^## |architecture|testing|performance|accessibility|platform|release|Flut
 | 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 |
@@ -265,26 +551,61 @@ The first routing contract is versioned as `schemaVersion: 1`. It accepts:
 - 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 ID is `flutter`; its primary signal is an
-  affected `dependencies.flutter.sdk: flutter` entry in `pubspec.yaml`.
+  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. 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. Unknown or duplicate signals
-fail with a routing error.
+  `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`. Flutter uses
-`PROJECT_FLUTTER_SDK_DEPENDENCY`, `PROJECT_FLUTTER_BASELINE`,
-`NO_FLUTTER_PRIMARY_EVIDENCE`, `NO_FLUTTER_SCOPE_MATCH`, and
-`NO_FLUTTER_EXECUTABLE_WORK`.
+  `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:
 
@@ -309,8 +630,63 @@ 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
@@ -365,6 +741,39 @@ 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_ENGINEERING.md

@@ -541,6 +541,21 @@ forgeloop preflight
 
 `preflight` validates local ForgeLoop artifacts only. It does not invoke the model, run project commands, or treat a prose declaration as evidence. A `READY` result is required before `EXECUTING` in standard and strict workflows. A non-empty `current-contract.unresolvedDecisions[]` causes `forgeloop preflight` to return `BLOCKED` with `E_CONTRACT_UNRESOLVED_DECISION`; a valid `current-contract.assumptions[]` list does not block preparation.
 
+Required gates are recorded only through `forgeloop gate-record`. The command
+accepts only gates required by the active route or policy, computes artifact
+hashes itself, rejects traversal and symlink escapes, and permits mutation only
+in `ROUTED`, `DESIGNING`, or `PLANNED`. It rejects gate writes after execution
+starts. A satisfied gate requires a meaningful decision and no unknowns.
+Caller-provided evidence remains descriptive local input and cannot assert
+`HOST_ATTESTED`, `FORGELOOP_EXECUTED`, or remote attestation.
+
+Built-in contract preset references are limited to the canonical
+`contract-preset:documentation`, `contract-preset:bug`,
+`contract-preset:feature`, and `contract-preset:release` values. These values
+do not require `.forgeloop/sources.json`; mixed contracts still validate every
+non-built-in reference against the source registry, and unknown preset names
+are rejected.
+
 ### Resumable activation and artifact reconciliation
 
 `PREFLIGHT_READY` is a durable checkpoint, not only a status value. A persisted
@@ -864,6 +879,15 @@ proportional phases, but:
 - `REVIEWING` cannot claim independent review when reviewer and implementer
   identities are equal.
 
+Immediately after `task-create`, a task may have a valid descriptor and
+hash-linked `TASK_RECEIVED`/transaction history without `work-state.json`.
+ForgeLoop derives `RECEIVED` from that canonical early artifact set. `next`
+returns `DISCOVER`, and `discover` appends the initial discovery milestone
+without creating synthetic work state. `next` then returns `CREATE_CONTRACT`;
+`contract-create` persists and validates the real contract and materializes the
+first work-state checkpoint with its actual contract fingerprint. Invalid,
+contradictory, or unexpected early history remains inconsistent.
+
 Resume rules are conservative: revalidate branch, HEAD, contract fingerprint,
 protocol version, and required artifacts before continuing; never rerun a
 completed destructive or publication action automatically; rerun cheap
@@ -989,8 +1013,10 @@ tooling, the agent must verify the capability boundary before using it:
 3. Reuse an existing callable capability when it is sufficient for the task.
 4. If the required capability is missing and a keyless Qwen path exists,
    install only the smallest matching capability, normally
-   `qwen-mm-plugins-core` for multimodal reading. Use the active harness's
-   native installation mechanism or the official
+   `qwen-mm-plugins-core` for multimodal reading, when the host or operator has
+   explicitly granted task-scoped installation authority. Without that
+   authority, keep the capability unavailable and report the limitation. Use
+   the active harness's native installation mechanism or the official
    [Qwen-MM-Plugins](https://github.com/QwenLM/Qwen-MM-Plugins) instructions.
 5. If the operation is API-backed, check the required environment variable or
    configured service endpoint before enabling it. Without that prerequisite,

package/ORCHESTRATOR_INTEGRATION.md

@@ -183,7 +183,8 @@ Attestation Chain](./docs/CODE_ATTESTATION.md#completion-flow).
 
 ## Serializable interfaces
 
-The following JSON Schemas define the boundaries a host may implement:
+The following core lifecycle JSON Schemas define boundaries a host may implement;
+the complete current inventory is generated in `docs/ARTIFACT_REFERENCE.md`:
 
 - `schemas/routing-input.schema.json` and
   `schemas/routing-result.schema.json` define deterministic guide selection
@@ -203,6 +204,9 @@ The following JSON Schemas define the boundaries a host may implement:
   `schemas/config.schema.json`, `schemas/policy.schema.json`, and
   `schemas/task-bundle.schema.json` define chronology, mode, policy, and
   handoff boundaries.
+- `schemas/semantic-decision.schema.json`, `schemas/context-plan.schema.json`,
+  and `schemas/test-utility.schema.json` define bounded semantic inputs and
+  test-intelligence projections without lifecycle or evidence authority.
 
 `src/core/conformance.js` validates relationships that individual schemas
 cannot express: route/state protocol versions, route/state guide sets,
@@ -224,10 +228,10 @@ tool objects, credentials, hidden prompts, or remote database references.
 ## Host responsibilities
 
 The compatible harness owns model execution, tool execution, scheduling,
-parallelism, lifecycle, isolation, and any remote services. It must pass
-validated inputs to the protocol, preserve file ownership, report unavailable
-capabilities, and never turn local success into an unverified publication
-claim.
+parallelism, verification isolation, and any remote services. It must invoke
+lifecycle transitions through ForgeLoop, pass validated inputs, preserve file
+ownership, report unavailable capabilities, and never turn local success into an
+unverified publication claim.
 
 ## No-runtime boundary