Skip to content

Releases: fireflyframework/firefly-forge

firefly forge v0.2.49

Choose a tag to compare

@ancongui ancongui released this 31 Oct 01:26
0225325

0.2.49

Saved final-result recovery now carries its completed native custody into the following verification and Git checks. The factory checks the original response and completion receipt, current project access, provider settings and supported runtime before continuing the same run. Pending actions keep their existing claim and lease checks. Missing receipts, changed authorization or altered usage leave the operation unavailable.

Verification can adopt the current policy after recovery while retaining the commands and continuations already spent. Later stages recognize the original acknowledged command history after worker feedback changes the pending question. This supplies no new coding grant and does not replay a consumed response or an uncertain command. The claim window remains separate from the project's QA duration. See verification after recovery.

The Studio documentation captures are refreshed for desktop and mobile in both appearances. They use controlled fixtures; a successful recovery screen does not establish that a generated product passed QA or reached GitHub.

Full release history

firefly forge v0.2.48

Choose a tag to compare

@github-actions github-actions released this 30 Oct 01:04
6c97f1b

description: Review firefly forge release changes, runtime requirements and the verification boundaries of each published version.

firefly forge release notes

0.2.48

Stopped combined installations can move their private storage and selected verification runtimes through offline location maintenance. A reviewed, authenticated receipt binds the new physical paths while preserving original topology, command arguments, source evidence and counters. A new verification environment requires fresh checks; maintenance itself starts no model or project work.

Partial-source recovery accepts the current checkpoint binding through its compact source identity. The receipt still hashes the complete invocation and validates its retained work policy before any Git operation.

New runs record a versioned work policy. The default has no fixed work deadline. Operators can choose a positive deadline when a project needs one; request waits and ownership heartbeats are configured separately. Old runs retain their captured policy. The CLI and automatic framework checks use the same distinction. See runner configuration.

Trusted-host process tools can start a command, inspect its output, wait for a condition and cancel the owned process group. A waiting observation can finish while the process continues. Process monitoring remains unavailable for Docker, pool and required-checkpoint invocations; unsupported grants are refused before dispatch.

Separately, distributed commands can select an explicit run-owned pool profile with a version-two work policy. Healthy queued commands renew their original admission without a fixed waiting-age ceiling. A chosen command deadline starts at execution. The controller requires the current run, task, actor and worker ownership; expired or canceled admissions cannot be revived. Plain Docker and untagged pool profiles retain their documented restrictions.

Authenticated status exchanges advance their sequence through every draining and drained response. Slow cleanup can therefore require several polls without producing a stale-frame rejection. Those acknowledgements do not extend the work deadline or owner alarm.

Checkpoint version 3 retains the selected work policy. Provider negotiation requires an advertised compatible protocol; the factory refuses an unsupported request instead of selecting a hidden deadline.

Acknowledged-command custody follows the native implementation intent and receipt. A model response can update progress before its terminal receipt commits; this interval retains its unfinished native phase for the existing acknowledgement proof. Unknown command outcomes and spent budgets remain unchanged.

An already-consumed final report has a separate reviewed continuation. Its worker records native acceptance from the retained typed response without another model call, response consumption or completed effect. Studio distinguishes accepting that report from completing the run, and retains one action identity through reloads and uncertain submission responses. The three corresponding operator MCP tools bring the catalog to 185. See saved final results.

Verification distinguishes retained check results from fresh executions. Reuse requires explicit declarations and captured source, dependency and execution evidence. Frontend builds that need generated-output metadata execute fresh and consume their normal allowance; they cannot be selected for reuse. The runtime guard can measure an exact-empty npm builtin configuration bound to its admitted executable and package, while the build process still cannot read private npm configuration. See verification results.

Explicit version-two work policies also reach external MCP calls. Connection, catalog and cleanup operations keep separate finite control windows; a selected work deadline is measured from the original call and does not restart after the handshake. The broker renews a separate native ownership lease while the admitted operation remains authorized. A late result after revocation or owner loss stays unresolved and cannot trigger automatic resubmission. An older capture retains its original timeout contract.

Source-profile registration, package validation and installed acceptance cover execution compatibility. They do not establish delivery of a generated product. Managed subagent delegation is a separate capability and is not enabled by these runner tools. Follow agent lifecycle and run evidence when reviewing a delivery.

0.2.47

Official framework references have immutable corpus identities, bounded refresh operations, version checks and generation pins. Binary reference exclusions do not grant authority to corrupt private cache bytes. The catalog retains its original 322 prompt entries and adds eleven framework templates; the MCP surface has 182 tools. See framework reference refresh.

A namespaced rejected evidence-read continuation reconstructs one known consumed negative tool turn offline. It permits only the reviewed strict evidence schema and description changes, recognizes a pinned historical policy epoch under current authority, and queues a finite same-attempt ownership lease. It preserves the original consumption, configuration, source at admission, history, limits and unknown-effect custody. Controlled regression cases advance command usage from 11 of 22 to 13 of 22 after two new commands; duplicate readback adds no charge. These cases do not establish delivery of a retained customer run.

Version-2 continuity can return an explicitly unavailable observation for pinned, granted list_files siblings. It requires a default-off administrator setting and acknowledgement on the exact request. It neither repeats the old reader nor invents its result.

Native API and Bridge workers now retain exact public-call custody for nine implementation tools through the framework capability interface. Raw and validated arguments remain distinct; large JSON values use immutable private artifacts. Unknown writes and commands hold further work. Other tool families report their uncaptured status explicitly. Studio shows readable arguments, output and links to native effects. See run evidence and agent lifecycle.

A separately registered SDK migration handles the known historical checkpoint format. Its witness binds the original and derived checkpoints, preserves both additional usage counters, and records each telemetry collector as unknown or known empty. It also distinguishes an absent tool-kind field from an existing null. Nonempty telemetry, unapproved tool changes and unsupported runtime versions are refused. Ordinary checkpoint restoration keeps its exact-version checks.

After cancellation, a current administrator can observe a framework refresh whose source write has an uncertain outcome. Observation uses retained source identities and GET requests; it keeps the operation cancelled and cannot submit another source or activate a corpus. Revoked administrator access stops observation.

Native CLI metadata discovery uses the caller's finite timeout without a model request. Studio and walkthrough metadata identify version 0.2.47. This release completed source-profile registration, controlled native qualification, package validation and source and installed configuration-RPC checks. Its published wheel and source archive match the qualified distributions, and the release workflow, documentation site and container publication were verified. Those proofs do not establish delivered CRM, live external-provider quality or a deployed service.

0.2.46 — changes included in the 0.2.47 preview

The model-facing read_run_evidence tool now publishes its exact query schema. Unknown fields, invalid types, malformed JSON and incomplete pagination cursors produce a fixed invalid_query tool result before the native evidence service runs. That result contains no evidence. It preserves ordinary tool history, so correcting the query does not introduce SDK retry state that checkpoints cannot restore. Worker pages default to ten records and accept at most ten, matching the existing native limit. The operator API keeps its separate fifty-record limit.

A corrected call still uses the original execution identity and role. Authorization, integrity, credential and unresolved-effect failures remain terminal. Query corrections consume the existing request and tool-call budgets. Validation feedback does not resume work, replay a tool or reset a budget. The new native source profile requires fresh measurements for this runtime; historical profile literals and receipts remain unchanged. Controlled tests do not establish completion of the retained CRM.

0.2.45

Project and campaign views use complete pages and revision-bound references instead of a fixed project-count ceiling. Campaign execution windows are f...

Read more

firefly forge v0.2.47

Choose a tag to compare

@github-actions github-actions released this 29 Oct 03:05
4466e8c

description: Review firefly forge release changes, runtime requirements and the verification boundaries of each published version.

firefly forge release notes

0.2.47 — implementation preview

Official framework references have immutable corpus identities, bounded refresh operations, version checks and generation pins. Binary reference exclusions do not grant authority to corrupt private cache bytes. The catalog retains its original 322 prompt entries and adds eleven framework templates; the MCP surface has 182 tools. See framework reference refresh.

A namespaced rejected evidence-read continuation reconstructs one known consumed negative tool turn offline. It permits only the reviewed strict evidence schema and description changes, recognizes a pinned historical policy epoch under current authority, and queues a finite same-attempt ownership lease. It preserves the original consumption, configuration, source at admission, history, limits and unknown-effect custody. Controlled regression cases advance command usage from 11 of 22 to 13 of 22 after two new commands; duplicate readback adds no charge. These cases do not establish delivery of a retained customer run.

Version-2 continuity can return an explicitly unavailable observation for pinned, granted list_files siblings. It requires a default-off administrator setting and acknowledgement on the exact request. It neither repeats the old reader nor invents its result.

Native API and Bridge workers now retain exact public-call custody for nine implementation tools through the framework capability interface. Raw and validated arguments remain distinct; large JSON values use immutable private artifacts. Unknown writes and commands hold further work. Other tool families report their uncaptured status explicitly. Studio shows readable arguments, output and links to native effects. See run evidence and agent lifecycle.

A separately registered SDK migration handles the known historical checkpoint format. Its witness binds the original and derived checkpoints, preserves both additional usage counters, and records each telemetry collector as unknown or known empty. It also distinguishes an absent tool-kind field from an existing null. Nonempty telemetry, unapproved tool changes and unsupported runtime versions are refused. Ordinary checkpoint restoration keeps its exact-version checks.

After cancellation, a current administrator can observe a framework refresh whose source write has an uncertain outcome. Observation uses retained source identities and GET requests; it keeps the operation cancelled and cannot submit another source or activate a corpus. Revoked administrator access stops observation.

Native CLI metadata discovery uses the caller's finite timeout without a model request. Studio and walkthrough metadata identify version 0.2.47. The composed source still requires independent current-profile registration, native PostgreSQL/controller qualification and exact original-custody review before retained-run admission. Host controls and fixture screenshots do not establish a published release, live provider quality or delivered CRM.

0.2.46 — changes included in the 0.2.47 preview

The model-facing read_run_evidence tool now publishes its exact query schema. Unknown fields, invalid types, malformed JSON and incomplete pagination cursors produce a fixed invalid_query tool result before the native evidence service runs. That result contains no evidence. It preserves ordinary tool history, so correcting the query does not introduce SDK retry state that checkpoints cannot restore. Worker pages default to ten records and accept at most ten, matching the existing native limit. The operator API keeps its separate fifty-record limit.

A corrected call still uses the original execution identity and role. Authorization, integrity, credential and unresolved-effect failures remain terminal. Query corrections consume the existing request and tool-call budgets. Validation feedback does not resume work, replay a tool or reset a budget. The new native source profile requires fresh measurements for this runtime; historical profile literals and receipts remain unchanged. Controlled tests do not establish completion of the retained CRM.

0.2.45

Project and campaign views use complete pages and revision-bound references instead of a fixed project-count ceiling. Campaign execution windows are finite, configurable and checked against retained usage. Credential fingerprint preparation and checkpoint source identity stream outside database writer units, with current source, credential and ownership checks retained. See large-product boundaries and project campaigns.

Contextual communication supplies the AI writer with the current recorded verification reason, source, check state and next factory action. A pending verification request remains factory work; earlier completed checks remain labeled as historical context. Six additional versioned templates extend the catalog to 321 entries without changing the original 315. Recorded facts do not invent a root cause or grant execution authority. Natural status replies use the current execution projection and the existing AI draft/review route, rather than publishing the classifier's historical wording. An unpublished classifier follow-up does not become worker-question authority.

Normal and blocked worker outcomes enter atomic native completion custody, including restored checkpoints, before QA or Git delivery proceeds. An administrator can separately acknowledge an exact unknown command and bind a fresh verification continuation to its current source, commands, policy, provider and next command ordinals. Its completed known result can authorize only the corresponding factory-response, coding, QA and Git lineage. The original unknown record and spent slots remain unchanged. Current acknowledging-actor authority is checked again before dispatch and local or remote Git effects. The existing command and repair budgets remain in force; see verification recovery.

An eligible older Bridge continuation can explicitly adopt stronger checkpoint and original-result recovery settings after a recorded missing-mode failure before model dispatch. A current native administrator reviews the exact source, unfinished intents, configuration and operator observation. The adoption retains the original provider revision, unknown outcomes and spent budgets; it does not complete the original intent or change providers. See checkpoint mode adoption.

Issue status follows validated native test and maintenance descendants while retaining the root conversation receipt. It selects an unambiguous current leaf using immutable admission evidence, rather than mutable run update times. Multiple active branches or tied latest leaves require clarification.

Fixed workspace exports include the audited credential-scanner dependencies and streaming chunk limit. Later QA receipts no longer enter unrelated duplicate worker-outcome preparation inside their native transaction. Malformed historical verification requests are withheld from public facts.

Same-provider Bridge verification continuations preserve the originally selected named model profile instead of replacing it with generic transport settings. An eligible retained failure before model dispatch has a separate native readmission path with current source, profile and actor checks. Its original configuration, prior claims and spent budgets remain immutable; see original-selection readmission.

A restart records a recovery witness for the current task intent or explicit readmission claim. A task already held after an earlier missing annotation can receive that new witness without rewriting the task or replaying work. Later attempts retain earlier claim metadata only as history. Unknown Bridge outcomes still refuse before provider configuration or routing is read.

The current source profile binds explicit admission and checkpoint-runtime dependency inventories plus 22 loader inputs. Every historical profile literal remains unchanged. Registration requires fresh controlled native tool-boundary, PostgreSQL budget/command/paging and terminal-completion measurements; the real native configuration RPC is checked again afterward without a model call. Studio 0.2.45 retains its fresh build and fixture captures. These proofs do not establish completed CRM delivery, live external-provider quality or a remote deployment.

A retained source-catalog manifest now binds its complete immutable hash and stable identity across checks. This addresses an observed ctime-only metadata change on a macOS Documents-backed catalog without refreshing its reference or accepting changed content. The bounded descriptor read and surrounding path checks still compare full timestamps during I/O and enforce the original inode, owner, mode and link guards. Current source, authority and live recovery acceptance remain required. Selected so...

Read more

firefly forge v0.2.45

Choose a tag to compare

@github-actions github-actions released this 26 Oct 17:43
f651323

description: Review firefly forge release changes, runtime requirements and the verification boundaries of each published version.

firefly forge release notes

0.2.45

Project and campaign views use complete pages and revision-bound references instead of a fixed project-count ceiling. Campaign execution windows are finite, configurable and checked against retained usage. Credential fingerprint preparation and checkpoint source identity stream outside database writer units, with current source, credential and ownership checks retained. See large-product boundaries and project campaigns.

Contextual communication supplies the AI writer with the current recorded verification reason, source, check state and next factory action. A pending verification request remains factory work; earlier completed checks remain labeled as historical context. Six additional versioned templates extend the catalog to 321 entries without changing the original 315. Recorded facts do not invent a root cause or grant execution authority. Natural status replies use the current execution projection and the existing AI draft/review route, rather than publishing the classifier's historical wording. An unpublished classifier follow-up does not become worker-question authority.

Normal and blocked worker outcomes enter atomic native completion custody, including restored checkpoints, before QA or Git delivery proceeds. An administrator can separately acknowledge an exact unknown command and bind a fresh verification continuation to its current source, commands, policy, provider and next command ordinals. Its completed known result can authorize only the corresponding factory-response, coding, QA and Git lineage. The original unknown record and spent slots remain unchanged. Current acknowledging-actor authority is checked again before dispatch and local or remote Git effects. The existing command and repair budgets remain in force; see verification recovery.

An eligible older Bridge continuation can explicitly adopt stronger checkpoint and original-result recovery settings after a recorded missing-mode failure before model dispatch. A current native administrator reviews the exact source, unfinished intents, configuration and operator observation. The adoption retains the original provider revision, unknown outcomes and spent budgets; it does not complete the original intent or change providers. See checkpoint mode adoption.

Issue status follows validated native test and maintenance descendants while retaining the root conversation receipt. It selects an unambiguous current leaf using immutable admission evidence, rather than mutable run update times. Multiple active branches or tied latest leaves require clarification.

Fixed workspace exports include the audited credential-scanner dependencies and streaming chunk limit. Later QA receipts no longer enter unrelated duplicate worker-outcome preparation inside their native transaction. Malformed historical verification requests are withheld from public facts.

Same-provider Bridge verification continuations preserve the originally selected named model profile instead of replacing it with generic transport settings. An eligible retained failure before model dispatch has a separate native readmission path with current source, profile and actor checks. Its original configuration, prior claims and spent budgets remain immutable; see original-selection readmission.

A restart records a recovery witness for the current task intent or explicit readmission claim. A task already held after an earlier missing annotation can receive that new witness without rewriting the task or replaying work. Later attempts retain earlier claim metadata only as history. Unknown Bridge outcomes still refuse before provider configuration or routing is read.

The current source profile binds explicit admission and checkpoint-runtime dependency inventories plus 22 loader inputs. Every historical profile literal remains unchanged. Registration requires fresh controlled native tool-boundary, PostgreSQL budget/command/paging and terminal-completion measurements; the real native configuration RPC is checked again afterward without a model call. Studio 0.2.45 retains its fresh build and fixture captures. These proofs do not establish completed CRM delivery, live external-provider quality or a remote deployment.

A retained source-catalog manifest now binds its complete immutable hash and stable identity across checks. This addresses an observed ctime-only metadata change on a macOS Documents-backed catalog without refreshing its reference or accepting changed content. The bounded descriptor read and surrounding path checks still compare full timestamps during I/O and enforce the original inode, owner, mode and link guards. Current source, authority and live recovery acceptance remain required. Selected source files retain their unchanged-metadata fast path. A ctime-only change can instead use a bounded streaming hash against the original retained payload digest, while device, inode, owner, group, mode, link count, size and modification time remain exact. Full metadata and path identity remain strict during the read; a payload change or race still holds. The observed metadata changes do not identify their author.

0.2.44

The version-3 checkpoint codec stores identical native history and request_history arrays once before compression. Decoding reconstructs the complete canonical record, checks the expanded size before allocating the mirrored record, and verifies its full SHA-256. Version-1 raw records and version-2 compressed records remain readable with their original encoded identities. Restored model requests must still reproduce exact wire bytes, usage, limits and file-tool state; consumed results and completed tools are never replayed.

Encoded-size refusals are distinct from digest refusals and do not expose record content. Capacity remains bounded: 192 KiB per encoded snapshot, 8 MiB per raw canonical record, 256 KiB per WAL envelope, and 4 MiB of per-run checkpoint/consume evidence. Deduplication improves capacity for mirrored history; it cannot make arbitrary input fit those limits. A content-addressed, chunked overflow path remains pending. This release does not claim unlimited or complete enterprise history storage.

The V13 profile has fresh native 250-case and SQL54/24/6 qualification on the measured protected source. The 22 loader inputs, 35 admission modules and 315 templates remain explicitly bound, with the prior eight profile literals and seals preserved. High-entropy, six-turn SDK tests cover exact next-request restoration, cumulative usage and one-use consumption; current credential and authority guards remain in force. These proofs do not establish completion of a generated CRM or a live product journey.

Backend 0.2.44 intentionally ships the unchanged Studio 0.2.42 source, compiled assets and captures. No UI refresh, new screenshot qualification or relabeled images is claimed. See checkpoint recovery for the remaining restoration and capacity boundaries.

0.2.43

Command slots now come from a durable, atomic run/task/attempt cursor. Fresh service instances allocate a new invocation; an explicit ordinal retains exact replay semantics. Pending, unknown, interrupted or unowned effects hold further dispatch. Command-enabled graph restoration accepts canonical, fully completed durable v2 records only, checks their position before the selected checkpoint or after the matching consume, and preserves lifetime command and browser budgets.

Accumulated native history uses a lossless, versioned canonical zlib/base64 envelope above 64 KiB. The raw record is limited to 8 MiB, the encoded snapshot to 192 KiB, and the complete WAL envelope and reserve to 256 KiB. Bounded decoding verifies the raw size and hash, canonical encoding, complete stream and absence of trailing data. Capture, consume, restore and generic journal reads scan the full decoded record against current credentials. A restored request retains its original encoded bytes and must match native history, usage, limits, state and wire identity. Unknown or consumed results are never re-armed.

Complete branding assets are staged through ordinary workspace tools while the model receives their compact path/hash manifest and one composed brief. Checkpointed execution retains the nine explicitly granted static tools and exact frozen wireframe descriptors. GitHub status cards can preserve only verified native PR/commit links for the current repository; the existing path, credential, image, mention and length guards remain active.

A native API configuration can bind finite maintenance communication to one exact server-owned creation receipt and checkpoint lineage. The configured issue can receive lifecycle and worker-question notices, and its mapped owner can answer through the existing native worker-response path. An answer does not resume execution, inherit a prior run's grants, reset a budget or launch another unit. Natural issue text does not create this maintenance binding or a new maintenance run. See SCM setup.

Checkpoint sou...

Read more

firefly forge v0.2.44

Choose a tag to compare

@github-actions github-actions released this 25 Oct 07:51
830289e

description: Review firefly forge release changes, runtime requirements and the verification boundaries of each published version.

firefly forge release notes

0.2.44

The version-3 checkpoint codec stores identical native history and request_history arrays once before compression. Decoding reconstructs the complete canonical record, checks the expanded size before allocating the mirrored record, and verifies its full SHA-256. Version-1 raw records and version-2 compressed records remain readable with their original encoded identities. Restored model requests must still reproduce exact wire bytes, usage, limits and file-tool state; consumed results and completed tools are never replayed.

Encoded-size refusals are distinct from digest refusals and do not expose record content. Capacity remains bounded: 192 KiB per encoded snapshot, 8 MiB per raw canonical record, 256 KiB per WAL envelope, and 4 MiB of per-run checkpoint/consume evidence. Deduplication improves capacity for mirrored history; it cannot make arbitrary input fit those limits. A content-addressed, chunked overflow path remains pending. This release does not claim unlimited or complete enterprise history storage.

The V13 profile has fresh native 250-case and SQL54/24/6 qualification on the measured protected source. The 22 loader inputs, 35 admission modules and 315 templates remain explicitly bound, with the prior eight profile literals and seals preserved. High-entropy, six-turn SDK tests cover exact next-request restoration, cumulative usage and one-use consumption; current credential and authority guards remain in force. These proofs do not establish completion of a generated CRM or a live product journey.

Backend 0.2.44 intentionally ships the unchanged Studio 0.2.42 source, compiled assets and captures. No UI refresh, new screenshot qualification or relabeled images is claimed. See checkpoint recovery for the remaining restoration and capacity boundaries.

0.2.43

Command slots now come from a durable, atomic run/task/attempt cursor. Fresh service instances allocate a new invocation; an explicit ordinal retains exact replay semantics. Pending, unknown, interrupted or unowned effects hold further dispatch. Command-enabled graph restoration accepts canonical, fully completed durable v2 records only, checks their position before the selected checkpoint or after the matching consume, and preserves lifetime command and browser budgets.

Accumulated native history uses a lossless, versioned canonical zlib/base64 envelope above 64 KiB. The raw record is limited to 8 MiB, the encoded snapshot to 192 KiB, and the complete WAL envelope and reserve to 256 KiB. Bounded decoding verifies the raw size and hash, canonical encoding, complete stream and absence of trailing data. Capture, consume, restore and generic journal reads scan the full decoded record against current credentials. A restored request retains its original encoded bytes and must match native history, usage, limits, state and wire identity. Unknown or consumed results are never re-armed.

Complete branding assets are staged through ordinary workspace tools while the model receives their compact path/hash manifest and one composed brief. Checkpointed execution retains the nine explicitly granted static tools and exact frozen wireframe descriptors. GitHub status cards can preserve only verified native PR/commit links for the current repository; the existing path, credential, image, mention and length guards remain active.

A native API configuration can bind finite maintenance communication to one exact server-owned creation receipt and checkpoint lineage. The configured issue can receive lifecycle and worker-question notices, and its mapped owner can answer through the existing native worker-response path. An answer does not resume execution, inherit a prior run's grants, reset a budget or launch another unit. Natural issue text does not create this maintenance binding or a new maintenance run. See SCM setup.

Checkpoint source identity streams tracked Git files, including ignored tracked assets, and nonignored untracked files through the current credential scanner. It binds source bytes, index, HEAD and the selected namespace without loading dependency trees into a TAR archive. Ignored generated output is outside this source fingerprint; it is not evidence of dependency integrity or successful installation. Docker and pool archive transport retain their independent byte limits, link rejection and publication checks.

Source listing and search return explicit complete/continuation pages bound to the source view, scope and query. Internal manifests hash every eligible file completely, including binary and large files. Search scans complete UTF-8 source with bounded excerpts and explicit binary/invalid-UTF-8 classification. The exhaustive Python inventory remains available; response windows do not silently drop the rest of a repository.

The V12 source profile binds an explicit 35-module admission closure and 22 loader inputs. It requires fresh same-source controlled native tool-boundary and PostgreSQL measurements, including the source-identity and paging cases. All seven historical profile literals and seals remain unchanged. Standard distribution payload checks, controlled transport tests and these qualifications remain separate from live model quality, completed generated-product delivery and GitHub acceptance. Backend 0.2.43 keeps the unchanged Studio 0.2.42 bundle and controlled captures; no screenshot version is relabeled.

0.2.42

An explicitly reviewed remote-completion request can confirm a saved local checkpoint after an uncertain push or draft-review outcome. It retains the original unknown request, exact AI-written review text and local checkpoint; a new finite consent grants remote completion only. The execution owner checks current authority, source, credentials and the exact expected branch before any write. A newly confirmed receipt records recovery provenance rather than claiming the original write succeeded. A later unmatched intent remains visible as uncertain even when an earlier draft was confirmed.

Final checkpoint cleanliness uses the same generated-path exclusions as source staging and rechecks them afterward. Natural status reads verified checkpoint and remote facts and refreshes them when execution state changes during the provider response or final lock wait. These observations grant no execution or additional budget.

On Darwin, diff cleanup distinguishes an exited, unreaped owned child from a live process whose signal was denied. A bounded reap is accepted only after the process group is proven absent; genuine denial and surviving groups remain errors. The separately qualified v9 source-only profile pairs fresh native tool-boundary evidence with same-source SQL budget and lease measurements. Its admitted lifetime read-file limit is 20 and canonical activation ceiling is 6; shared tool, command and final-check limits remain unchanged. Historical v8 evidence remains unchanged. These controlled proofs do not establish completed CRM delivery or general live-provider acceptance.

0.2.41

Large source changes use private chunked artifacts, hash-backed file indexes and bounded content pages. Project storage and time budgets are separate from response and preview sizes. Studio, the API, the typed Python SDK, the operator CLI and read-only MCP tools can inspect the exact retained run or checkpoint diff. See Inspect large source changes for configuration, integrity checks and remaining whole-repository scaling boundaries.

A natural GitHub checkpoint request can review current source, including untracked files, without requiring an automatic pause checkpoint. The read-only candidate preserves the index and HEAD. The native execution owner later checks that exact source and current permissions before saving a commit. A failed legacy unit has a separate one-use administrator adoption flow that retains its failed status and marks its checkpoint as unverified partial work. These operations do not add coding budget or declare QA complete.

A separately authorized test or maintain run can select an exact saved checkpoint while preserving its original repository, project and component. Both require publication to be disabled, a fresh native creation request and a confirmed remote receipt. Admission observes the branch reference without fetching the repository; execution checks the selected commit and tree after cloning. Maintain mode is included in the resolved source digest and starts an ordinary work unit with current configuration, its own session and counters. The original failed run, spent budgets, questions and grants remain unchanged. Existing test-source digests retain their default representation. Selection is refused if the checkpoint branch has advanced; read-only issue lineage grants no answer, resume or new launch authority.

Automatic worker verification prepares source identity through a streamed catalog outside database writer units. Hashing and sorting run off the runtime loop, with current-authority callbacks and cancellation cleanup. Command and subsequent provider admissions retain that source cut under exclusive workspace ownership. Explicit adoption, review archives and other transports retain separate scaling boundaries.

Provider activity present...

Read more

firefly forge v0.2.43

Choose a tag to compare

@github-actions github-actions released this 25 Oct 05:59
b0f09d5

description: Review firefly forge release changes, runtime requirements and the verification boundaries of each published version.

firefly forge release notes

0.2.43

Command slots now come from a durable, atomic run/task/attempt cursor. Fresh service instances allocate a new invocation; an explicit ordinal retains exact replay semantics. Pending, unknown, interrupted or unowned effects hold further dispatch. Command-enabled graph restoration accepts canonical, fully completed durable v2 records only, checks their position before the selected checkpoint or after the matching consume, and preserves lifetime command and browser budgets.

Accumulated native history uses a lossless, versioned canonical zlib/base64 envelope above 64 KiB. The raw record is limited to 8 MiB, the encoded snapshot to 192 KiB, and the complete WAL envelope and reserve to 256 KiB. Bounded decoding verifies the raw size and hash, canonical encoding, complete stream and absence of trailing data. Capture, consume, restore and generic journal reads scan the full decoded record against current credentials. A restored request retains its original encoded bytes and must match native history, usage, limits, state and wire identity. Unknown or consumed results are never re-armed.

Complete branding assets are staged through ordinary workspace tools while the model receives their compact path/hash manifest and one composed brief. Checkpointed execution retains the nine explicitly granted static tools and exact frozen wireframe descriptors. GitHub status cards can preserve only verified native PR/commit links for the current repository; the existing path, credential, image, mention and length guards remain active.

A native API configuration can bind finite maintenance communication to one exact server-owned creation receipt and checkpoint lineage. The configured issue can receive lifecycle and worker-question notices, and its mapped owner can answer through the existing native worker-response path. An answer does not resume execution, inherit a prior run's grants, reset a budget or launch another unit. Natural issue text does not create this maintenance binding or a new maintenance run. See SCM setup.

Checkpoint source identity streams tracked Git files, including ignored tracked assets, and nonignored untracked files through the current credential scanner. It binds source bytes, index, HEAD and the selected namespace without loading dependency trees into a TAR archive. Ignored generated output is outside this source fingerprint; it is not evidence of dependency integrity or successful installation. Docker and pool archive transport retain their independent byte limits, link rejection and publication checks.

Source listing and search return explicit complete/continuation pages bound to the source view, scope and query. Internal manifests hash every eligible file completely, including binary and large files. Search scans complete UTF-8 source with bounded excerpts and explicit binary/invalid-UTF-8 classification. The exhaustive Python inventory remains available; response windows do not silently drop the rest of a repository.

The V12 source profile binds an explicit 35-module admission closure and 22 loader inputs. It requires fresh same-source controlled native tool-boundary and PostgreSQL measurements, including the source-identity and paging cases. All seven historical profile literals and seals remain unchanged. Standard distribution payload checks, controlled transport tests and these qualifications remain separate from live model quality, completed generated-product delivery and GitHub acceptance. Backend 0.2.43 keeps the unchanged Studio 0.2.42 bundle and controlled captures; no screenshot version is relabeled.

0.2.42

An explicitly reviewed remote-completion request can confirm a saved local checkpoint after an uncertain push or draft-review outcome. It retains the original unknown request, exact AI-written review text and local checkpoint; a new finite consent grants remote completion only. The execution owner checks current authority, source, credentials and the exact expected branch before any write. A newly confirmed receipt records recovery provenance rather than claiming the original write succeeded. A later unmatched intent remains visible as uncertain even when an earlier draft was confirmed.

Final checkpoint cleanliness uses the same generated-path exclusions as source staging and rechecks them afterward. Natural status reads verified checkpoint and remote facts and refreshes them when execution state changes during the provider response or final lock wait. These observations grant no execution or additional budget.

On Darwin, diff cleanup distinguishes an exited, unreaped owned child from a live process whose signal was denied. A bounded reap is accepted only after the process group is proven absent; genuine denial and surviving groups remain errors. The separately qualified v9 source-only profile pairs fresh native tool-boundary evidence with same-source SQL budget and lease measurements. Its admitted lifetime read-file limit is 20 and canonical activation ceiling is 6; shared tool, command and final-check limits remain unchanged. Historical v8 evidence remains unchanged. These controlled proofs do not establish completed CRM delivery or general live-provider acceptance.

0.2.41

Large source changes use private chunked artifacts, hash-backed file indexes and bounded content pages. Project storage and time budgets are separate from response and preview sizes. Studio, the API, the typed Python SDK, the operator CLI and read-only MCP tools can inspect the exact retained run or checkpoint diff. See Inspect large source changes for configuration, integrity checks and remaining whole-repository scaling boundaries.

A natural GitHub checkpoint request can review current source, including untracked files, without requiring an automatic pause checkpoint. The read-only candidate preserves the index and HEAD. The native execution owner later checks that exact source and current permissions before saving a commit. A failed legacy unit has a separate one-use administrator adoption flow that retains its failed status and marks its checkpoint as unverified partial work. These operations do not add coding budget or declare QA complete.

A separately authorized test or maintain run can select an exact saved checkpoint while preserving its original repository, project and component. Both require publication to be disabled, a fresh native creation request and a confirmed remote receipt. Admission observes the branch reference without fetching the repository; execution checks the selected commit and tree after cloning. Maintain mode is included in the resolved source digest and starts an ordinary work unit with current configuration, its own session and counters. The original failed run, spent budgets, questions and grants remain unchanged. Existing test-source digests retain their default representation. Selection is refused if the checkpoint branch has advanced; read-only issue lineage grants no answer, resume or new launch authority.

Automatic worker verification prepares source identity through a streamed catalog outside database writer units. Hashing and sorting run off the runtime loop, with current-authority callbacks and cancellation cleanup. Command and subsequent provider admissions retain that source cut under exclusive workspace ownership. Explicit adoption, review archives and other transports retain separate scaling boundaries.

Provider activity presents completed native summaries and usage as readable records, with retained structured details available for inspection. The updated walkthrough uses controlled desktop/mobile light/dark fixtures. Native budget readmission accepts the exact currently qualified parent seal or strict older profile provenance; fresh dependency closure and v8 measurements remain required before adoption, and spent counters and prior grants remain unchanged. Host and visual checks do not establish completed CRM delivery or a live remote draft review.

0.2.40

Projects can configure development checkpoints for completed implementation rounds and safe worker pauses. A run records its schedule and original Git baseline; each checkpoint extends its last confirmed factory commit. GitHub and GitLab adapters can update one retained draft review, then mark that same review ready after final verification and approval. Remote updates compare the exact expected branch revision and preserve fast-forward ancestry. Changed review identity and unknown outcomes stop further writes. Checkpoints remain disabled until configured, and disabling the project policy stops further checkpoints for existing runs without removing saved commits.

Studio adds a workflow form and saved-progress history, with complete commit and source-tree identifiers on desktop and mobile. Six API, SDK, CLI and MCP operations expose configuration, checkpoint requests, receipts and read-only observation under current project permissions. The development workflow guide illustrates the portal with controlled fixtures and explains what a draft checkpoint establishes.

Implementation handoffs now read bounded, authenticated question-and-answer history rather than only the latest answer. Historical diagnostics remain labeled and confer no authorit...

Read more

firefly forge v0.2.42

Choose a tag to compare

@github-actions github-actions released this 24 Oct 22:35
a65f719

description: Review firefly forge release changes, runtime requirements and the verification boundaries of each published version.

firefly forge release notes

0.2.42

An explicitly reviewed remote-completion request can confirm a saved local checkpoint after an uncertain push or draft-review outcome. It retains the original unknown request, exact AI-written review text and local checkpoint; a new finite consent grants remote completion only. The execution owner checks current authority, source, credentials and the exact expected branch before any write. A newly confirmed receipt records recovery provenance rather than claiming the original write succeeded. A later unmatched intent remains visible as uncertain even when an earlier draft was confirmed.

Final checkpoint cleanliness uses the same generated-path exclusions as source staging and rechecks them afterward. Natural status reads verified checkpoint and remote facts and refreshes them when execution state changes during the provider response or final lock wait. These observations grant no execution or additional budget.

On Darwin, diff cleanup distinguishes an exited, unreaped owned child from a live process whose signal was denied. A bounded reap is accepted only after the process group is proven absent; genuine denial and surviving groups remain errors. The separately qualified v9 source-only profile pairs fresh native tool-boundary evidence with same-source SQL budget and lease measurements. Its admitted lifetime read-file limit is 20 and canonical activation ceiling is 6; shared tool, command and final-check limits remain unchanged. Historical v8 evidence remains unchanged. These controlled proofs do not establish completed CRM delivery or general live-provider acceptance.

0.2.41

Large source changes use private chunked artifacts, hash-backed file indexes and bounded content pages. Project storage and time budgets are separate from response and preview sizes. Studio, the API, the typed Python SDK, the operator CLI and read-only MCP tools can inspect the exact retained run or checkpoint diff. See Inspect large source changes for configuration, integrity checks and remaining whole-repository scaling boundaries.

A natural GitHub checkpoint request can review current source, including untracked files, without requiring an automatic pause checkpoint. The read-only candidate preserves the index and HEAD. The native execution owner later checks that exact source and current permissions before saving a commit. A failed legacy unit has a separate one-use administrator adoption flow that retains its failed status and marks its checkpoint as unverified partial work. These operations do not add coding budget or declare QA complete.

A separately authorized test or maintain run can select an exact saved checkpoint while preserving its original repository, project and component. Both require publication to be disabled, a fresh native creation request and a confirmed remote receipt. Admission observes the branch reference without fetching the repository; execution checks the selected commit and tree after cloning. Maintain mode is included in the resolved source digest and starts an ordinary work unit with current configuration, its own session and counters. The original failed run, spent budgets, questions and grants remain unchanged. Existing test-source digests retain their default representation. Selection is refused if the checkpoint branch has advanced; read-only issue lineage grants no answer, resume or new launch authority.

Automatic worker verification prepares source identity through a streamed catalog outside database writer units. Hashing and sorting run off the runtime loop, with current-authority callbacks and cancellation cleanup. Command and subsequent provider admissions retain that source cut under exclusive workspace ownership. Explicit adoption, review archives and other transports retain separate scaling boundaries.

Provider activity presents completed native summaries and usage as readable records, with retained structured details available for inspection. The updated walkthrough uses controlled desktop/mobile light/dark fixtures. Native budget readmission accepts the exact currently qualified parent seal or strict older profile provenance; fresh dependency closure and v8 measurements remain required before adoption, and spent counters and prior grants remain unchanged. Host and visual checks do not establish completed CRM delivery or a live remote draft review.

0.2.40

Projects can configure development checkpoints for completed implementation rounds and safe worker pauses. A run records its schedule and original Git baseline; each checkpoint extends its last confirmed factory commit. GitHub and GitLab adapters can update one retained draft review, then mark that same review ready after final verification and approval. Remote updates compare the exact expected branch revision and preserve fast-forward ancestry. Changed review identity and unknown outcomes stop further writes. Checkpoints remain disabled until configured, and disabling the project policy stops further checkpoints for existing runs without removing saved commits.

Studio adds a workflow form and saved-progress history, with complete commit and source-tree identifiers on desktop and mobile. Six API, SDK, CLI and MCP operations expose configuration, checkpoint requests, receipts and read-only observation under current project permissions. The development workflow guide illustrates the portal with controlled fixtures and explains what a draft checkpoint establishes.

Implementation handoffs now read bounded, authenticated question-and-answer history rather than only the latest answer. Historical diagnostics remain labeled and confer no authority. The report schema also expresses the existing requirement that a blocked or clarification response include a typed question; invalid reports retain a fixed error without echoing their contents. GitHub polling projects a bounded candidate descriptor before credential admission, keeping full conversation content in its original inbox records.

An explicit known-completed-output review can admit the next finite source-only activation after a completed native turn returned an invalid implementation report. It binds the retained dispatch, output, tool history, unchanged Git index and freshly reviewed source. It does not fabricate a question, treat output as successful implementation, reset budgets or replay the failed dispatch. This path requires its separately measured v7 native profile; historical profiles remain unchanged. See source-budget recovery.

Controlled host, browser and native qualification have separate evidence boundaries. These features do not establish completed CRM delivery, live remote draft acceptance or a successful external deployment.

0.2.39

A paused source-only task can continue through separately reviewed human-answer or completed-output admission. The review retains the original run, source, command budget and uncertain effects; it does not replay an old request. Completed-output observation binds the retained stdout descriptors and accepts only the exact pinned pre-turn CLI notice. It does not infer process exit or implementation success from a completed turn.

Pending native worker questions now have their own durable publication outbox. The factory checks current issue, identity, repository and polling authority before the configured AI writer and before posting. Confirmed publications support ordinary human replies in the same issue, including after the original source grant expires. Saving an answer grants no execution or additional budget. Renewing the same account's read consent preserves a confirmed question's exact historical proof; current scope, identity and respond permission are still required. Unknown remote outcomes remain held; a definite local refusal before dispatch can retain the same draft for a later authorized attempt.

An administrator can review an explicit finite source-read allowance through the API, SDK or CLI. The measured v6 Codex 0.163 Darwin arm64 profile supports a lifetime read-file limit of 20 and canonical activation ceiling of 5 for that separately admitted continuation. Existing tool rows and spent counters remain intact, the shared tool ceiling stays 30, and the original command allowance and final verification checks remain unchanged. Ordinary source limits remain 10 reads and four activations. Final allowance writes use the physical execution-lease connection and roll back when ownership is lost before commit.

Natural question selection supports grounded cross-language answers using the exact offered question and human spans. GitHub App reads and feedback share bounded, persistent provider cooldowns. A known local no-dispatch hold retains one intent and draft across restart; an uncertain dispatched write still requires reconciliation.

The prompt catalog adds a versioned source-continuation resource while preserving existing resource bytes. Historical v5 profile evidence remains immutable alongside the new profile. Studio keeps the published 0.2.38 interface and refreshes its controlled walkthrough for the 0.2.39 stamp. Controlled native transport and PostgreSQL evidence cover their stated boundaries; actual model behavior, completed CRM delivery and generated-product acceptance remain separate.

0.2.38

...

Read more

firefly forge v0.2.41

Choose a tag to compare

@github-actions github-actions released this 24 Oct 18:08
c32ffec

description: Review firefly forge release changes, runtime requirements and the verification boundaries of each published version.

firefly forge release notes

0.2.41

Large source changes use private chunked artifacts, hash-backed file indexes and bounded content pages. Project storage and time budgets are separate from response and preview sizes. Studio, the API, the typed Python SDK, the operator CLI and read-only MCP tools can inspect the exact retained run or checkpoint diff. See Inspect large source changes for configuration, integrity checks and remaining whole-repository scaling boundaries.

A natural GitHub checkpoint request can review current source, including untracked files, without requiring an automatic pause checkpoint. The read-only candidate preserves the index and HEAD. The native execution owner later checks that exact source and current permissions before saving a commit. A failed legacy unit has a separate one-use administrator adoption flow that retains its failed status and marks its checkpoint as unverified partial work. These operations do not add coding budget or declare QA complete.

A separately authorized test or maintain run can select an exact saved checkpoint while preserving its original repository, project and component. Both require publication to be disabled, a fresh native creation request and a confirmed remote receipt. Admission observes the branch reference without fetching the repository; execution checks the selected commit and tree after cloning. Maintain mode is included in the resolved source digest and starts an ordinary work unit with current configuration, its own session and counters. The original failed run, spent budgets, questions and grants remain unchanged. Existing test-source digests retain their default representation. Selection is refused if the checkpoint branch has advanced; read-only issue lineage grants no answer, resume or new launch authority.

Automatic worker verification prepares source identity through a streamed catalog outside database writer units. Hashing and sorting run off the runtime loop, with current-authority callbacks and cancellation cleanup. Command and subsequent provider admissions retain that source cut under exclusive workspace ownership. Explicit adoption, review archives and other transports retain separate scaling boundaries.

Provider activity presents completed native summaries and usage as readable records, with retained structured details available for inspection. The updated walkthrough uses controlled desktop/mobile light/dark fixtures. Native budget readmission accepts the exact currently qualified parent seal or strict older profile provenance; fresh dependency closure and v8 measurements remain required before adoption, and spent counters and prior grants remain unchanged. Host and visual checks do not establish completed CRM delivery or a live remote draft review.

0.2.40

Projects can configure development checkpoints for completed implementation rounds and safe worker pauses. A run records its schedule and original Git baseline; each checkpoint extends its last confirmed factory commit. GitHub and GitLab adapters can update one retained draft review, then mark that same review ready after final verification and approval. Remote updates compare the exact expected branch revision and preserve fast-forward ancestry. Changed review identity and unknown outcomes stop further writes. Checkpoints remain disabled until configured, and disabling the project policy stops further checkpoints for existing runs without removing saved commits.

Studio adds a workflow form and saved-progress history, with complete commit and source-tree identifiers on desktop and mobile. Six API, SDK, CLI and MCP operations expose configuration, checkpoint requests, receipts and read-only observation under current project permissions. The development workflow guide illustrates the portal with controlled fixtures and explains what a draft checkpoint establishes.

Implementation handoffs now read bounded, authenticated question-and-answer history rather than only the latest answer. Historical diagnostics remain labeled and confer no authority. The report schema also expresses the existing requirement that a blocked or clarification response include a typed question; invalid reports retain a fixed error without echoing their contents. GitHub polling projects a bounded candidate descriptor before credential admission, keeping full conversation content in its original inbox records.

An explicit known-completed-output review can admit the next finite source-only activation after a completed native turn returned an invalid implementation report. It binds the retained dispatch, output, tool history, unchanged Git index and freshly reviewed source. It does not fabricate a question, treat output as successful implementation, reset budgets or replay the failed dispatch. This path requires its separately measured v7 native profile; historical profiles remain unchanged. See source-budget recovery.

Controlled host, browser and native qualification have separate evidence boundaries. These features do not establish completed CRM delivery, live remote draft acceptance or a successful external deployment.

0.2.39

A paused source-only task can continue through separately reviewed human-answer or completed-output admission. The review retains the original run, source, command budget and uncertain effects; it does not replay an old request. Completed-output observation binds the retained stdout descriptors and accepts only the exact pinned pre-turn CLI notice. It does not infer process exit or implementation success from a completed turn.

Pending native worker questions now have their own durable publication outbox. The factory checks current issue, identity, repository and polling authority before the configured AI writer and before posting. Confirmed publications support ordinary human replies in the same issue, including after the original source grant expires. Saving an answer grants no execution or additional budget. Renewing the same account's read consent preserves a confirmed question's exact historical proof; current scope, identity and respond permission are still required. Unknown remote outcomes remain held; a definite local refusal before dispatch can retain the same draft for a later authorized attempt.

An administrator can review an explicit finite source-read allowance through the API, SDK or CLI. The measured v6 Codex 0.163 Darwin arm64 profile supports a lifetime read-file limit of 20 and canonical activation ceiling of 5 for that separately admitted continuation. Existing tool rows and spent counters remain intact, the shared tool ceiling stays 30, and the original command allowance and final verification checks remain unchanged. Ordinary source limits remain 10 reads and four activations. Final allowance writes use the physical execution-lease connection and roll back when ownership is lost before commit.

Natural question selection supports grounded cross-language answers using the exact offered question and human spans. GitHub App reads and feedback share bounded, persistent provider cooldowns. A known local no-dispatch hold retains one intent and draft across restart; an uncertain dispatched write still requires reconciliation.

The prompt catalog adds a versioned source-continuation resource while preserving existing resource bytes. Historical v5 profile evidence remains immutable alongside the new profile. Studio keeps the published 0.2.38 interface and refreshes its controlled walkthrough for the 0.2.39 stamp. Controlled native transport and PostgreSQL evidence cover their stated boundaries; actual model behavior, completed CRM delivery and generated-product acceptance remain separate.

0.2.38

Natural replies to a confirmed pending worker question no longer load unrelated provider and tool output from the whole execution journal. The lookup selects the exact run and question ancestry, enforcing its row and byte limits in one SQL statement snapshot before returning payloads. A large retained diagnostic history therefore cannot hide a small current question; changed or ambiguous question evidence still refuses answer application.

The source-control guide starts with ordinary issue conversation and replies without copied command identifiers. Typed commands remain available as an advanced compatibility path. Tool documentation distinguishes the conditional native registry from ordinary CLI permissions and the separately qualified source-only profile. This release does not introduce owner-note delivery, repeated restricted source readmission or a new model allowance.

0.2.37

GitHub conversations accept ordinary language for product requests, status and answers. A reply to a confirmed pending question can omit the mention when its issue, author and question binding are unambiguous. The factory retains the original text and question provenance across restarts. Ambiguous references ask for clarification rather than guessing a run or requiring a command. See the conversation guide.

Conversation authority does not authorize execution. A late answer remains available after execution consent expires; continuing the original ProductAssistant session or worker task requires fresh bounded native authori...

Read more

firefly forge v0.2.40

Choose a tag to compare

@github-actions github-actions released this 24 Oct 01:34
c1df888

description: Review firefly forge release changes, runtime requirements and the verification boundaries of each published version.

firefly forge release notes

0.2.40

Projects can configure development checkpoints for completed implementation rounds and safe worker pauses. A run records its schedule and original Git baseline; each checkpoint extends its last confirmed factory commit. GitHub and GitLab adapters can update one retained draft review, then mark that same review ready after final verification and approval. Remote updates compare the exact expected branch revision and preserve fast-forward ancestry. Changed review identity and unknown outcomes stop further writes. Checkpoints remain disabled until configured, and disabling the project policy stops further checkpoints for existing runs without removing saved commits.

Studio adds a workflow form and saved-progress history, with complete commit and source-tree identifiers on desktop and mobile. Six API, SDK, CLI and MCP operations expose configuration, checkpoint requests, receipts and read-only observation under current project permissions. The development workflow guide illustrates the portal with controlled fixtures and explains what a draft checkpoint establishes.

Implementation handoffs now read bounded, authenticated question-and-answer history rather than only the latest answer. Historical diagnostics remain labeled and confer no authority. The report schema also expresses the existing requirement that a blocked or clarification response include a typed question; invalid reports retain a fixed error without echoing their contents. GitHub polling projects a bounded candidate descriptor before credential admission, keeping full conversation content in its original inbox records.

An explicit known-completed-output review can admit the next finite source-only activation after a completed native turn returned an invalid implementation report. It binds the retained dispatch, output, tool history, unchanged Git index and freshly reviewed source. It does not fabricate a question, treat output as successful implementation, reset budgets or replay the failed dispatch. This path requires its separately measured v7 native profile; historical profiles remain unchanged. See source-budget recovery.

Controlled host, browser and native qualification have separate evidence boundaries. These features do not establish completed CRM delivery, live remote draft acceptance or a successful external deployment.

0.2.39

A paused source-only task can continue through separately reviewed human-answer or completed-output admission. The review retains the original run, source, command budget and uncertain effects; it does not replay an old request. Completed-output observation binds the retained stdout descriptors and accepts only the exact pinned pre-turn CLI notice. It does not infer process exit or implementation success from a completed turn.

Pending native worker questions now have their own durable publication outbox. The factory checks current issue, identity, repository and polling authority before the configured AI writer and before posting. Confirmed publications support ordinary human replies in the same issue, including after the original source grant expires. Saving an answer grants no execution or additional budget. Renewing the same account's read consent preserves a confirmed question's exact historical proof; current scope, identity and respond permission are still required. Unknown remote outcomes remain held; a definite local refusal before dispatch can retain the same draft for a later authorized attempt.

An administrator can review an explicit finite source-read allowance through the API, SDK or CLI. The measured v6 Codex 0.163 Darwin arm64 profile supports a lifetime read-file limit of 20 and canonical activation ceiling of 5 for that separately admitted continuation. Existing tool rows and spent counters remain intact, the shared tool ceiling stays 30, and the original command allowance and final verification checks remain unchanged. Ordinary source limits remain 10 reads and four activations. Final allowance writes use the physical execution-lease connection and roll back when ownership is lost before commit.

Natural question selection supports grounded cross-language answers using the exact offered question and human spans. GitHub App reads and feedback share bounded, persistent provider cooldowns. A known local no-dispatch hold retains one intent and draft across restart; an uncertain dispatched write still requires reconciliation.

The prompt catalog adds a versioned source-continuation resource while preserving existing resource bytes. Historical v5 profile evidence remains immutable alongside the new profile. Studio keeps the published 0.2.38 interface and refreshes its controlled walkthrough for the 0.2.39 stamp. Controlled native transport and PostgreSQL evidence cover their stated boundaries; actual model behavior, completed CRM delivery and generated-product acceptance remain separate.

0.2.38

Natural replies to a confirmed pending worker question no longer load unrelated provider and tool output from the whole execution journal. The lookup selects the exact run and question ancestry, enforcing its row and byte limits in one SQL statement snapshot before returning payloads. A large retained diagnostic history therefore cannot hide a small current question; changed or ambiguous question evidence still refuses answer application.

The source-control guide starts with ordinary issue conversation and replies without copied command identifiers. Typed commands remain available as an advanced compatibility path. Tool documentation distinguishes the conditional native registry from ordinary CLI permissions and the separately qualified source-only profile. This release does not introduce owner-note delivery, repeated restricted source readmission or a new model allowance.

0.2.37

GitHub conversations accept ordinary language for product requests, status and answers. A reply to a confirmed pending question can omit the mention when its issue, author and question binding are unambiguous. The factory retains the original text and question provenance across restarts. Ambiguous references ask for clarification rather than guessing a run or requiring a command. See the conversation guide.

Conversation authority does not authorize execution. A late answer remains available after execution consent expires; continuing the original ProductAssistant session or worker task requires fresh bounded native authority for that exact context. Product requests use the existing functional assistant, knowledge and configured task route. Proposals remain unreviewed. The selected Agentic or Bridge communication route uses Humanizer instructions, with one correction for a confirmed invalid response and no automatic replay of an unknown provider outcome.

The package includes a measured source-only Codex 0.163 Darwin arm64 capability profile. Its tool, loader, runtime and filesystem evidence is specific to that profile. MCP resources accept bounded standard progress metadata and return correlated errors without broadening tool arguments or resource access. Source reconciliation preserves the original intent and spent command budget; an explicitly reviewed generated index entry can be sanitized without discarding source changes. See the recovery guide.

Studio makes retained worker questions, recorded answers and continuation state visible with responsive evidence. The complete controlled walkthrough is regenerated for version 0.2.37. Host, browser, native PostgreSQL and finite no-model protocol proofs cover their stated boundaries; actual CRM completion, external model behavior and generated-product acceptance remain separate.

Known limitations: a restricted source-only grant admits one implementation attempt. A saved human answer does not grant the next attempt; dedicated human/source readmission is being implemented in a separate successor. The generic native conversation proofs do not establish that restricted resume. Retained verification context can also be clipped and omit the root error; scoped retained-diagnostics retrieval is being corrected separately. Preserve the paused request and its evidence while these boundaries remain held.

0.2.36

A GitHub issue can host a separately authorized functional conversation. A native administrator reviews the exact API-observed account, project, repository, issue and named assistant profile, then records a finite allowance. Start and status do not invoke a model; each turn reserves one of at most three assistant model turns before entering the product provider. The same issue-bound conversation can receive a natural message addressed to @forge. Unknown outcomes retain their original request and allowance instead of triggering an automatic retry. See the functional GitHub dialogue guide.

Grant review reports the mapped native user's readiness for each action. Status requires an enabled account with current project read membership; start and turn require edit membership. The administrator's own role does not grant the mapped person those permissions. Active consent is refused before a grant or allowance ledger is written when the membership is insufficient, and admission checks it again under the existing native transaction locks.

Feedback u...

Read more

firefly forge v0.2.39

Choose a tag to compare

@github-actions github-actions released this 23 Oct 20:23
60e845f

description: Review firefly forge release changes, runtime requirements and the verification boundaries of each published version.

firefly forge release notes

0.2.39

A paused source-only task can continue through separately reviewed human-answer or completed-output admission. The review retains the original run, source, command budget and uncertain effects; it does not replay an old request. Completed-output observation binds the retained stdout descriptors and accepts only the exact pinned pre-turn CLI notice. It does not infer process exit or implementation success from a completed turn.

Pending native worker questions now have their own durable publication outbox. The factory checks current issue, identity, repository and polling authority before the configured AI writer and before posting. Confirmed publications support ordinary human replies in the same issue, including after the original source grant expires. Saving an answer grants no execution or additional budget. Renewing the same account's read consent preserves a confirmed question's exact historical proof; current scope, identity and respond permission are still required. Unknown remote outcomes remain held; a definite local refusal before dispatch can retain the same draft for a later authorized attempt.

An administrator can review an explicit finite source-read allowance through the API, SDK or CLI. The measured v6 Codex 0.163 Darwin arm64 profile supports a lifetime read-file limit of 20 and canonical activation ceiling of 5 for that separately admitted continuation. Existing tool rows and spent counters remain intact, the shared tool ceiling stays 30, and the original command allowance and final verification checks remain unchanged. Ordinary source limits remain 10 reads and four activations. Final allowance writes use the physical execution-lease connection and roll back when ownership is lost before commit.

Natural question selection supports grounded cross-language answers using the exact offered question and human spans. GitHub App reads and feedback share bounded, persistent provider cooldowns. A known local no-dispatch hold retains one intent and draft across restart; an uncertain dispatched write still requires reconciliation.

The prompt catalog adds a versioned source-continuation resource while preserving existing resource bytes. Historical v5 profile evidence remains immutable alongside the new profile. Studio keeps the published 0.2.38 interface and refreshes its controlled walkthrough for the 0.2.39 stamp. Controlled native transport and PostgreSQL evidence cover their stated boundaries; actual model behavior, completed CRM delivery and generated-product acceptance remain separate.

0.2.38

Natural replies to a confirmed pending worker question no longer load unrelated provider and tool output from the whole execution journal. The lookup selects the exact run and question ancestry, enforcing its row and byte limits in one SQL statement snapshot before returning payloads. A large retained diagnostic history therefore cannot hide a small current question; changed or ambiguous question evidence still refuses answer application.

The source-control guide starts with ordinary issue conversation and replies without copied command identifiers. Typed commands remain available as an advanced compatibility path. Tool documentation distinguishes the conditional native registry from ordinary CLI permissions and the separately qualified source-only profile. This release does not introduce owner-note delivery, repeated restricted source readmission or a new model allowance.

0.2.37

GitHub conversations accept ordinary language for product requests, status and answers. A reply to a confirmed pending question can omit the mention when its issue, author and question binding are unambiguous. The factory retains the original text and question provenance across restarts. Ambiguous references ask for clarification rather than guessing a run or requiring a command. See the conversation guide.

Conversation authority does not authorize execution. A late answer remains available after execution consent expires; continuing the original ProductAssistant session or worker task requires fresh bounded native authority for that exact context. Product requests use the existing functional assistant, knowledge and configured task route. Proposals remain unreviewed. The selected Agentic or Bridge communication route uses Humanizer instructions, with one correction for a confirmed invalid response and no automatic replay of an unknown provider outcome.

The package includes a measured source-only Codex 0.163 Darwin arm64 capability profile. Its tool, loader, runtime and filesystem evidence is specific to that profile. MCP resources accept bounded standard progress metadata and return correlated errors without broadening tool arguments or resource access. Source reconciliation preserves the original intent and spent command budget; an explicitly reviewed generated index entry can be sanitized without discarding source changes. See the recovery guide.

Studio makes retained worker questions, recorded answers and continuation state visible with responsive evidence. The complete controlled walkthrough is regenerated for version 0.2.37. Host, browser, native PostgreSQL and finite no-model protocol proofs cover their stated boundaries; actual CRM completion, external model behavior and generated-product acceptance remain separate.

Known limitations: a restricted source-only grant admits one implementation attempt. A saved human answer does not grant the next attempt; dedicated human/source readmission is being implemented in a separate successor. The generic native conversation proofs do not establish that restricted resume. Retained verification context can also be clipped and omit the root error; scoped retained-diagnostics retrieval is being corrected separately. Preserve the paused request and its evidence while these boundaries remain held.

0.2.36

A GitHub issue can host a separately authorized functional conversation. A native administrator reviews the exact API-observed account, project, repository, issue and named assistant profile, then records a finite allowance. Start and status do not invoke a model; each turn reserves one of at most three assistant model turns before entering the product provider. The same issue-bound conversation can receive a natural message addressed to @forge. Unknown outcomes retain their original request and allowance instead of triggering an automatic retry. See the functional GitHub dialogue guide.

Grant review reports the mapped native user's readiness for each action. Status requires an enabled account with current project read membership; start and turn require edit membership. The administrator's own role does not grant the mapped person those permissions. Active consent is refused before a grant or allowance ledger is written when the membership is insufficient, and admission checks it again under the existing native transaction locks.

Feedback uses confirmed assistant facts rather than inventing an execution state. Status distinguishes the latest attempted turn from an earlier completed response, keeps the original reply and questions, and places turn references in a collapsed section. It retains the sanitized reply and questions, including slash-separated prose and line breaks, while keeping any proposed product definition unreviewed. A selected AI communication profile still uses the separate full-candidate classifier and one final correction within the existing three-request ceiling. Material failures hold the response without a substitute message. Changed outcomes, revoked authority and later operator decisions fence stale replies before publication.

Source-only activation has its own versioned command and native administrator consent. It binds the original issue, repository, run, task, source candidate, qualified native profile and SCM caller provenance. The administrator remains the sealed authority; the SCM caller retains its own identity. This route preserves the existing run and command budget, including the reserved final checks. It refuses activation when no matching native capability has been qualified. This release does not add a production native profile or establish completed native CLI isolation, live GitHub execution or generated-product acceptance.

GitHub polling accepts the provider's canonical numeric repository pagination path only when it matches the verified repository, API origin, resource and exact query. The existing page ceiling, cursor and immutable consent remain in force.

The prompt catalog contains 301 versioned resources and preserves all previous prompt bytes. Studio adds a functional-consent walkthrough and exact-receipt recovery guidance. The source also retains the published read-only patch-index fix and its ordinary and source-only regressions, plus the two-tab final-allowance reservation test. Controlled host, browser and PostgreSQL fixtures qualify the recorded transitions; actual provider and product acceptance remain separate.

0.2.35

Studio keeps your place on the production floor. Choose a project, switch to Board and select a manufacturing run; after Inspect or a visit to another page, returning to Factory restores those choices. The selection stays in memory for the current session. Switching the signed-in user or factory API, or disconnecting, resets it. A project or run that disappears from the accessible list no longer supplies the selected plan.

The Factory view ...

Read more