[tonytonycoder11]

Everything for 1.0.0 in one pull request: the review of the public API, the stability policy, the checks that found what the review could not, the media for what 0.2.0 added, and the release commit. Merging it tags and publishes nothing: the release workflow starts from a tag, and pushes to main only run CI.

The review (M25) read everything the four packages export. Every export now names what it makes public, which stops parseFormEncoded and prettyXml from leaking out with the body model, and FlutwireCallRecorder.observeRequest, which nothing called, is removed. FlutwireStore, MemoryFlutwireStore and FlutwirePreferences are base classes and FlutwireClient is final, so none of them can be implemented or extended outside the package and each can grow without breaking anyone. FlutwireBodyDecoder stays the one interface meant to be implemented. The HAR export names this package's version instead of 0. STABILITY.md says what all of that means. Compared with 0.2.0, dart_apitool lists those three removals for the core and nothing for the adapters. It does not see a change of class modifier, so the changelog lists those by hand.

The checks found things the review could not. The history on disk had no version, and a summary that could not be read was deleted, so an older release opening the history of a newer one would have wiped it (M40). The folder now records a layout number, a folder with none is read as the one 0.1.0 and 0.2.0 write, and a layout this release does not know is left exactly as it is while the history stays in memory. A fixture written by the 0.2.0 code is read back in a test. The Protobuf decoder had only been tested on input built by hand (M38). Run over a descriptor set and messages that protoc and its generated code wrote, it got a negative enum value and a float wrong, and both are fixed with tests that fail without the fixes. The new screens were run on an Android emulator, an iOS simulator, macOS and in a browser (M39). That turned up layout problems on narrow screens: the four numbers above the list ran into each other in a panel of 200 points, the title of a selection was cut, and the dock could be put to the right of a phone. All three are fixed, each with a test that fails without it. A smoke test in the example records a call through dart:io, opens the comparison and the statistics and docks the inspector, and passes on macOS and on an iOS simulator.

Two jobs are new (M41, M39). One compares each package with its latest release on pub.dev and fails when the API breaks and the pubspec has not moved to a version that allows it. The other builds the example for the web, which no job did.

The media (M37) is a second tour and a 74 second video in both READMEs, and four more screenshots on the pub.dev page of flutwire, which now shows ten.

The release commit moves the four packages to 1.0.0 together. The three adapters ask for flutwire ^1.0.0, flutwireVersion and the podspec follow, which version_test checks, the entries that were waiting under Unreleased are now under [1.0.0] - 2026-10-24, each package has its own changelog entry, and the README says what shipped, links the policy and names gRPC capture as what comes next.

Checked locally on this branch: format, analyze, the four suites (1137, 15, 12 and 19 tests), the four flutter pub publish --dry-runs with 0 warnings, the lowest versions of each package, the example for Android, the iOS simulator, macOS and the web, the API job's own script run with bash, which passes for all four packages, and the repository audit, which says "At standard".

What waits for after the merge: the tag v1.0.0 on the merge commit, which starts the release workflow, the board, where the items that target 1.0.0 go to Shipped and the Tier 3 milestone closes, the topics, which are re-ranked at each major release, and a new status update. The date in the changelog heading and in the anchors of the four package changelogs is the day this was written. If the tag goes out on another day, those five places change.

Targets 1.0.0, Tier 3, and the Maintenance item M37.

[trueup-by-nacode-studios]

This pull request adds no capability to production code. Test and benchmark code gains the ability to import a module chosen at runtime, touch the filesystem, in 3 places.

_{80 files read · 8522 ms · against b96d43b · engine 1.4.1}