@cassiomc1/forgeloop 1.13.0 → 2.0.0-rc.2

package/ENG/sec-code-eng.md

@@ -677,11 +677,11 @@ data independently of that choice.
 
 ## Sources and References
 
-- OWASP ASVS 5.0.0: https://owasp.org/www-project-application-security-verification-standard/
+- OWASP ASVS 5.0.0: https://owasp.org/projects/asvs
 - Official OWASP ASVS 5.0.0 CSV: https://github.com/OWASP/ASVS/raw/v5.0.0/5.0/docs_en/OWASP_Application_Security_Verification_Standard_5.0.0_en.csv
 - OWASP Top 10:2025 (Web): https://owasp.org/Top10/2025/
 - OWASP Mobile Top 10:2024: https://owasp.org/www-project-mobile-top-10/
-- OWASP Mobile Application Security Verification Standard (MASVS) / MASTG: https://owasp.org/www-project-mobile-app-security/
+- OWASP Mobile Application Security Verification Standard (MASVS) / MASTG: https://owasp.org/projects/mobile-application-security
 - OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org/
 - OWASP SSRF Prevention: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
 - OWASP File Upload: https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html
@@ -700,11 +700,11 @@ data independently of that choice.
 - Android Network Security Config and Certificate Transparency: https://developer.android.com/privacy-and-security/security-config
 - Android cryptography and Keystore: https://developer.android.com/privacy-and-security/cryptography
 - Android `EncryptedSharedPreferences` (deprecated): https://developer.android.com/reference/androidx/security/crypto/EncryptedSharedPreferences
-- OAuth 2.0 Security Best Current Practice, RFC 9700: https://www.rfc-editor.org/rfc/rfc9700
-- JWT Best Current Practices, RFC 8725: https://www.rfc-editor.org/rfc/rfc8725
-- Web Origin, RFC 6454: https://www.rfc-editor.org/rfc/rfc6454
-- OAuth 2.0 Token Introspection, RFC 7662: https://www.rfc-editor.org/rfc/rfc7662
-- ChaCha20-Poly1305, RFC 8439: https://www.rfc-editor.org/rfc/rfc8439
+- OAuth 2.0 Security Best Current Practice, RFC 9700: https://datatracker.ietf.org/doc/html/rfc9700
+- JWT Best Current Practices, RFC 8725: https://datatracker.ietf.org/doc/html/rfc8725
+- Web Origin, RFC 6454: https://datatracker.ietf.org/doc/html/rfc6454
+- OAuth 2.0 Token Introspection, RFC 7662: https://datatracker.ietf.org/doc/html/rfc7662
+- ChaCha20-Poly1305, RFC 8439: https://datatracker.ietf.org/doc/html/rfc8439
 - GitHub Actions: use full-length commit SHA: https://docs.github.com/en/actions/reference/security/secure-use
 - GitHub artifact attestations: https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations
 - Apple Platform Security Guide: https://support.apple.com/guide/security/

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/EXECUTION_STATE.md

@@ -31,6 +31,18 @@ task-bound `COMPLETION_VALIDATED` event and coherent state) is required, and a
 forged or unproven COMPLETE state is `INCONSISTENT` with historical claims
 retained.
 
+For an intentional active-task stop, use the explicit canonical command:
+
+```bash
+forgeloop task-abandon --task <id> --acknowledge-abandonment --json
+```
+
+It appends `TASK_ABANDONED`, writes a matching recovery boundary classified
+`ABANDONED`, keeps the current phase unchanged, and resolves ownership to
+`RELEASED_BY_RECOVERY`. It never emits `COMPLETION_VALIDATED` and never grants
+publication authority. `clear-state` only clears a checkpoint and must not be
+used to release claims.
+
 The file is local, ignored by Git, schema-versioned, and never a replacement
 for the manifest or the target project profile (installed as
 `.forgeloop/kit/PROJECT_PROFILE.md`). It contains no secrets and is untrusted

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

package/LICENSE

@@ -1,21 +1,133 @@
-MIT License
-
-Copyright (c) 2026 Cassio
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+# PolyForm Noncommercial License 1.0.0
+
+<https://polyformproject.org/licenses/noncommercial/1.0.0>
+
+## Acceptance
+
+In order to get any license under these terms, you must agree
+to them as both strict obligations and conditions to all
+your licenses.
+
+## Copyright License
+
+The licensor grants you a copyright license for the
+software to do everything you might do with the software
+that would otherwise infringe the licensor's copyright
+in it for any permitted purpose.  However, you may
+only distribute the software according to [Distribution
+License](#distribution-license) and make changes or new works
+based on the software according to [Changes and New Works
+License](#changes-and-new-works-license).
+
+## Distribution License
+
+The licensor grants you an additional copyright license
+to distribute copies of the software.  Your license
+to distribute covers distributing the software with
+changes and new works permitted by [Changes and New Works
+License](#changes-and-new-works-license).
+
+## Notices
+
+You must ensure that anyone who gets a copy of any part of
+the software from you also gets a copy of these terms or the
+URL for them above, as well as copies of any plain-text lines
+beginning with `Required Notice:` that the licensor provided
+with the software.  For example:
+
+> Required Notice: Copyright Yoyodyne, Inc. (http://example.com)
+
+## Changes and New Works License
+
+The licensor grants you an additional copyright license to
+make changes and new works based on the software for any
+permitted purpose.
+
+## Patent License
+
+The licensor grants you a patent license for the software that
+covers patent claims the licensor can license, or becomes able
+to license, that you would infringe by using the software.
+
+## Noncommercial Purposes
+
+Any noncommercial purpose is a permitted purpose.
+
+## Personal Uses
+
+Personal use for research, experiment, and testing for
+the benefit of public knowledge, personal study, private
+entertainment, hobby projects, amateur pursuits, or religious
+observance, without any anticipated commercial application,
+is use for a permitted purpose.
+
+## Noncommercial Organizations
+
+Use by any charitable organization, educational institution,
+public research organization, public safety or health
+organization, environmental protection organization,
+or government institution is use for a permitted purpose
+regardless of the source of funding or obligations resulting
+from the funding.
+
+## Fair Use
+
+You may have "fair use" rights for the software under the
+law. These terms do not limit them.
+
+## No Other Rights
+
+These terms do not allow you to sublicense or transfer any of
+your licenses to anyone else, or prevent the licensor from
+granting licenses to anyone else.  These terms do not imply
+any other licenses.
+
+## Patent Defense
+
+If you make any written claim that the software infringes or
+contributes to infringement of any patent, your patent license
+for the software granted under these terms ends immediately. If
+your company makes such a claim, your patent license ends
+immediately for work on behalf of your company.
+
+## Violations
+
+The first time you are notified in writing that you have
+violated any of these terms, or done anything with the software
+not covered by your licenses, your licenses can nonetheless
+continue if you come into full compliance with these terms,
+and take practical steps to correct past violations, within
+32 days of receiving notice.  Otherwise, all your licenses
+end immediately.
+
+## No Liability
+
+***As far as the law allows, the software comes as is, without
+any warranty or condition, and the licensor will not be liable
+to you for any damages arising out of these terms or the use
+or nature of the software, under any kind of legal claim.***
+
+## Definitions
+
+The **licensor** is the individual or entity offering these
+terms, and the **software** is the software the licensor makes
+available under these terms.
+
+**You** refers to the individual or entity agreeing to these
+terms.
+
+**Your company** is any legal entity, sole proprietorship,
+or other kind of organization that you work for, plus all
+organizations that have control over, are under the control of,
+or are under common control with that organization.  **Control**
+means ownership of substantially all the assets of an entity,
+or the power to direct its management and policies by vote,
+contract, or otherwise.  Control can be direct or indirect.
+
+**Your licenses** are all the licenses granted to you for the
+software under these terms.
+
+**Use** means anything you do with the software requiring one
+of your licenses.
+
+Required Notice: Copyright (c) 2026 Cassio Marques Campos

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/LOOP_SYSTEM_DESIGN.md

@@ -24,7 +24,7 @@ The system should use every guide that materially helps the task without loading
 - The loop continues while safe progress is possible. Repetition without new evidence triggers hypothesis reassessment or a blocked result, not infinite retries.
 - Third-party provenance and reuse boundaries remain part of every portable copy.
 - Qwen-MM-Plugins is an optional, task-scoped capability extension: the agent checks native support first, installs the smallest missing capability when needed, and verifies it before use; it is not a package or runtime dependency.
-- Canonical documents are installed under `.forgeloop/kit/`; root native adapters remain small discovery shims; project-scoped configuration remains under `.forgeloop/`; and modern mutable task protocol state is isolated under `.forgeloop/task-state/<taskKey>/`.
+- Canonical documents are installed under `.forgeloop/kit/`; root native adapters remain small discovery shims; project-scoped configuration remains under `.forgeloop/`; operational task records use `.forgeloop/state.sqlite` in SQLite mode. `.forgeloop/task-state/<taskKey>/` remains the logical and portable export path for task artifacts. Legacy filesystem mode remains a separate compatibility path, and SQLite capability still reports `soleSQLiteWriter: false` while legacy writers remain.
 - `PREFLIGHT_READY` is a resumable protocol checkpoint reconciled with work state, activation events, fingerprints, and the append-only hash chain.
 
 ## Alternatives considered
@@ -446,15 +446,15 @@ The validator also exercises seven routing scenarios:
 The npm CLI installs the kit into the current directory or an existing
 directory selected with `--path` when the package is available in the npm
 registry. If it is not available yet, the same commands can run as
-`node src/cli.js ...` from a repository checkout. The CLI maps canonical
-documents into `.forgeloop/kit/`, keeps only native instruction shims at the
-target root, and leaves project-scoped configuration under `.forgeloop/` while
-isolating modern mutable task protocol state (contract, route, gate, state,
-event, preflight, receipt, and recovery artifacts) under
-`.forgeloop/task-state/<taskKey>/`. Legacy singleton artifacts remain under
-`.forgeloop/` for compatibility and migration only. Manual copying must
-preserve that target layout; copying package-source root files directly is not
-equivalent to `forgeloop init`.
+`node src/cli.js ...` from a repository checkout. The CLI maps canonical documents into `.forgeloop/kit/`, keeps only native
+instruction shims at the target root, and leaves project-scoped configuration
+under `.forgeloop/`. In SQLite mode, mutable task records are stored in
+`.forgeloop/state.sqlite`; `.forgeloop/task-state/<taskKey>/` is the logical
+task-artifact and portable export path, not a claim that each artifact exists
+as a live filesystem file. Legacy filesystem mode remains a separate
+compatibility path, and SQLite mode must not share writable operational state
+with it. Manual copying must preserve the target layout; copying package-source
+root files directly is not equivalent to `forgeloop init`.
 
 Recovery uses a relational state model: `work-state.json` owns the lifecycle
 phase, `task.json` retains historical claims, `recovery.json` records current

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
 

package/PROTOCOL_INTEGRATION.md

@@ -181,6 +181,16 @@ authority, provenance, and safety-floor decisions remain unchanged.
 validator-backed completion remains unchanged.
 ```
 
+The capability handshake also advertises the versioned, read-only `auditUx`
+resource feature. `task/audit-view` is a bounded presentation projection
+composed from canonical status, audit, report, history, trace, ownership,
+next-action, approval, and recovery resolvers. It exposes no lifecycle,
+evidence, completion, mutation, or external-execution authority; hosts must
+use the canonical command/API path for mutations. Timeline pagination is
+sequence-based and bounded, and the projection omits raw event payloads,
+commands, environment values, credentials, provider output, and absolute
+paths. See [`docs/AUDIT_UX.md`](./docs/AUDIT_UX.md).
+
 ## Capability negotiation
 
 The public capability handshake exposes additive capability families separately
@@ -190,6 +200,7 @@ from Protocol v1, schema v1, and Integration API v1:
 | --- | --- | --- |
 | `canonicalHandoffs` | v2 | Immutable handoff snapshots with ledger-backed exactly-once operational acceptance |
 | `advisoryContextProviders` | v1 | Lazy, opt-in, provider-neutral Integration API injection only |
+| `providerExtensions` | v1 | Experimental provider-neutral capability vocabulary; generic registry remains internal and unexported |
 
 `repositoryIndex` v1 is a mandatory provider-neutral discovery capability for
 Git repositories. ForgeLoop currently implements it with a managed, pinned
@@ -223,6 +234,40 @@ instructions. `protocol-info` may advertise the capability, but advisory
 recall remains a programmatic Integration API operation; there is no stock
 `context-recall` CLI command.
 
+<a id="FL-PROVIDER-001"></a> **FL-PROVIDER-001 — `providerExtensions` MUST remain provider-neutral and experimental and MUST NOT imply a public generic provider registry API.**
+
+<a id="FL-PROVIDER-002"></a> **FL-PROVIDER-002 — Every advertised provider kind MUST deny lifecycle, completion, and evidence authority.**
+
+<a id="FL-PROVIDER-003"></a> **FL-PROVIDER-003 — Provider results MUST cross a strict JSON snapshot boundary before consumer use.**
+
+<a id="FL-PROVIDER-004"></a> **FL-PROVIDER-004 — The generic provider registry MUST remain absent from public package subpath exports.**
+
+`providerExtensions` v1 is provider-neutral and experimental. It advertises
+five provider kinds, strict JSON result normalization, cooperative cancellation,
+and false lifecycle, completion, evidence, and auto-install authority. This
+capability advertisement does not imply a generic public provider registration
+API or a supported `./providers` package subpath. Protocol version remains 1,
+Schema version remains 1, and Integration API version remains 1.
+
+The dedicated `browserVerificationProviders` runtime-context option is a
+separate explicit Integration API boundary. It is host-injected, provider
+neutral, lazy, and inert during context construction. `runBrowserVerification`
+is the only public operation; it does not run from lifecycle commands and does
+not persist observations. ForgeLoop owns the shared deadline, cooperative
+cancellation, strict result snapshot, exact origin/redirect validation, and
+overall assertion-status derivation. Browser observations cannot directly
+create evidence, completion authority, claims, receipts, or next actions. The
+origin allowlist is not a network sandbox and no browser vendor is canonical.
+
+The dedicated `securityReviewProviders` runtime-context option is another
+explicit, host-injected Integration API boundary. `runSecurityReview` is
+lazy, inert during context construction, and observation-only: it does not
+install or discover scanners, mutate lifecycle artifacts, create evidence,
+authorize completion, or issue commands. ForgeLoop bounds and freezes the
+request, shares one deadline and cooperative abort signal across factory and
+review, and normalizes the result into a strict immutable observation. Findings
+must not be treated as canonical evidence or lifecycle authority.
+
 A consumer that understands `canonicalHandoffs` v1 but not v2 may disable the
 handoff-specific UI while keeping Protocol v1 core functionality available.
 Consumers must feature-detect the capability family and must not mark the
@@ -394,6 +439,12 @@ only a compatibility alias and has identical caller-acknowledgement semantics.
 a trusted grant reference through a boundary the active actor cannot mint or
 replace. The standalone CLI does not expose such a self-attestation option.
 
+Explicit active-task abandonment is a distinct caller-acknowledged operation:
+`task-abandon --task <id> --acknowledge-abandonment` releases validated claims
+through the same canonical ownership resolver, project/task serialization, and
+append-only recovery history. It does not change the phase or create completion,
+publication, or host authority. `clear-state` is not an abandonment substitute.
+
 Claim ownership is a validated relationship, not an artifact preference.
 <a id="FL-CLAIM-001"></a> **FL-CLAIM-001 — Every harness MUST consume the canonical claim-state resolver**
 over the descriptor, work state, recovery artifact, and complete validated
@@ -488,8 +539,10 @@ installing a package.
 
 The installed loop directs the active actor to inspect native model and harness
 capabilities. When a task requires a missing capability (e.g. multimodal vision),
-the actor may install the smallest task-scoped capability (such as `Qwen-MM-Plugins`)
-through native mechanisms or upstream installers, then verify it before use.
+a host or operator may provision the smallest task-scoped capability (such as
+`Qwen-MM-Plugins`) only when installation authority has been explicitly
+granted. Use native mechanisms or upstream installers, then verify it before
+use. Without that authority, keep it unavailable and report the limitation.
 
 API credentials, system packages, and unrelated environment changes remain
 separately gated.