@cassiomc1/forgeloop 1.14.0 → 2.0.0-rc.2

package/CONTRIBUTING.md

@@ -12,8 +12,8 @@ aggregates coverage without rerunning tests. `npm run test:watch` provides
 local watch mode. Run `npm run mcp:setup` explicitly when MCP checks are in
 scope. Keep CLI metadata, generated
 references, schemas, completions, summaries, and conformance scenarios
-aligned. Do not add vendor-specific runtime behavior: ForgeLoop remains a
-file-backed protocol and support CLI.
+aligned. Do not add vendor-specific runtime behavior: ForgeLoop uses canonical
+SQLite operational storage and explicit file interchange.
 
 The ordinary PR workflow is intentionally path-aware. `pr-core.yml` always
 publishes the ruleset contexts `audit`, `CodeQL`, `Verify generated Archify
@@ -23,6 +23,11 @@ or is skipped unexpectedly. Broader main-branch and release workflows provide
 the explicit cross-platform, package, Windows, documentation, and audit
 coverage that is not duplicated on every pull request.
 
+Node test jobs use local macOS and remote native Windows/Linux Docker runners.
+See [self-hosted validation](./docs/SELF_HOSTED_TESTS.md) for admission, runtime,
+service and evidence boundaries. Required check names remain stable, including
+the historical `tarball smoke (ubuntu-latest)` context.
+
 ## Protocol changes
 
 Any persisted artifact or lifecycle change must preserve the published schema
@@ -83,8 +88,7 @@ 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.
 
-Transaction payload maintenance is opt-in:
-`npm run transactions:compact -- --path /path/to/project --retain-days 7`
-previews the operation; add `--apply` to compact eligible payloads. Manifests,
-ledgers, recent transactions, and ambiguous outcomes remain intact. See the
-[Astra implementation record](docs/ASTRA_IMPLEMENTATION.md) for boundaries.
+Filesystem transaction-payload maintenance is retired with the SQLite
+migration. Preserve legacy evidence for explicit migration and diagnosis. See
+the [Astra implementation record](docs/ASTRA_IMPLEMENTATION.md) for historical
+boundaries.

package/DOCS_INDEX.md

@@ -61,6 +61,7 @@ integration and guide context. Use this map before editing documentation.
 | Documentation history | [`docs/history/README.md`](./docs/history/README.md) | Archived audits, release evidence, and completed validation records with current-owner links |
 | Documentation guide | [`docs/DOCUMENTATION_GUIDE.md`](./docs/DOCUMENTATION_GUIDE.md) | Rules and checklist for modifying documentation |
 | Current release checklist | [`docs/RELEASE_CHECKLIST.md`](./docs/RELEASE_CHECKLIST.md) | Package, protocol, attestation, integration, and publication gates |
+| Self-hosted Node tests | [`docs/SELF_HOSTED_TESTS.md`](./docs/SELF_HOSTED_TESTS.md) | Local macOS, remote Windows/Linux Docker runners, event admission and verification boundaries |
 | Core npm package contents | [`docs/PACKAGE_CONTENTS.md`](./docs/PACKAGE_CONTENTS.md) | Published consumer surface, intentional inclusions, exclusions, and clean-room verification |
 | ForgeLoop 1.6.1 release checklist (historical) | [`docs/RELEASE_CHECKLIST_1_6_1.md`](./docs/RELEASE_CHECKLIST_1_6_1.md) | Verification adapter boundary, isolation invariants, and publication gates |
 | ForgeLoop 1.5/MCP release checklist (historical) | [`docs/RELEASE_CHECKLIST_1_5_MCP.md`](./docs/RELEASE_CHECKLIST_1_5_MCP.md) | Integration API v1, MCP package, and publication gates |
@@ -73,7 +74,7 @@ integration and guide context. Use this map before editing documentation.
 | Architecture and safety boundaries | [`LOOP_SYSTEM_DESIGN.md`](./LOOP_SYSTEM_DESIGN.md) and [`THREAT_MODEL.md`](./THREAT_MODEL.md) | Design rationale and residual risk |
 | Artifact and phase schemas | [`schemas/`](./schemas/) and [`CONTRACT_COVERAGE.md`](./CONTRACT_COVERAGE.md) | Versioned machine-readable contract |
 | CLI/package behavior | [`src/`](./src/) and [`tests/`](./tests/) | Executable implementation and regression evidence |
-| Guide content | [`ENG/`](./ENG/) | Context-specific, English-only operational guides, including Flutter, .NET, Node.js, Rust, C, C++, Java, SQL, Go, TypeScript, PHP, and Swift specialists; ASP.NET Core and ABP remain .NET overlays |
+| Guide content | [`ENG/`](./ENG/) | Context-specific, English-only operational guides, including Flutter, .NET, Node.js, Rust, C, C++, Java, SQL, Go, TypeScript, PHP, Swift, and Python specialist guides; Python is documentation-only and is not yet selected automatically by the router; ASP.NET Core and ABP remain .NET overlays |
 | Diagram governance | [`docs/diagrams/manifest.json`](./docs/diagrams/manifest.json) | Authoritative taxonomy, renderer mapping, canonical purposes, artifact ownership, and references |
 | Diagram maintainer entrypoint | [`docs/diagrams/README.md`](./docs/diagrams/README.md) | Typed Archify source, animated HTML explorer, animated SVG fallback, review, and regeneration workflow |
 | Engineering flow diagram | [`docs/assets/diagrams/forgeloop-engineering-flow.html`](./docs/assets/diagrams/forgeloop-engineering-flow.html) | Conceptual lifecycle from request through validator-backed completion |

package/ENG/c-development-eng.md

@@ -3,7 +3,7 @@ name: c-development-eng
 language: en
 description: "Specialist guidance for production C libraries, services, embedded components, and native build systems."
 version: "2026.09"
-last-reviewed: "2026-09-12"
+last-reviewed: "2026-10-13"
 guide-id: c
 requires-gates:
   - threat-boundary
@@ -31,7 +31,7 @@ Repository architecture, supported platforms, compiler configuration, ABI,
 warning policy, and minimum supported toolchain win over generic advice. Use
 the matching repository standard and toolchain first, then the ISO/WG14
 material and version-matched platform documentation. C23 (ISO/IEC 9899:2024)
-is the current published reference in the 2026-09 plan snapshot; C2y remains
+is the current published C language standard; C2y remains
 development work and is not an automatic migration target.
 
 ## Project and standard discovery

package/ENG/cpp-development-eng.md

@@ -3,7 +3,7 @@ name: cpp-development-eng
 language: en
 description: "Specialist guidance for production C++ libraries, services, tools, and native build systems."
 version: "2026.09"
-last-reviewed: "2026-09-12"
+last-reviewed: "2026-10-13"
 guide-id: cpp
 requires-gates:
   - threat-boundary
@@ -32,7 +32,7 @@ Repository architecture, standard mode, ABI, supported compilers, target
 platforms, and public compatibility policy win over generic best practice.
 Use WG21, the actual compiler documentation, and version-matched platform
 documentation after repository evidence. C++23 (ISO/IEC 14882:2024) is the
-published reference in the 2026-09 plan snapshot. C++26 compiler support is
+published reference as of 2026-10-13. C++26 compiler support is
 not permission to migrate a C++17/20/23 repository.
 
 ## Project and standard discovery

package/ENG/dotnet-aspnetcore-development-eng.md

@@ -3,7 +3,7 @@ name: dotnet-aspnetcore-development-eng
 language: en
 description: "Specialist guide for architecture, implementation, testing, performance, security, data access, hosting, observability, and release of production .NET and ASP.NET Core applications."
 version: "2026.09"
-last-reviewed: "2026-09-11"
+last-reviewed: "2026-10-13"
 guide-id: dotnet
 ---
 
@@ -75,6 +75,10 @@ Use structural project evidence for routing, but use source and configuration in
 
 ## 4. Version-sensitive decisions
 
+As of 2026-10-13, .NET 10 is the current LTS line; its latest patch is 10.0.12.
+.NET 9 is in maintenance and reaches end of support on 2026-11-10. These are
+dated references only: use the repository's pinned SDK and target framework.
+
 Treat these as version-sensitive:
 
 - `global.json`, SDK selection, target frameworks, trimming, Native AOT, single-file publish, and roll-forward;
@@ -388,6 +392,8 @@ The router must not activate this guide from prose, source snippets, `Dockerfile
 
 Official references for version-sensitive work:
 
+- [.NET support policy](https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core)
+
 - [ASP.NET Core best practices](https://learn.microsoft.com/aspnet/core/fundamentals/best-practices)
 - [.NET SDK overview](https://learn.microsoft.com/dotnet/core/sdk)
 - [`global.json` overview](https://learn.microsoft.com/dotnet/core/tools/global-json)

package/ENG/flutter-development-eng.md

@@ -3,14 +3,14 @@ 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-09-09"
+last-reviewed: "2026-10-13"
 guide-id: flutter
 ---
 # Flutter Development Engineering Guide
 
 > Production-oriented Flutter specialist guidance for ForgeLoop-enabled AI coding agents and developers.
 >
-> This guide is an operational synthesis of the official Flutter documentation at `https://docs.flutter.dev/`, reviewed against the documentation baseline current on 2026-09-09. The Flutter documentation reviewed for this guide generally reports Flutter 3.47.2. Version-sensitive behavior MUST be verified against the project's pinned SDK and the current official documentation before changing code.
+> This guide is an operational synthesis of the official Flutter documentation at `https://docs.flutter.dev/`, reviewed on 2026-10-13. The current stable release line is Flutter 3.47. Version-sensitive behavior MUST be verified against the project's pinned SDK and the current official documentation before changing code.
 >
 > This guide complements, rather than replaces, ForgeLoop's general engineering guides. For code structure and maintainability use `clean-code-eng.md`; for verification strategy use `test-code-eng.md`; for threat modeling and trust boundaries use `sec-code-eng.md`; for measured optimization use `perf-code-eng.md`; for visual design use `design-code-eng.md`; and for inclusive interfaces use `accessibility-eng.md`.
 >
@@ -1991,6 +1991,8 @@ Do not add identifiers to ForgeLoop protocol schemas without updating validators
 
 ## 56. Official documentation map
 
+- [Flutter SDK archive](https://docs.flutter.dev/install/archive)
+
 Primary official Flutter documentation areas used to synthesize this guide:
 
 - Flutter documentation home  

package/ENG/go-development-eng.md

@@ -3,7 +3,7 @@ name: go-development-eng
 language: en
 description: "Specialist guidance for production Go services, workers, CLIs, modules, and concurrent systems."
 version: "2026.09"
-last-reviewed: "2026-09-12"
+last-reviewed: "2026-10-13"
 guide-id: go
 requires-gates:
   - threat-boundary
@@ -31,7 +31,7 @@ Repository module boundaries, supported Go versions, build tags, target
 matrix, compatibility policy, and release process win over generic advice.
 Use the matching Go specification, standard-library documentation, module and
 workspace documentation, and official Go security guidance after repository
-evidence. The 2026-09 plan snapshot uses Go 1.27/1.27.1 as a current reference;
+evidence. Go 1.27.2 is the current stable reference as of 2026-10-13;
 that is not permission to upgrade a repository.
 
 Keep the `go` language minimum directive distinct from `toolchain`, the build

package/ENG/java-development-eng.md

@@ -3,7 +3,7 @@ name: java-development-eng
 language: en
 description: "Specialist guidance for production Java services, libraries, workers, and JVM build systems."
 version: "2026.09"
-last-reviewed: "2026-09-12"
+last-reviewed: "2026-10-13"
 guide-id: java
 requires-gates:
   - threat-boundary
@@ -40,8 +40,8 @@ boundaries remain isolated.
 Repository architecture, toolchain/build configuration, source/target policy,
 ABI, and supported runtime win over generic advice. Then use the matching Java
 Language Specification/API, official Maven/Gradle/Bazel documentation, and
-version-matched framework documentation. The 2026-09 plan snapshot identifies
-JDK 26 as the current Java SE release and JDK 25 as the latest Oracle LTS;
+version-matched framework documentation. JDK 27 is the current Java SE release
+and JDK 25 is the latest Oracle LTS as of 2026-10-13;
 neither is an automatic migration target.
 
 Keep separate the JDK running the build tool, Java source level, `--release`,

package/ENG/nodejs-backend-development-eng.md

@@ -3,7 +3,7 @@ name: nodejs-backend-development-eng
 language: en
 description: "Specialist guidance for architecture, implementation, testing, security, performance, observability, and release of production Node.js backend services and workers."
 version: "2026.09"
-last-reviewed: "2026-09-11"
+last-reviewed: "2026-10-13"
 guide-id: nodejs
 requires-gates:
   - threat-boundary
@@ -148,6 +148,10 @@ descendants; unrelated frontend packages remain isolated.
 
 ## 3. Runtime and module-system decisions
 
+As of 2026-10-13, Node.js 26 is Current and Node.js 24 is the latest LTS
+release. Production deployments should use an Active or Maintenance LTS line;
+check the official release schedule again when selecting a runtime.
+
 Record the actual runtime range before changing APIs:
 
 - inspect `engines.node`, version files, CI matrices, container images, and
@@ -589,9 +593,9 @@ Useful primary references include:
 - [Node.js documentation](https://nodejs.org/docs/latest/api/)
 - [Node.js LLM documentation index](https://nodejs.org/docs/latest-v26.x/llms.txt)
 - [Node.js release policy](https://nodejs.org/en/about/previous-releases)
-- [Node.js HTTP](https://nodejs.org/api/http.html), [HTTP/2](https://nodejs.org/api/http2.html),
-  [net](https://nodejs.org/api/net.html), and [TLS](https://nodejs.org/api/tls.html)
-- [Node.js package exports](https://nodejs.org/api/packages.html)
+- [Node.js HTTP](https://nodejs.org/docs/latest-v24.x/api/http.html), [HTTP/2](https://nodejs.org/docs/latest-v24.x/api/http2.html),
+  [net](https://nodejs.org/docs/latest-v24.x/api/net.html), and [TLS](https://nodejs.org/docs/latest-v24.x/api/tls.html)
+- [Node.js package exports](https://nodejs.org/docs/latest-v24.x/api/packages.html)
 - [Express](https://expressjs.com/), [Fastify](https://fastify.dev/docs/latest/),
   [NestJS](https://docs.nestjs.com/), [Koa](https://koajs.com/), and
   [hapi](https://hapi.dev/)

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-09-12"
+last-reviewed: "2026-10-13"
 guide-id: php
 requires-gates:
   - threat-boundary
@@ -32,8 +32,8 @@ package resolution, or project code, and it does not access the network.
 Repository PHP/Composer constraints, runtime platform, extensions, deployment
 model, and compatibility policy win over generic advice. Then use the matching
 official PHP manual/migration guide, Composer documentation, and
-version-matched framework documentation. The 2026-09 plan snapshot records PHP
-8.5.10 as a current reference and supported branches 8.2–8.5; neither changes
+version-matched framework documentation. As of 2026-10-13, PHP 8.5.10 is the
+current patch reference and supported branches are 8.2–8.5; neither changes
 the repository runtime constraint automatically.
 
 Keep PHP language version, engine/runtime, extensions, Composer platform

package/ENG/python-development-eng.md

@@ -0,0 +1,205 @@
+---
+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"
+guide-id: python
+requires-gates:
+  - threat-boundary
+completion-evidence:
+  - python-validation
+---
+
+# Python Development Engineering Guide
+
+## Mission and activation
+
+Use this guide for Python applications, libraries, command-line tools, build
+and automation scripts, data pipelines, and CPython extensions. Confirm the
+actual project from owned `.py` files and its packaging/build metadata, such as
+`pyproject.toml`, `setup.cfg`, `setup.py`, or a declared requirements file.
+Do not infer Python project identity from documentation, editor settings,
+Jupyter output, a Python executable used only by CI, or a transitive package.
+
+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,
+unpacking in comprehensions, and explicit lazy imports. Treat each feature as
+version-gated: verify its exact semantics and availability in the project's
+target version before using it. The project interpreter and support policy
+always take precedence over the newest release.
+
+## Authority and version boundaries
+
+Resolve conflicts in this order:
+
+1. Platform and safety requirements.
+2. The user's explicit request.
+3. Repository instructions, supported interpreter range, dependency lock,
+   packaging metadata, tests, and deployment configuration.
+4. This guide.
+5. The version-matched official Python documentation and PEPs.
+6. Framework, packaging-tool, and community examples.
+
+Keep separate the CPython or alternative implementation version, Python
+language compatibility, minimum supported version, build interpreter,
+runtime interpreter, ABI (including free-threaded builds), platform, and
+dependency resolver. `requires-python`, classifiers, tox/nox matrices, CI,
+containers, and deployment manifests may express different constraints;
+reconcile them rather than choosing one by recency. Python 3.15.0 is a
+reference point, not an automatic upgrade target.
+
+## Project discovery and packaging
+
+Inspect the narrowest complete project boundary:
+
+- `pyproject.toml`, including `[build-system]`, `[project]`, tool-specific
+  tables, and workspace configuration;
+- `requires-python`, build backend, package discovery, entry points, optional
+  dependencies, extras, and dynamic metadata;
+- lockfiles and the exact tool that owns each one (`uv.lock`, Poetry, PDM,
+  Pipenv, or another declared workflow);
+- `src/`, package modules, `__init__.py`, namespace-package layout, scripts,
+  tests, fixtures, generated code, and vendored files;
+- `tox.ini`, `noxfile.py`, `pytest.ini`, `setup.cfg`, `setup.py`, and
+  requirements files when present;
+- CI interpreter matrices, container images, deployment commands, native
+  libraries, and platform-specific build steps.
+
+Do not execute package build hooks, project imports, setup scripts, arbitrary
+`pyproject.toml` backends, or test collection during static discovery. Do not
+install tools or dependencies merely to answer a routing or documentation
+question. Preserve the repository's package manager and lockfile strategy.
+Avoid adding a second environment manager or migrating packaging metadata as
+incidental cleanup.
+
+## Python semantics and API design
+
+Prefer explicit, unsurprising behavior over clever metaprogramming. Keep
+mutable defaults out of function signatures; use immutable values or create
+fresh state inside the function. Distinguish identity from equality, shallow
+from deep copying, and iteration from materialization. Make generators,
+context managers, descriptors, decorators, metaclasses, and dynamic imports
+serve a concrete need and document non-obvious lifetime or execution behavior.
+
+Use annotations to communicate contracts, not as runtime validation. Preserve
+the project's typing style and supported-version constraints when choosing
+built-in generics, unions, protocols, overloads, `TypedDict`, generics,
+`TypeVar`, `ParamSpec`, or `Self`. Treat `Any`, casts, ignores, and
+`# type: ignore` as explicit escapes; narrow untrusted values with runtime
+checks at boundaries. Keep public annotations and stubs compatible with the
+declared interpreter range and type checker.
+
+Prefer cohesive modules and explicit imports. Avoid import-time network,
+filesystem, process, or service side effects. Keep module initialization
+predictable and make circular dependencies visible rather than masking them
+with local imports without a clear reason.
+
+## Errors, resources, and concurrency
+
+Raise specific exceptions with useful context and preserve causal chains with
+`raise ... from ...` when translating failures. Do not swallow broad
+exceptions, return ambiguous sentinels, or expose secrets and internal paths
+in public errors. Use `finally`, context managers, or structured cleanup for
+files, sockets, locks, temporary directories, subprocesses, and transactions.
+
+Use `asyncio` only when the workload and dependencies benefit from concurrent
+I/O. Keep blocking work off the event loop, propagate cancellation, bound
+queues and fan-out, set timeouts, and close tasks and clients during shutdown.
+Choose threads, processes, native extensions, or free-threaded Python from
+measured workload and dependency compatibility. Do not assume that the GIL
+provides application-level synchronization or that releasing it makes shared
+state safe.
+
+## Security and trust boundaries
+
+Treat request data, files, environment variables, serialized objects, SQL,
+templates, archive members, subprocess arguments, plugin metadata, and network
+responses as untrusted. Validate type, size, encoding, and allowed values
+before use. Prefer parameterized SQL and argument arrays; avoid shell
+interpolation, unsafe YAML loaders, `eval`, `exec`, and untrusted `pickle`
+deserialization. Apply archive path containment and decompression limits.
+
+Keep secrets out of source, exceptions, tracebacks exposed to users, test
+fixtures, and logs. Bound file and request sizes, recursion, concurrency,
+memory, CPU-heavy parsing, retries, and subprocess lifetimes. Use maintained
+dependencies with a recorded source and lock; review build backends and
+installation plugins as executable supply-chain code.
+
+## Testing and verification
+
+Select checks from risk and the project's declared tools:
+
+- unit tests for pure behavior and boundary cases;
+- integration tests for filesystem, database, network, subprocess, and
+  framework behavior;
+- contract tests for public APIs, serialization, CLI behavior, and supported
+  Python versions;
+- concurrency and cancellation tests for async tasks, workers, and shared
+  resources;
+- static typing and linting with the repository's configured tools;
+- packaging and installation checks in a clean environment when packaging
+  changes.
+
+Test malformed, empty, oversized, duplicated, reordered, and unexpected
+inputs; failure cleanup; cancellation; retries; and resource closure where
+applicable. Do not test only private implementation details. Keep tests
+deterministic, isolate external services, and do not claim skipped or
+unavailable platform checks passed. Record the exact interpreter, command,
+environment, and result.
+
+## Performance and operations
+
+Profile representative workloads before optimizing. Measure the relevant
+latency, throughput, memory, startup, allocation, and queue behavior with the
+same interpreter build, dependency set, input, and environment before and
+after a change. Avoid speculative micro-optimization and unbounded caches.
+
+Expose useful structured logs and metrics without logging secrets or
+high-cardinality user data. Make readiness, graceful shutdown, worker
+ownership, retry policy, and idempotency explicit for services and jobs.
+Document interpreter and OS support, native dependencies, environment
+variables, migration steps, and rollback behavior for deployable applications.
+
+## Python 3.15 compatibility review
+
+When adopting Python 3.15 features, verify the corresponding section of the
+versioned documentation and test the minimum supported interpreter. In
+particular:
+
+- explicit lazy imports change when import work and import errors occur;
+- UTF-8 default encoding can expose code that relied on locale-dependent
+  defaults;
+- comprehension unpacking and new built-in types may not parse or exist on
+  older supported interpreters;
+- experimental JIT or interpreter configuration is not a production
+  performance guarantee; benchmark the actual deployment build;
+- C API, ABI, build, deprecation, and removal changes require a separate
+  extension and dependency compatibility review.
+
+Do not copy preview-only behavior or assume that a 3.15 feature is available
+in every implementation or distribution build.
+
+## Definition of done
+
+- The project boundary, interpreter range, packaging tool, and target
+  platforms are confirmed from repository evidence.
+- The change preserves supported Python versions and public package/API
+  behavior, or documents an intentional migration.
+- Trust boundaries, exceptions, cancellation, and resource cleanup are
+  handled for the changed path.
+- Focused tests, configured static checks, and relevant package/build checks
+  pass; unavailable checks are `NOT_VERIFIED`.
+- Documentation describes the tested behavior and exact Python compatibility
+  range.
+
+## Official sources
+
+- [Python 3.15.0 documentation](https://docs.python.org/release/3.15.0/)
+- [What's New in Python 3.15](https://docs.python.org/3.15/whatsnew/3.15.html)
+- [Python version status](https://devguide.python.org/versions/)
+- [Python Enhancement Proposals](https://peps.python.org/)
+- [Python Packaging User Guide](https://packaging.python.org/)
+- [Python typing documentation](https://docs.python.org/3/library/typing.html)
+- [Python asyncio documentation](https://docs.python.org/3/library/asyncio.html)

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-09-11"
+last-reviewed: "2026-10-13"
 guide-id: rust
 requires-gates:
   - threat-boundary
@@ -108,6 +108,47 @@ manifest, lockfile, configuration, source, or generated output.
 
 ## 2. Authority, discovery, and version truth
 
+Rust 1.99.0 is the latest stable release as of 2026-10-13. This dated reference
+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.
+
+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
+project decision and matching CI coverage.
+
 Resolve conflicts in this order:
 
 1. Platform and safety rules.

package/ENG/sql-development-eng.md

@@ -3,7 +3,7 @@ name: sql-development-eng
 language: en
 description: "Specialist overlay guidance for SQL schemas, queries, migrations, and database-boundary changes."
 version: "2026.09"
-last-reviewed: "2026-09-12"
+last-reviewed: "2026-10-13"
 guide-id: sql
 requires-gates:
   - threat-boundary
@@ -37,9 +37,9 @@ migration, reads credentials, or introspects a schema.
 The repository's database engine, version, migration policy, transaction model,
 compatibility window, and deployment process win over generic SQL advice. Use
 the matching engine's official reference first, then ISO/IEC 9075:2023 for
-portable semantics. The research snapshot covers PostgreSQL 18.6, MySQL 9.7
-Innovation and 8.4 LTS, SQL Server 17 T-SQL, Oracle AI Database 26, and
-SQLite; these are reference points, not automatic upgrade targets.
+portable semantics. The 2026-10-13 reference check covers PostgreSQL 18.6, MySQL 9.7 Innovation
+and 8.4 LTS, SQL Server 17 T-SQL, Oracle AI Database 26, and SQLite 3.54.0.
+These are reference points, not automatic upgrade targets.
 
 Never infer a dialect, isolation guarantee, identifier rule, timestamp
 behavior, JSON extension, or migration capability from a file extension.

package/ENG/swift-development-eng.md

@@ -3,7 +3,7 @@ name: swift-development-eng
 language: en
 description: "Specialist guidance for production Swift applications, packages, services, and Apple-platform components."
 version: "2026.09"
-last-reviewed: "2026-09-12"
+last-reviewed: "2026-10-13"
 guide-id: swift
 requires-gates:
   - threat-boundary
@@ -34,9 +34,8 @@ plugins, build scripts, tests, or network resolution.
 Repository package manifest, toolchain, deployment target, SDK, target triple,
 entitlements, signing policy, ABI, and platform support win over generic
 advice. Use version-matched Swift language, SwiftPM, Apple SDK, and Xcode
-documentation after repository evidence. Swift 6.3 is the stable reference in
-the 2026-09 plan snapshot; the online language book's 6.4 beta material is not
-an automatic target.
+documentation after repository evidence. Swift 6.4 is the current stable reference as of 2026-10-13; it is not an
+automatic migration target.
 
 Keep Swift language mode, compiler/toolchain, SDK, deployment target, runtime
 OS, architecture, signing, entitlements, and package/platform compatibility
@@ -103,6 +102,8 @@ setting evaluation, macro execution, or Xcode build execution.
 
 ## Official sources
 
+- [Swift 6.4 release](https://www.swift.org/blog/swift-6.4-released/)
+
 - [The Swift Programming Language](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/)
 - [Swift.org documentation](https://www.swift.org/documentation/)
 - [Swift Package Manager](https://github.com/swiftlang/swift-package-manager)

package/ENG/test-code-eng.md

@@ -57,7 +57,7 @@ A tool is a candidate, not a ranking winner. Record the decision in the reposito
 
 | Context | Candidates with official documentation | Reproducible decision basis |
 | --- | --- | --- |
-| Node.js/TypeScript | [`node:test`](https://nodejs.org/api/test.html), [Vitest](https://vitest.dev/guide/), [Jest](https://jestjs.io/docs/getting-started) | existing framework/build, ESM/CJS, TypeScript, mocks, watch, coverage, and CI runtime |
+| Node.js/TypeScript | [`node:test`](https://nodejs.org/docs/latest-v24.x/api/test.html), [Vitest](https://vitest.dev/guide/), [Jest](https://jestjs.io/docs/getting-started) | existing framework/build, ESM/CJS, TypeScript, mocks, watch, coverage, and CI runtime |
 | Components and browser | [Testing Library](https://testing-library.com/docs/), [Playwright](https://playwright.dev/docs/intro), [Cypress](https://docs.cypress.io/) | required browsers, isolation, failure artifacts, parallelism, accessibility, and app compatibility |
 | Python | [pytest](https://docs.pytest.org/), [`unittest`](https://docs.python.org/3/library/unittest.html) | dependency policy, fixtures/plugins, Python versions, and existing integration |
 | .NET | [xUnit.net](https://xunit.net/), [NUnit](https://docs.nunit.org/), [MSTest](https://learn.microsoft.com/dotnet/core/testing/unit-testing-mstest-intro) | .NET version, runner/IDE, fixture model, assertions, and existing projects |

package/ENG/typescript-development-eng.md

@@ -3,7 +3,7 @@ name: typescript-development-eng
 language: en
 description: "Specialist guidance for TypeScript applications, libraries, build configurations, and typed JavaScript boundaries."
 version: "2026.09"
-last-reviewed: "2026-09-12"
+last-reviewed: "2026-10-13"
 guide-id: typescript
 requires-gates:
   - threat-boundary
@@ -33,9 +33,9 @@ compiler, package script, or project code.
 Repository compiler/configuration, emitted module contract, runtime support,
 public type compatibility, and build policy win over generic advice. Use the
 matching repository TypeScript version/config first, then official TypeScript
-documentation and release notes, then runtime/framework documentation. The
-2026-09 plan snapshot records TypeScript 7.0 as the current reference. TS 7.0
-uses the native Go-based toolset and does not provide a stable programmatic
+documentation and release notes, then runtime/framework documentation. As of
+2026-10-13, TypeScript 7.0 is the current reference. TS 7.0 uses the native
+Go-based toolset and does not provide a stable programmatic
 compiler API; TS 6 compatibility can remain necessary for tooling. Do not
 auto-migrate TS 6 projects or compiler integrations to TS 7.
 

package/GUIDE_ROUTER.md

@@ -63,8 +63,14 @@ project commands.
 | `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 |
+| `python` | [Python development engineering](./ENG/python-development-eng.md) | Python applications, packages, CLIs, async services, data pipelines, and native extensions (reference guide; project auto-routing is not implemented) |
 | `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 |
 
+The Python guide is available as bounded reference material, but the current
+`forgeloop route` project-evidence schema does not detect Python projects or
+select the guide automatically. Do not claim automatic Python routing until
+structural detection and route tests are implemented.
+
 ## Domain rules
 
 ### `clean` — code and structure