Native Reader and compiler roadmap

The native Reader is for any application, service, tool, or game that needs to open and verify AmoosedWeb content. AmoosedWeb::NativeReader is the general CMake target; AmoosedWeb::GameReader remains a preview compatibility target. Its C++ CallbackHttpHost bounds and checks caller supplied HTTP responses before core verification. Preview C revision 16 can prepare a site with that transport, and a Windows plain-C fixture verifies generated-site content through it. The Windows Node-API bridge now routes npm's injected fetcher through this native boundary. Its clean installed Windows npm consumer now compares native injected-fetch metadata and bytes with the current Reader across all six carrier modes and external member content, and rejects a wrong key, altered media, and existing output. The same gate now checks that rejected fetches and HTTP failures surface as native network errors, while bad ranges and short bodies surface as verification errors. A changed final URL and malformed ETag also surface as native network errors. The Node callback path requests identity encoding and rejects compressed responses as network errors; direct C callbacks still need to supply the exact carrier bytes because the preview response struct has no content-encoding field. The Windows WinHTTP adapter independently rejects compressed range, full-body, and HEAD responses even when the server ignores its identity request. Wider transport failure and target-host parity remain open. The local Windows release build of amoosedweb-reader now uses this bridge by default through the same four public functions. It bundles the matching Node-API addon and C DLL, while Linux and macOS retain the JavaScript Reader. Its clean installed consumer reads every public demo resource and checks exact hashes and no overwrite. This source change has not been published to the npm registry. Game catalogue and experiment APIs are optional layers. An engine-specific Game SDK can be packaged separately once the general Reader is stable.

The first native release target is Windows x64. Complete the static-hosting compiler, Reader, language bindings, clean installed-consumer gates, and the 1.0 ABI freeze for that target before expanding release support. Existing Linux implementation and passing preview fixtures are retained, but a Windows release does not wait for Linux or imply Linux support. Adding Linux to a later release requires its own clean package and target-host evidence.

The local Windows x64 standalone compiler ZIP now uses a small C++ amw.exe dispatcher and packaged C++ commands instead of a Node single-executable application. It carries the shared help catalogue, runtime, templates, skills, Reader DLL, and required third-party notice, but no Node executable or C++ implementation source. node tools/check-native-compiler-zip.js extracts the archive into a clean directory and checks every command's help, a Unicode starter build, verified Pages packaging and backup, invitation links, and a local fake deployment handoff. It now also runs the same Windows media and preview-server interoperability fixtures used by installed npm/.NET packages, and checks hosted listing, download, member-key rejection, and full pull from the extracted ZIP. The ZIP is an owner-side release artifact; these local checks do not publish it or establish full command parity.

The local Windows x64 AmoosedWeb.Reader.NativeDefaultPreview NuGet review package now exposes the existing AmoosedReader method signatures with the revision-16 C library as the default backend. Its exact-version native binary dependency is installed through NuGet; it carries no embedded Node CLI or implementation source. Run node tools/check-dotnet-native-default-preview.js <folder-with-GameReader-Native-nupkg> to pack and install it into an isolated cache, read a locally hosted carrier site, compare exact output bytes, pull every indexed resource, and check that repeated downloads preserve existing files. The published AmoosedWeb.Reader now selects the C reader by default in the local Windows release build, and AmoosedWeb.Native copies its matching DLL beside the consumer application without packaging the embedded-Node CLI or site runtime. A clean install of the official package built from this checkout lists and downloads all 13 public demo resources with exact digests and no overwrite. The local 0.27.1 Native NuGet archive is 126,731 bytes and its inventory has only the Reader DLL, build target, license, and README. The local Compiler NuGet tool now omits its embedded Node executable; its documented Windows commands route to native tools and its .NET launcher handles informational output. The explicit CLI constructor remains available. This local package change does not mean the registry already carries it or that the preview ABI has 1.0 stability. The clean NuGet consumer now also exercises an external-index member edition: it rejects a missing index credential and absent or incorrect member key, leaves no partial protected output, verifies exact protected bytes, and keeps an existing file. The Windows clean installed native-default NuGet consumer also builds and reads all six carrier modes through the familiar AmoosedReader API, checking exact bytes, digests, and no-overwrite output for each. An opt-in check lists the public amoosed.com HTTPS site, downloads a bounded public resource, verifies its digest, and preserves the output on a second download. This covers one real public host; private target hosts, transport failures, and the full release matrix still need evidence. The separate installed Node Reader HTTPS gate reads every public resource within a bounded 64 MiB set, checks its digest against verified metadata, compares exact bytes with the JavaScript Reader for resources with at most 64 parts, confirms protected content stays locked without a key, and checks no-overwrite on a downloaded resource. The many-part case needs the native Reader's bounded adjacent-range cache; the JavaScript reference currently issues an individual request for each part. This is still one public host, not target-host coverage for every supported deployment. The Windows x64 clean-installed review package passed that gate against the current amoosed.com release: 13 public resource digests, nine exact JavaScript byte comparisons, locked member content, and no overwrite. Its 2,155-part Ruma image completed through bounded native range windows. The opt-in gate for the locally built official AmoosedWeb.Reader NuGet package now downloads all 13 public resources from the same HTTPS host, checks each digest and no-overwrite behavior, and rejects member content without a key or partial output. It passed from a clean local package install; the registry package and other hosts are not covered by this result. The same clean-install gate now damages the hosted discovery index and an indexed byte inside an appended carrier on separate local copies of the release. The installed .NET Reader reports a verification failure in both cases; the carrier failure leaves no partial resource file. These checks protect the official package path in addition to the native core fixtures.

The proposed NGINX host integration is another native-core consumer, not a game SDK. Its module should use the public C ABI for offline deployment validation and a versioned release manifest, while NGINX handles per-request routing, policy, and byte serving. Do not call blocking remote Reader operations inside an NGINX worker or add host-specific symbols to the stable amw1_ ABI without the usual parity and compatibility gates. Static hosting and its developer tools take priority; this adapter remains a later phase.

1. Finish the native Reader

• Keep the preview C ABI as the cross-language boundary. The C++17 interface uses standard-library types and is not a cross-compiler binary ABI promise.
• Test hosted and external indexes, public and member data, all published carrier codecs, cancellation, error categories, and no-overwrite output on every claimed platform. Windows x64 and Ubuntu Linux x64 review ZIPs pass local clean-consumer gates; broader platform and operation parity remain.
• Install only public headers, prebuilt libraries, runtime dependencies, examples, license, and ABI inventory for third-party developers. Keep implementation source in the separately encrypted licensed member edition.
• Freeze a new amw1_ C symbol namespace only after the complete operation matrix and clean consumer builds pass. Preserve status values, ownership, calling convention, and symbol inventory within 1.x.

2. Move compiler behavior into native code

The current compiler and distributed native CLI still execute JavaScript with an embedded Node.js runtime. Replace the implementation in tested slices:

The Windows AmoosedWeb.Compiler NuGet tool now runs init, init-game, init-share, update-project, install-skill, update-skill, rotate-project, build-project, validate-game, export-runtime, bundle, compile, pack, unpack, verify, member-file, media-key, pixel-capacity, carrier-embed, carrier-extract, carrier-verify, carrier-embed-set, carrier-extract-set, carrier-verify-set, verify-site, verify-bundle, unpack-bundle, package-pages, verify-managed, verify-backup, remote-list, remote-get, remote-pull, and check-host through packaged C++ tools beside the self-contained CLI. The release gate clean-installs the tool, builds and verifies a starter, checks private key creation and no-overwrite, rejects a changed carrier, and packages and verifies the Pages inventory and private backup without upload. The game validator and runtime exporter also run natively, with clean package parity checks. The native initializer copies packaged, version-matched starter inputs into a new Git repository without replacing an existing project. The clean npm gate compares every generated starter file against the packaged JavaScript initializer; init-share also checks a multi-carrier sample and an external-index build. The native updater requires a clean independent Git root and ignored private .amw/ files, upgrades unchanged older starter inputs, preserves owner edits, and rejects tracked private files in the clean npm gate. Other published compiler commands still use the embedded Node CLI; this remains a partial migration.

The six public agent skills are now shipped as version-matched files beside a native Windows installer. Clean installed npm and .NET consumers check that ordinary installation preserves differing existing text, explicit update refreshes it, all update skips absent skills, and a selected update may add one. Owner-only repository skills are not packaged. The Windows packages now route project key rotation through a C++ tool as well. It rotates member keys, public encoding salts, and external index keys without passing secrets through arguments. Clean installed consumers check member and hosted-site rotation followed by a native rebuild. The .NET package gate also checks private index archival, new credential generation, and an authenticated external-site rebuild. Its clean .NET gate also makes the configuration read-only to force failure after the index-key swap, then checks that the prior configuration and key are restored and no new member key remains. Broader interruption and recovery cases remain open. The Windows compiler commands also route hosted remote-list, remote-get, and remote-pull through the revision-16 native Reader C library. The clean installed npm and .NET gates exercise public and member files through a local HTTP site, including a private index in the .NET case. The remote commands retain the Reader's verified no-overwrite download behavior. Wider transport and target-host checks remain part of the Reader 1.0 gate. Both Windows command packages now use a native check-host executable for runtime route headers and CSP, index range and cache rules, carrier ranges or media HEAD, and verified resources. It uses the packaged policy and version, and stages resource checks in an owner-only temporary directory. Clean installed gates check a valid local host and reject a deliberately missing cache header. Both Windows command packages now route serve to a loopback-only C++ preview server. It preserves the local server's GET/HEAD byte ranges, content types, cache and CSP headers, and virtual app boot fallback. A response-parity gate compares eleven requests against the JavaScript server and rejects an encoded parent-path escape; clean installed npm and .NET tools run that gate.

The Windows-built amoosedweb-compiler npm package dispatches the commands listed above to C++. Its other commands remain in the bundled JavaScript CLI. For verify-site, protected resources without a member key receive stored-part hash checks; keyed plaintext authentication remains the stricter native SDK operation. The Windows command now consumes AMW_CONTENT_KEY_HEX for that keyed check and rejects a wrong or malformed key in clean installed npm and .NET package tests. verify-bundle reuses the native integrity checks and requires the directory to contain exactly the indexed carriers, including the hosted favicon when applicable. Clean package gates reject an extra file. unpack-bundle reuses that verification and the native Reader to publish recovered resources as a new directory only after every resource verifies. Member bundles require the key; clean npm and .NET consumers check exact public and member bytes, wrong-key cleanup, and no overwrite. The clean .NET gate also extracts an externally indexed member overlay using its separate credential. The Windows bundle CONFIG SITE APP OUTPUT [INDEX_OUT] command now reads the authored inputs in place through the native C++ overlay builder. Clean installed npm and .NET consumers compare hosted and external carrier bytes with the JavaScript command; external .amwkey and ICO bytes match too. The builder keeps the separate credential owner-only and refuses existing outputs. A package built on another operating system keeps the JavaScript command path until native builds are available there. The Windows npm and .NET compiler packages now route compile DOCUMENT.json OUTPUT.amw through the C++ document composer and wire writer. Clean installed gates compare exact bytes with the JavaScript compiler for plain Unicode, private-index, and hosted webApp documents, and reject an invalid authored document before creating output. The matching native local verifier now powers pack, unpack, and verify in both Windows packages. Clean installed gates compare v2 universal carrier bytes with JavaScript, recover exact original and document bytes, reject a changed carrier, and read legacy v1 footers. Broader large-file and output-failure parity remains open. The Windows npm and .NET command packages also write .amwmember credentials through a native tool. Clean consumers compare its token bytes with the JavaScript format and confirm that an existing output is preserved. The credential is written with a current-user Windows ACL and no replacement. The Windows packages now route key-link and member-link through a C++ command. It validates compact bearer files, verifies index ICO carrier and document bytes, checks the secure origin and protected return path, and matches JavaScript URLs in direct and clean-package fixtures. Optional SVG QR output uses the pinned MIT-licensed Nayuki generator and a private, new-only file. Its matrix encodes the same bearer URL with medium error correction. The installed Windows commands also use the packaged native OS key generator for media-key and the native PNG adapter for pixel-capacity. Clean consumers check private key shape, refusal to replace a key, and capacity parity against the JavaScript PNG reader. The single-file encrypted carrier commands now use bounded Windows CNG GCM chaining and staged, exclusive output. A cross-implementation fixture verifies native-to-JavaScript and JavaScript-to-native recovery, wrong keys, modified carrier bytes, no overwrite, and multi-block input. The folder-set commands now use the same native CNG path. They authenticate each encrypted shard, reject missing or duplicate parts, verify the complete set digest, and publish only after the full payload matches. The clean Windows package gates exercise all three commands. Remaining standalone media encoding and decoding are still open. The Windows pixel-encode and pixel-decode commands now use the native PNG adapter and CNG AES-GCM envelope. A bidirectional JavaScript/native fixture checks recovered bytes, wrong keys, damaged input, absent keys, and no-overwrite behavior. Clean npm and .NET consumers exercise both commands. The standalone WAV, PNG frame, and MP4 exchange commands now have native Windows slices described below; broader size and interruption gates remain. The bounded audio-file-encode and audio-file-decode commands now use the native standalone WAV writer and Reader on Windows. They carry one 1–4068 byte payload using AMW_MEDIA_KEY_HEX; a direct interoperability fixture compares both directions with JavaScript and checks wrong-key, damaged-input, and no-overwrite behavior. Clean npm and .NET compiler consumers run that fixture. The Windows audio-decode command now assembles numbered WAV exchange parts through the native Reader. It checks each authenticated shard, the whole archive digest, every file digest, portable paths, and no-overwrite publication inside a private staging directory. A JavaScript-produced two-part fixture recovers nested Unicode files and rejects wrong keys, duplicate parts, altered WAV bytes, and a crafted traversal entry. The matching Windows audio-encode command now inventories regular input files, hashes each twice around private archive staging, writes authenticated WAV shards, checks each with the native Reader, and publishes the complete numbered set without overwriting. A two-part fixture round-trips nested Unicode files through JavaScript and the native decoder, and checks dry-run estimates and existing destinations. The separate Windows audio-encode-set command now builds indexed multi-clip WAV packets with three copies distributed across clips, optional PCM cover tracks, and private no-overwrite staging. The direct and clean npm/.NET fixtures restore two native-produced clips with the JavaScript Reader, both with and without covers. Windows audio-decode-set now recovers JavaScript and native sets through the C++ Reader, authenticating every packet and the media key before no-overwrite publication. Its direct and clean-package gates reject wrong keys, altered packet digests, unsafe paths, and existing output. The Windows video-decode now uses that same archive verifier after scanning an MP4 UUID exchange box and authenticating its AES-GCM envelope. A two-part JavaScript-produced MP4 set restores an 8 MiB-plus file through the packaged native command; wrong keys, duplicate parts, altered authentication tags, and existing destinations fail without new output. Windows video-encode now validates the original MP4 cover, stages an authenticated archive, appends one UUID box to each byte-identical cover, and publishes the numbered set without overwriting. A two-part native-produced set round-trips through JavaScript and native decoders, with matching dry-run estimates. Windows frame-decode-set now restores the indexed PNG pixel and legacy tile modes through the native media adapter and CNG, including packet and whole-payload authentication before no-overwrite output. Direct and clean npm/.NET tests cover both modes, wrong keys, altered packet hashes, unsafe names, and existing destinations. The matching native frame-encode-set now writes both PNG modes from an authenticated ciphertext packet map, verifies each frame through the native Reader, stages privately, and publishes without overwriting. Direct and clean-package tests recover its output through both the JavaScript and native Readers. Large-file, source mutation, and interruption coverage remain open.

The owner-side AmoosedWeb.NodeCompiler preview now wraps the installed revision-9 Compiler C library through Node-API worker calls for full-site builds and offline verification. Local Windows x64 and Linux x64 source-free npm tarballs pass clean consumers that build hosted and external-index member editions, including wrong-key, existing-output, pre-start cancellation, and game catalogue checks. The Windows x64 tarball now also contains the matching C++ Pages tools. Its clean installed consumer builds a distribution, verifies the Pages inventory and private source/key backup, and rejects an existing output. This path runs native executables for release packaging, while site builds and verification continue through the Compiler C library; neither path uploads. The local Windows x64 npm review tarball now also installs an amw-native-preview command that invokes that same native backend for build-site, verify-site, and package-pages. Its clean installed consumer builds and verifies an external-index member site, rejects a missing member key and existing destination, and prepares a hosted Pages distribution with a managed inventory and private backup. The small Node.js command wrapper still requires Node.js, while the carrier codec and release tools run in C/C++. The Windows npm compiler preview tarball and Windows .NET tool preview now package the five version-matched browser runtime routes. Clean installed consumers build and prepare Pages distributions from the packaged runtime without a separate runtime argument. The Pages commands accept an explicit runtime directory override for custom installations. A local byte comparison found the five Windows preview runtime files identical to the current generated Pages release files. Broader command and release parity remains open. Both installed Windows command previews now expose export-runtime through the matching native C++ exporter. Their package checks compare every exported route byte and SHA-256 contract entry with the packaged runtime, verify the compiler version, and reject an existing export destination. The Windows Pages, runtime-export, overlay, and verification command entry points now convert wide Windows arguments to strict UTF-8 before parsing paths. Clean installed npm and .NET tool fixtures run their project, runtime export, Pages packaging, inventory, and dry-run deployment paths below directories whose names contain Polish characters. Both the npm and .NET review command packages now carry a compiled Windows amw-native-keygen executable. It uses the operating system CSPRNG, creates one private new key file, and refuses to replace an existing file. Their clean installed consumers verify the generated hex format and no-overwrite rule. Both packages now expose validate-game through a compiled native validator. It uses the same catalogue and referenced-file checks as the native build, returns the published command's JSON summary, and rejects absent catalogues and invalid records. Clean installed consumers exercise these cases under Unicode project paths. The shared native game parser now rejects catalogue and experiment revisions above JavaScript's safe integer range. This moves key generation out of language-specific wrappers. A separate native build-project command now creates or reuses the project's private member and external-index hex keys, builds and verifies the site, and writes external credentials in a private project directory. Clean installed npm and .NET tool consumers exercise first and repeat builds, key reuse, verification, and failed build cleanup. The command now writes a private .amwmember file whose bytes match the JavaScript member-token format; both clean consumers decode it and reject a conflicting saved credential. The native command now accepts the published AMW_CONTENT_KEY_HEX and AMW_INDEX_KEY_HEX environment inputs, rejects malformed or conflicting values, and does not persist the supplied hex key when no saved copy exists. Both clean consumers verify that behavior. The command now writes digest-named external ICO and .amwkey files directly under .amw/indexes/, reuses matching bytes, and rejects conflicting saved files. The Windows Pages packager now calls this project builder for ordinary invocations without explicit key paths. Clean installed npm and .NET tool consumers prepare external-index member distributions from saved and environment-supplied keys, verify their inventory and backup, compare the carrier bytes with a standalone project build, and check that private project files stay out of pages/. The full published CLI lifecycle still needs parity. Both Windows command packages also expose verify-managed, verify-backup, and verify-pages, backed by the native managed-manifest verifier. Clean installed consumers check the Pages asset inventory and private backup independently and together, then reject changed HTML and backup receipts. They now also carry the native Pages deploy handoff. Its --dry-run checks the same distribution without upload, including rejection of a modified asset in clean installed consumers. A real upload requires an installed Wrangler or explicit Node and Wrangler paths and remains the owner's action. The Windows npm compiler and .NET tool packages also expose that handoff through amw deploy-pages DIST PROJECT [branch] --dry-run. Clean installed consumers check the native preflight and reject tampered Pages bytes. Both packages use the native handoff for real uploads too. Explicit Node and Wrangler paths may be supplied; otherwise Windows runs installed npx.cmd wrangler after the inventory and private backup pass. A clean-package test replaces npx.cmd with a local stand-in and confirms the handoff without uploading. Neither path uploads during --dry-run. The Windows npm and .NET review commands now run both native inventory and private-backup verification for verify-pages. Clean installed consumers reject a changed page and a damaged backup receipt independently through that command. The official Windows .NET Compiler package now omits the embedded amw.exe. Its documented commands route to packaged C++ tools; the .NET launcher handles grouped and per-command help, version output, guide/store links, and invalid arguments. The packaged help catalogue is generated from the same authored command list as the JavaScript CLI. The clean installed-consumer gate checks the package inventory, representative command output, and native media, Pages, site, and Reader paths. Broader command and target-host parity remains before a stable native compiler claim. The installed C SDK now includes the package license consumed by both the C and Node review packages. This is a separate review package, not a replacement for the published npm compiler: the remaining compiler commands, native deployment handoff, and wider clean target-host tests remain before a native-backed npm compiler can be offered. Keep keys as raw buffers outside command arguments and preserve the C status code through the wrapper.

An owner-side Windows x64 .NET 10 compiler review package now calls the same revision-9 C boundary for hosted and external-index member builds and offline verification. Its NuGet package includes the prebuilt DLL but no embedded-Node CLI or implementation source. It also includes the matching C++ Pages tools. A clean installed consumer verifies both editions, typed missing-key and existing-output failures, pre-start cancellation, game validation, and a Pages distribution with its managed inventory and private source/key backup. It does not yet replace the published AmoosedWeb.Compiler tool: command parity, native deployment handoff, and release policy remain.

The separate local Windows x64 AmoosedWeb.Compiler.NativeToolPreview NuGet tool now executes build-site and verify-site through the same C library and package-pages through the matching C++ tools. A clean dotnet tool install consumer built and verified an external-index member site, rejected an absent member key and existing destination, and prepared a hosted Pages distribution whose managed inventory and private backup both verified. The package contains the native DLL and tools but no amw.exe, embedded Node runtime, or C++ source. It has a smaller command set than the published compiler tool, so the public package stays unchanged until command parity and release checks pass.

The native project builder now checks an optional game catalogue and all referenced game records before it publishes an overlay. The Windows gate npm run test:native-game-build compares accepted and rejected fixtures with the JavaScript game validator. The clean installed .NET compiler consumer also checks that missing game assets return the input-error status and malformed records return bad-format, then verifies a valid game build. Its review gate uses an isolated NuGet cache so a previous package with the same preview version cannot mask a rebuilt native DLL. This closes a build-time validation gap for game projects; it does not make either preview wrapper a replacement for the published npm or .NET compiler.

1. Add native parsers and writers for the fixed header, section manifest, favicon discovery index, external encrypted index, and site resource map. Check exact wire bytes and rejection behavior against existing fixtures. The first owner-side C++ writer now encodes canonical document sections and universal append footers, plus append/PNG-chunk/MP4-UUID resource carriers. It also encodes public and AES-GCM protected resource parts, matching the JavaScript bytes on local Linux and Windows fixtures. It also serializes assembled byte-addressable resource metadata as canonical webApp JSON. An in-memory bundle operation combines assets, site encoding-key derivation, public/member part encoding, round-robin placement, append/PNG-chunk/MP4-UUID carrier packing, and manifest writing with JavaScript byte parity. A hosted-index fixture now validates the base document's title, blocks, theme, links, and bootstrap, then writes a complete discovery favicon with exact JavaScript byte parity. The native virtual app favicon writer now embeds an identity document with exact JavaScript byte parity. Supplied byte-carrier webApp JSON is now checked by parsing and regenerating the native manifest; other manifest modes fail closed. Private-index fixtures now write encrypted index bytes into append, PNG ancillary chunk, and MP4 UUID first carriers and produce separate ICO and compact .amwkey credentials. They check JavaScript bytes and reconstruct public/member resources with either form. An owner-side native overlay command now reads authored project inputs and produces hosted or external byte-carrier overlays. Public, member, and external-index fixtures match the JavaScript compiler byte for byte and pass Reader verification. The external credential ICO and .amwkey stay in a separate private directory. On Windows the native builder protects that directory with an owner-only, non-inherited ACL before writing credentials; a late cancellation removes the staged directory and files. This is a prerequisite for automatic native key lifecycle and the eventual compiler package replacement. Saved hex keys now accept uppercase and lowercase digits with surrounding spaces, tabs, or line endings, matching common JavaScript project inputs. The native key reader holds the text in a bounded stack buffer and clears it on every exit. Hosted project assembly also accepts the public encoding salt used for site-key rotation and authored asset-to-carrier placements. An opt-in native full-site mode now copies the ordinary site, installs the supplied site-owned runtime, and writes Pages routing and header rules. Its hosted and external-index member output matches the JavaScript project builder byte for byte on Linux and Windows fixtures. Streaming project I/O, other media modes, key lifecycle, backups, and packaging remain. An offline native site verifier now authenticates every indexed resource from local hosted or external carriers and rejects loose app source, damaged bytes, symlinks, and source maps. Native overlay and full-site builds now invoke it on staged bytes before publishing output. Its internal C++ result now distinguishes input, format, authentication, verification, unsupported, cancellation, and internal failures without parsing diagnostic text. Windows and Linux generated-site fixtures check cancellation, damage, and missing-site categories. A separate owner-side amwc_preview_* C library now exposes local verification and site builds through nine checked exports and a plain-C fixture. Its CMake package can be installed for local review on Windows and Linux; it is not a published or stable compiler SDK. A separate native managed-manifest tool writes and verifies the same Pages file-hash inventory as the JavaScript packager, including file-count and size limits. The native snapshot mode can now copy project source and private key inputs to a protected local directory and write a receipt beside pages/; the native and JavaScript verifiers check that receipt and its file hashes. A native Pages command now stages a complete site, inventory, private snapshot, and DEPLOY.txt and publishes only after its native checks pass. It does not upload. A native deploy command now rechecks the managed inventory and private backup immediately before handing only pages/ to an explicitly selected local Wrangler CLI, with a verify-only dry run. Broader carrier parity remains before this preview can replace the distributed amw package-pages path.
2. Add native AES-CTR/GCM packaging, hash verification, and deterministic key handling. The native part writer now performs site CTR encoding and optional deterministic-nonce member GCM sealing. Site encoding-key derivation matches the JavaScript public, salted, and private-index cases on Linux and Windows. The external index writer derives its GCM nonce and locator from a saved key and verifies the matching private site encoding key. End-to-end project encryption now works for byte-addressable first carriers; broader key lifecycle and other carrier modes remain. Never package private keys or source snapshots into a public site.
3. Encode append, PNG ancillary, PNG low-bit, WAV tones, sparse frames, and MP4 UUID carriers with the same reconstruction guarantees as the current compiler. Test each produced carrier through Node, browser, and native Readers, including damaged and truncated cases. A standalone native WAV tone writer now matches JavaScript bytes for bare, mono-cover, and stereo-cover website shards on Linux and Windows. The native site builder now places public and member parts into WAV carriers and writes matching audioCarriers maps; Linux and Windows full-site fixtures check byte parity with the JavaScript builder. A Windows protected-WAV overlay fixture also verifies exact carrier bytes and member-resource recovery. Native project builds now reject PNG ancillary and MP4 UUID carrier URLs whose extensions the JavaScript compiler rejects, even when their bytes contain valid media. This closes one package-parity gap for the native npm and .NET review paths. The native bundle and private-index writers also accept uppercase media extensions that JavaScript accepts, with hosted PNG/MP4 overlay bytes checked against JavaScript on Windows and Linux. A portable pixel writer and platform PNG adapters now match the JavaScript low-bit packet, decoded pixels, and recovered payload on Linux and Windows. The native site builder places public and protected resources in PNG low-bit carriers; a full-site parity fixture checks manifests, recovered resources, and decoded image pixels across the two compilers. A standalone native AWF2 writer now packs one sparse-frame shard and compares decoded pixels and recovered bytes with JavaScript on Linux and Windows. The native site builder now places a public or member shard in frame-luma and a full-site fixture compares the manifest, recovered resources, and decoded pixels on Linux and Windows. An opt-in Chrome gate boots native-built PNG low-bit and AWF2 sites with the release runtime, then fetches a protected resource from each through the site worker after confirming that it is locked without the member key. It changes an encoded pixel bit and two AWF2 bit copies in their hosted PNGs and checks browser rejection of both damaged carriers. The same gate now opens a native-built external-index site in Chrome using its generated .amwkey invitation, verifies that the index import form is shown without that credential, then checks that a protected resource stays locked until a separate member key is supplied. This tests browser access to the generated private edition, not only offline Reader reconstruction. Evaluate one optional FFmpeg-backed authoring adapter shared by Windows and Linux for inputs that need media conversion, such as normalizing a music or video soundtrack to the bounded PCM WAV cover accepted by the native writer. Invoke an explicitly selected executable with argument arrays, cap input/output size and execution time, and validate the resulting PCM before packing. Keep FFmpeg output outside the final carrier after its bytes are fixed and hashed. Current Linux libpng decoding and Windows image adapters remain suitable for the exact PNG pixel contract; append/PNG-chunk/MP4-UUID placement and WAV packet modulation still need AmoosedWeb's own deterministic logic. The Reader must verify published carrier bytes directly and must not require FFmpeg to read today's formats. Do not bundle FFmpeg until the selected build and its redistribution terms have been reviewed against FFmpeg's license guidance. Test the same conversion fixture on Windows and Linux and compare decoded PCM, encoded carrier recovery, sizes, and performance before making it a supported tool. Investigate a separate GStreamer plugin so callers can compose AmoosedWeb media work with string-described pipelines, alongside ordinary GStreamer elements. GStreamer's gst_parse_launch accepts pipeline descriptions, and its plugin model supports loadable elements. The native core now writes and recovers a self-contained standalone media exchange WAV file. The writer seals a payload with the separate media key and a fresh nonce from the crypto host's platform CSPRNG; the Reader verifies repeated packets and authenticates the AES-GCM envelope. A Windows/Linux fixture compares exact one- and multi-packet WAV bytes with JavaScript and checks damaged-copy, wrong-key, malformed-WAV, and lost-signal results. Compiler C preview revision 9 exposes bounded single-file WAV writing through amwc_preview_audio_encode_file, and Reader preview revision 14 exposes authenticated recovery through amw_preview_audio_decode_file. The writer uses a fresh nonce and a caller-owned output buffer; the C fixture checks a round trip across the two libraries on Windows and Linux. The Reader's installed plain-C example is compiled and exercised against clean Windows and Linux SDK installs. Neither a GStreamer element nor an indexed multi-clip decoder ships today. A caller-supplied nonce remains available only through a clearly marked deterministic fixture helper. Website wav-4fsk1 is a different path whose native decoder uses the verified site's packet catalogue. The broader compiler C ABI and indexed multi-clip exchange remain open. The first milestone is a local, source-free consumer spike using the installed revision-14 C library as the codec boundary: load the plugin from an installed binary, run a string-described pipeline, and compare its recovered bytes and failure categories with the plain-C standalone example. Make that spike reproducible with an installed SDK, run gst-inspect-1.0 amwwavdecode for element discovery, and use gst-launch-1.0 to check parsing and the expected missing-key error. Run authenticated recovery through the GStreamer library API, where the key can be supplied after parsing and before playback. Record the exact GStreamer version and plugin search path on Windows and Linux. The plugin is an optional package with its own dependency and license review; it must not become a dependency of the core Reader or static-hosted sites. Start the plugin with a bounded whole-WAV input element. A candidate local pipeline is filesrc location=carrier.wav ! amwwavdecode name=decoder ! filesink location=recovered.bin; the element name and caps are provisional. In an application, parse this local pipeline, find decoder, supply the 32-byte media key through a non-string credential setter before moving to PLAYING, and clear the caller's key copy afterward. Do not encode the key in a pipeline property, URI, environment variable, or gst-launch-1.0 argument. The command-line run is only an element-discovery/diagnostic check until a safe local key handoff exists. This matches the existing native WAV parser's complete-file input. A later PCM-input variant may accept exact, unconverted samples from wavparse, but wavparse removes the WAV container, so that variant needs a separate native PCM decoder and explicit rate/channel/sample-format caps. Do not place audioconvert, a resampler, or a lossy codec before either decoder: changing samples can destroy the embedded tone packet. The element must enforce a whole-input size bound, retain output in a bounded private spool, and emit no recovered bytes until the native core verifies the complete payload and, where applicable, authenticates it. On error, cancellation, or missing credential, discard the spool and emit an error rather than a partial resource. Website WAV carriers additionally require the verified index and original carrier bytes, so a separate site-resource source element would be needed for them. Decide how a companion encode element receives both cover audio and payload data before fixing its pads or caps. A separate authoring adapter could use GStreamer to normalize a cover WAV before the native writer packs bytes; that is comparable to the FFmpeg authoring option above, not a replacement for AmoosedWeb's packet or verification logic. Treat pipeline descriptions as local executable configuration, never as untrusted site metadata or a stable C ABI input. Use gst_parse_launch_full with fatal parse errors in a production adapter, and inspect the instantiated elements before running it. Keep secrets out of pipeline strings and logs; pass them through a deliberate local credential interface. Bound any appsrc/appsink queues and propagate back-pressure rather than dropping samples; their documented queues can otherwise grow if the application stops consuming data. Implement the first element as a whole-stream decoder that buffers bounded input and publishes output only at EOS after authentication. A conventional per-buffer GstBaseTransform is not a good fit for that transaction; its documented base-class model is primarily one input buffer to one output buffer. Test element discovery, parsed library pipelines, CLI discovery and missing-key behavior, exact recovered bytes, rejection of damage and missing keys, transactionality, cancellation, and back-pressure on both Windows and Linux. GStreamer's gst-launch-1.0 guide identifies the CLI as a debugging tool; production integrations should use the library API. Its appsink and appsrc documentation describes the queue controls. Review the exact runtime and plugin dependencies before redistribution: GStreamer's licensing FAQ says plugins can carry different effective licenses and recommends checking each installed plugin with gst-inspect-1.0. Keep this plugin optional and outside the static-hosting and core SDK critical path until those gates pass. It is a proposal, not a supported encoder or Reader today.
4. Build the native project compiler, verifier, and Pages packager around those codecs. Preserve explicit release file lists, source/key backups, and the no-upload behavior of build and package commands.
5. Replace the distributed compiler CLI only when every shipped command and supported target platform has parity tests. Measure installed bytes and startup memory before and after; a smaller package is an outcome to verify, not a reason to drop features.

An owner-side compiler 1.0 C ABI draft proposes a separate amwc1_ query, cancellation handle, static-site build, and offline verification. It is compile-checked as C and C++ but has no implementation or installed header. Its build call requires an already verified site-owned runtime and caller-supplied keys; it cannot replace the public compiler CLI or the Pages backup/release workflow. Freeze its symbols, numeric statuses, and ownership only after the native implementation and platform parity prove them. The experimental amwc_preview_* C boundary exercises local verification and hosted, member, and external project builds. It does not implement this amwc1_ proposal or a complete replacement for the public compiler CLI.

3. Use the native core from every SDK

Complete the Windows npm and .NET Reader and compiler migrations, including their clean installed-consumer and release gates, before changing the Unreal plugin or starting the PixelMaze port. The Unreal adapter should consume the same verified native package that those language bindings have already tested.

• Keep the existing npm Reader and compiler commands and the NuGet Reader and tool APIs as compatibility surfaces. Their implementation should call the same native Reader and compiler core, rather than maintain separate codec implementations indefinitely.
• Give Node.js a thin native binding to the C ABI (for example N-API) and distribute version-matched binaries for each claimed platform. The npm compiler CLI may call a standalone native compiler executable where that gives a simpler and safer process boundary. Do not silently fall back to a different codec when the native binary is missing. Windows x64 and Ubuntu 22.04 x64 owner-side Node-API previews now list resource metadata, reads fully verified bytes, accepts AbortSignal, and downloads without overwrite through the revision 16 C ABI on Windows and revision 14 on Linux. Its hosted, external, member, frame, and audio fixtures pass locally. The local Windows official npm build now selects the native bridge by default, but the registry package has not been updated. Broader transport and error parity and other native platforms remain. The preview's openSite() keeps one verified index snapshot across serialized list, read, and download operations, and close() waits for accepted work. Its whole-site pull checks the complete path list and downloads through that same snapshot without replacing existing files. A Windows clean-installed review tarball now also exercises the published Reader function names at the package root for hosted, external, member, and whole-site operations. Callers close the session explicitly. On Windows, an injected transport now reaches the native Reader through a bounded Node-API callback bridge, and the package omits the JavaScript fallback. Broader injected-transport and error-behavior parity remain before claiming stable native parity. The direct native API remains available at ./native in the review tarball. The preview accepts .amwkey, packed ICO, .amwmember, and hexadecimal member key files; it checks member edition IDs against the verified index. Separate source-free Windows and Linux x64 npm review tarballs build from installed SDKs, check exact file inventories, and pass their hosted, external, member, key-file, wrong-edition, session, media, damaged-carrier, cancellation, and whole-site pull and no-overwrite fixtures after clean local installs. The Linux addon's runpath is $ORIGIN only. Both tarballs are marked private and are not registry releases; the Linux validation host is Ubuntu 22.04. The Windows 0.28.17-preview.1 and Linux 0.28.14-preview.3 Node review tarballs also expose decodeStandaloneWav() through an async worker. Both clean consumers recover exact standalone bytes and reject an incorrect media key and damaged WAV. Their receipts read the matching revision-16 or revision-14 header instead of recording the older revision 13. An opt-in Windows clean-install gate compares all public amoosed.com resource metadata and one bounded resource's bytes between this native package and the current JavaScript Reader over HTTPS, then tests native no-overwrite.
• Give the .NET Reader a P/Invoke facade over the same stable C ABI. Give the .NET compiler tool a native compiler executable or interop wrapper from the same native implementation. No embedded Node.js runtime belongs in the final NuGet dependencies.
• Run the same hosted, external, member, media, damaged-carrier, cancellation, and output-race fixtures through native C++, npm, and NuGet public APIs. Compare command output, resource metadata, bytes, and error categories. A platform package is ready only after a clean consumer installs and runs it.

4. Publish language-specific integrations

The stable C ABI also supports PHP, Ruby, Go, and Java without separate carrier implementations. Each binding should expose the language's familiar API while preserving native error categories, cancellation, secret-file handling, and verified no-overwrite downloads. Reader bindings come first; compiler APIs follow the native compiler parity gates above.

• PHP: a Composer package with a small native extension or FFI layer, choosing the mechanism through clean consumer tests on supported PHP versions.
• Ruby: a gem with a native extension or FFI layer and platform-matched native binaries.
• Go: a module using cgo for the C ABI, with explicit headers, library search paths, and supported target triples. Keep a process wrapper available where cgo is unsuitable for a supported deployment target.
• Java: a Maven Central artifact with a small JNI or Foreign Function and Memory API binding, selected according to the Java versions we support. Keep native binaries version-matched and document their loading and redistribution requirements.

Each package needs its own versioned distribution, platform inventory, license, install guide, runnable examples, and package-registry publication workflow. Do not call a platform supported until its clean package consumer can install it and run the shared fixture suite. The native library's ABI version is independent of language-package versioning; wrappers must check the native capabilities they require at runtime. The owner publication handoff records registry destinations, account setup, and the release gate separately from this public technical roadmap.

Owner-side build scripts may continue using Node.js during the transition. The Windows x64 npm compiler now uses Node.js only as a command launcher. Its installed package contains the C++ dispatcher and native command tools, with no JavaScript compiler codec fallback. The Windows standalone compiler and NuGet tool likewise use the native dispatcher without an embedded Node.js runtime. Other platform packages and the browser runtime retain their current paths until their native gates pass.

5. Evaluate a browser WebAssembly target

After the native Reader and compiler pass the static-hosting and SDK parity gates, compile their portable codec and verification core to WebAssembly. Emscripten can connect C/C++ functions to JavaScript, but the browser still needs a small JavaScript adapter for same-origin fetch, service-worker requests, Web Crypto or equivalent native crypto, image/audio decoding, and verified download delivery. Compile the portable core only: WinHTTP, filesystem output, Node-API, and NGINX adapters remain host-specific. Keep the site-owned worker and its origin/security model; a Wasm module does not itself provide that.

Begin with a Reader proof that decodes hosted and external indexes plus every published carrier mode from the same fixtures as the existing browser and native Readers. Measure total compressed download size, startup time, peak linear memory, range-request behavior, and cancellation on target browsers. Then test the native compiler core as an optional browser authoring tool, including private-key handling and large-project limits. Use a narrow C-style export/JavaScript import boundary with explicit memory ownership; the stable amw1_ host ABI rules inform it, but a Wasm/JavaScript distribution is a separate compatibility target. Do not replace the production JavaScript worker or compiler until the browser fixtures and release gates pass.