MethodMesh v2.13.0 — Alpha

MethodMesh v2.13.0 — Alpha

Released 2026-10-02. App version 2.13.0 (version code 14). The release includes a debug-signed APK for sideloading and controlled field evaluation.

External display and presentation

• Adds the reusable external_display.present capability.
• Discovers Android presentation displays through DisplayManager.
• Launches a clean MethodMesh presentation surface on a selected secondary display using Android display targeting.
• Adds handset-side refresh, blank and stop controls, plus persistent presentation notification controls.
• Reports when no suitable display is available and explains that USB video depends on device hardware, adapter and display support.
• Provides an explicit handoff to Android system casting for whole-device mirroring and third-party apps such as YouTube.
• Does not invent a USB-video transport or use a software screen-capture path.
• Adds module-owned documentation and a canonical ODK showcase workbook.

ESP mesh controls

• Adds a clear Settings switch for enabling or disabling ESP mesh communications.
• Disabling mesh stops the service, BLE maintenance and active voice transmission.
• Disabling mesh removes the persistent foreground notification and hides the dashboard Talk/Listen control.
• Prevents a disabled mesh service from recreating its foreground notification during startup.

Limitations

• External display support depends on Android exposing a presentation display. A USB-C port without DisplayPort Alt Mode cannot be made to output video by MethodMesh.
• The initial external presentation surface is generic; capability-specific dashboards such as astronomy remain a follow-up integration.
• Whole-device mirroring remains controlled by Android and the device manufacturer.
• This is an alpha release for development, testing and controlled field evaluation.

Validation

• Debug APK build: passed.
• Focused ESP mesh and module-discovery tests: passed.
• External-display documentation/ODK architecture checks: passed.
• The full unit suite retains unrelated pre-existing module-boundary failures in Home/ESP mesh and NFC code.

The APK is debug-signed and intended for development, testing and controlled field evaluation.

MethodMesh v2.11.0

MethodMesh v2.11.0 — Alpha

Released 2026-09-30. App version 2.11.0 (version code 12). The release includes a debug-signed APK for sideloading and controlled field evaluation.

NFC credentials

• Enforces authenticated ROSC2 credential expiry, with inclusive calendar-date handling and a UTC-midnight exclusive expiry instant.
• Returns valid_until_iso in provisioning and verification results, including expiry failures where the credential can be decrypted.
• Produces explicit failed verification results with human-readable messages such as expired credential and incorrect PIN.
• Separates provisioning into card preparation, PIN creation, PIN confirmation, write, deliberate fresh-tap verification, and final result stages.
• Uses an on-screen PIN keypad and re-arms NFC reader mode between write and verification taps.
• Preserves issuer identity evidence without adding study or provisioner knowledge to MethodMesh; Sentinel remains responsible for later legitimacy reconciliation.

ODK examples

• Reduces the canonical provisioning and verification examples to necessary inputs, confirmation outputs, issuer evidence, expiry, and one full JSON field.
• Removes the redundant NFC provisioning showcase form.
• Regenerates the packaged ODK template catalogue.

Validation

• Focused NFC unit tests: passed.
• Kotlin compilation: passed.
• Debug APK build: passed.
• ODK catalogue generation: 415 templates, 0 generator errors.
• git diff --check: passed.

The APK is debug-signed and intended for development, testing and controlled field evaluation.

MethodMesh v2.10.0 — Alpha

MethodMesh v2.10.0 — Alpha

Released 2026-09-27. App version 2.10.0 (version code 11). The release includes a debug-signed APK for sideloading and field evaluation.

A toolkit for field, lab and everyday work

• Expands MethodMesh as a practical toolkit for people collecting data and making observations in the field, in the lab and in the wider world.
• Makes the “many small apps in one place” use case more explicit: capabilities share a dashboard, artifact layer, presets, protocols, schedules and external/ODK contracts.
• Refreshes conversions, Weather, Signals, QR/barcode, live translation, NFC and device-facing workflows with clearer instrument surfaces, live results, validation notes and updated examples.

Devices, transport and evidence

• Adds the first MethodMesh Devices implementation pieces, including display capabilities, ESP32-C3 firmware installation assets, device provisioning and ESP mesh join/provisioning flows.
• Extends ESP mesh transport diagnostics, coexistence handling, secure provisioning and BLE-related coverage.
• Adds NFC issuer identity and evidence-first credential assurance, including the canonical public-key fingerprint and public issuer bundle used for later provisioning-device registration.
• Adds quiet trusted-clock refresh scheduling and preserves policy-neutral time/provenance evidence across execution results.

Widgets and practical UI

• Adds the widget bundle system with compact, frosted and themed shortcut surfaces, expanded bundle views, configuration migration and restart recovery.
• Improves calculator/conversion, weather radar, streaming translation and QR-burst interactions while keeping capability-owned workflows and live readouts coherent.
• Adds an early Display module with clock and timer examples.

Forms, documentation and repository hygiene

• Regenerates the packaged ODK/XLSForm catalogue from module-owned examples, including new Display, live-translation and Signals examples.
• Updates the MethodMesh Master Book with Devices, the Devices ↔ Field Transport bridge, NFC issuer assurance, instrument dashboard guidance and current implementation boundaries.
• Consolidates the outstanding module sources, tests, firmware, prototype archives and the XLSForm compiler history on GitHub.
• Removes temporary local backups and superseded module-local copies where the current source or generated catalogue is authoritative.

Validation

• ./gradlew test: passed; 254 JVM tests, no failures or skips.
• ESP mesh security invariant self-test: passed.
• Debug APK build: passed.
• ODK catalogue generation: 415 templates, 0 generator errors. Advisory form-revision findings remain for 141 templates; they do not prevent packaging and are documented follow-up work.
• The APK is debug-signed. Interactive device, NFC, ODK round-trip, ESP hardware and production signing validation remain required before production deployment.

Known alpha limits

• ESP mesh, physical devices, live translation, Signals, Weather radar and several instrument-style modules remain under active field validation.
• The packaged APK is intended for development, testing and controlled field evaluation, not as a production-signed distribution.
• Transport routing, heterogeneous device support, large-object transfer, issuer registry reconciliation and authoritative ODK validation remain partly implemented or roadmap work.

MethodMesh v2.9.0 — Alpha

MethodMesh v2.9.0 — Alpha

Released 2026-09-22. App version 2.9.0 (version code 10); canonical Master Book remains v1.25.

Architecture, provenance and time assurance

• Consolidates the v1.25 implementation and subsequent UI/widget patches. FULL execution envelopes carry policy-neutral time evidence and captured module/capability identity, version and maturity. Historical exports retain the producing implementation's identity after upgrades; legacy results explicitly report missing provenance.
• Shared Clock Assurance advances verified timestamp anchors using same-boot monotonic time, exposes uncertainty and reboot/unanchored states, and preserves wall-clock rollback/forward-divergence evidence. RFC 3161 anchoring checks signer identity, configured trust, certificate chain, validity and timestamp usage.
• Workbench adds Time Assurance inspection and manual trusted-time refresh. Home shows anchor recency and signed Android clock offset, with a warning above 60 seconds. This threshold is presentation only; it does not change assurance policy or Android system time.
• Corrects unequal forward/backward clock-tolerance handling while retaining rollback detection. Shared location, language, sensor-profile and reference-library utilities now live in the platform layer; cross-capability game/API calls use the existing execution registry.

Module maturity and user experience

• Universal version and maturity badges use a canonical resolver, tolerate legacy/unknown status text, and provide compact, aligned module rows and capability metadata.
• Updated conversions with worked explanations and precision controls, FieldStats/LabBench dashboards, Network Tools, and barcode scanning, generation and cloning with preset integration.
• Includes File Lab inspection/conversion and the Text documents workspace for text, Markdown, JSON and JSON Lines; retains star-spectrum calibration and browser-return bridge work since v2.8.0.

Widget regression fix

• Application startup calls MethodMeshWidgetProvider.updateAll(this) after module and scheduler initialization, rebuilding existing widgets from their saved configuration so icons, labels, colours and target-specific taps return after restart/update.
• Preset and protocol IDs, schedule toggles, widget launch origin and return-to-launcher routing are preserved. Saved-config regression tests cover preset appearance, legacy defaults, protocol and schedule targets; provider/dispatch routing was reviewed and remains unchanged.

Repository and form cleanup

• Preserves useful prototype/patch history, module sources, integration specifications and screenshots on GitHub. Local rollback snapshots, obsolete source ZIPs, firmware patch backups, flash dumps and IDE device settings are excluded; recoverable local copies remain available.
• Repairs a malformed Gradle property, removes machine-specific paths from generated catalogue metadata, and archives the superseded transport overview. Historical prototypes and cross-system design documents are explicitly separate from the sole current Master Book.
• Repairs scheduler/Tamagotchi settings while preserving their original form IDs, resolves duplicate duration fields, and adds three ESP mesh XLSForm examples plus missing API GET/question documentation. The regenerated catalogue contains 411 forms and zero generator errors.
• Refreshes stale tests to the v1.25 documentation rules: multiple capability READMEs, human-readable titles, independent form IDs, optional choices sheets and supported namespace controls.

Validation

• :app:compileDebugKotlin, :app:testDebugUnitTest, :app:assembleDebug: passed; 240 JVM tests, no failures or skips.
• Artifact compiler: 3 tests passed. Documentation hygiene: 0 errors. XLSForm catalogue lint: 0 errors.
• New coverage includes clock continuity/rollback tolerances, immutable software provenance, maturity fallback, legacy widget configuration and deterministic cross-capability composition.
• Existing advisory findings remain: 33 documentation-placement warnings and 133 XLSForm revision warnings/style findings. Authoritative pyxform/ODK Validate and interactive device tests were not run. A read-only check confirmed that the connected phone's existing widgets have RemoteViews; this does not replace testing the new APK on-device.

The attached APK is a debug-signed alpha build. Source archives correspond to this tag.

MethodMesh v2.7.0 — Alpha

MethodMesh v2.7.0

MethodMesh v2.7.0 is an alpha release that packages the current fieldwork, Paper Bridge, communication, translation and device work into one build. It is intended for practical testing and development, not production deployment.

Highlights

• Added a native, offline AprilTag detection boundary with CameraX analysis support, all pinned tag families, Android instrumentation coverage, and vendored sources for reproducible Android builds.
• Expanded Paper Bridge into a fuller paper-form workflow: template authoring and import, tagged registration, field extraction, review and audit metadata, persistent result bundles, and ODK-facing source/registered-image attachments.
• Added the four-person table conversation translator, language/voice support, and its focused ODK example.
• Expanded Signals with optical screen and torch transfer, AprilTag payload support, visual transport helpers, and refreshed focused ODK examples.
• Added the Weather module and its generated ODK catalogue entries.
• Refined ESP mesh gateway provisioning and connected-device support for bench testing with ESP32-C3 hardware.
• Made result sharing consistent across native capabilities, protocol/scheduler closeout, and saved exports: beef is shared as text, media is de-duplicated, and full provenance JSON is an optional sidecar. ODK/external returns always retain full JSON and available media URIs.

Build and platform changes

• Added the Android NDK/CMake configuration and required foreground-service permission for the native fiducial and connected-device work.
• Added OpenCV for Paper Bridge registration and AprilTag-related image processing.
• Regenerated the module-owned ODK/XLSForm catalogue from the current module sources.
• Updated the Master Book with the native fiducial boundary, artifact/export contract, and current build requirements.

Validation

• :app:assembleDebug passes with the release sources.
• Focused result, external-return, and scheduler unit tests pass.
• The generated XLSForm catalogue is included in the APK. Its structural warnings remain advisory migration work; they do not silently change form IDs or source workbooks.

Known alpha limits

• Paper Bridge, ESP mesh, Signals, Weather, native fiducials, and the table translator remain under active field validation.
• ESP mesh support is suitable for controlled bench tests; production provisioning, encrypted payloads, route discovery, and larger-payload fragmentation are still follow-up work.
• Sharing behaviour ultimately depends on the receiving Android application. MethodMesh supplies a standard text payload and explicitly grants every selected attachment URI.

MethodMesh v2.6.0

Highlights

• Added a live, non-resumable Digital Signing session.
• Increased document zoom up to 16× for large PDFs on small screens.
• Added tap-to-place checkmarks.
• Added typed text placement for form fields and labels.
• Added Move mode so checkmarks and text can be repositioned before committing.
• Markup is rendered into the committed PDF.
• Preserved Files, Reference Library, ODK catalogue, DOCX conversion, and artifact handoff improvements from the 2.5.x work.

Validation

• Android debug Kotlin compilation passes.

MethodMesh v2.5.0

MethodMesh v2.5.0

MethodMesh v2.5.0 adds the first shared artifact foundation and packages the banked module and ODK work from the real project checkout.

Highlights

• Added a core Artifact Service that separates artifact identity and handoff from persistence.
• Added bundled, managed and external artifact origins.
• Added persistent, session and transient artifact lifecycles.
• Added explicit artifact references and a shared picker contract.
• Added the Files surface for importing and browsing persistent artifacts.
• Added generated module-owned ODK/XLSForm asset projection while keeping module folders as the canonical source of truth.
• Preserved drag-and-drop module packaging; source workbooks are copied and indexed during the build rather than moved.
• Added hashes, provenance fields and policy findings to generated XLSForm catalogue entries.
• Included the banked Arcade, GameDeck, Digital Signing, Reference Library, Trusted Timestamp, Kobo and ODK work.
• Kept existing module-owned workbooks, deployed form identities and capability contracts intact.

Validation

• Kotlin compilation succeeds for the real Android Studio checkout.
• The generated ODK/XLSForm catalogue runs from module-owned docs/ folders.
• The artifact service and catalogue tests are included in the repository.

The full project test suite still contains pre-existing documentation and XLSForm contract failures. Device-level signing, sharing and ODK roundtrip testing remain follow-up validation for the next increment.

Upgrade notes

Files is the first consumer of the shared artifact layer. Reference Library, signing and timestamp workflows retain their existing repositories and contracts in this release; they can migrate incrementally to shared artifact references.

MethodMesh v2.4.0 — ODK/XLSForm contract consolidation

MethodMesh v2.4.0

MethodMesh v2.4.0 consolidates the project-wide documentation model and the module-owned ODK/XLSForm capability library.

Highlights

• MethodMesh Master Book v1.06 remains the sole normative project-wide documentation source.
• Installed and aligned the reviewed module-owned XLSForm library across 66 modules.
• Reviewed baseline contains 423 XLSForms:
  • 276 focused capability showcase forms
  • 147 broader, workflow-oriented or legacy examples
• Established focused capability showcase naming using example_odk_showcase_<capability_method>.xlsx.
• Retained example_odk_<purpose>.xlsx for broader, workflow, dashboard and historical examples.
• Preserved deployed form_id values as stable external identities.
• Clarified that filename, title, version and form_id are separate concerns.
• Added YYYYMMDDrr as the preferred version convention for new forms and intentional revisions.
• Tightened XLSForm settings metadata and human-readable title requirements.
• Clarified that XLSForms demonstrate the MethodMesh runtime contract rather than defining a second schema.
• Prevented XLSForms from inventing success fields, timestamps, JSON fields or other outputs not actually exposed by the runtime.
• methodmesh_full_json remains the shared complete structured/audit projection.
• Capability-specific scalar, status, time, JSON and media returns are included only where actually declared.
• Module handoff documentation now distinguishes focused capability showcases from broader examples.
• Documentation-hygiene rules reduce future architectural drift.

XLSForm migration

The reviewed XLSForm installation processed 423 canonical forms:

• 331 installed as new module-owned XLSForms
• 22 replaced older reviewed copies
• 70 were already identical
• 0 canonical reviewed targets were skipped because of local modifications

A subsequent identity-based cleanup identified 118 additional legacy filename variants.

Of these:

• 112 were verified as legacy duplicates by matching settings.form_id to exactly one reviewed canonical workbook in the same module and were removed after backup.
• 6 locally modified legacy workbooks were deliberately protected from automatic removal and remain pending module-specific reconciliation.

The protected workbooks are associated with active Arcade, Calibrated Scale, Digital Signing and GameDeck development. They are not part of the canonical reviewed 423-form baseline.

ODK/XLSForm contract

Module-owned XLSForms remain first-class MethodMesh resources.

Focused capability showcases demonstrate independently callable MethodMesh methods using their existing canonical contracts.

A showcase does not create a parallel API. It uses:

• the canonical method ID;
• declared capability inputs;
• the requested return namespace;
• declared capability/shared transport outputs;
• methodmesh_full_json where complete structured/audit return is required;
• Android URI/media transport where appropriate.

Where the shared runtime does not yet expose a desirable universal scalar success/time/JSON envelope, that is recorded as a shared MethodMesh contract gap rather than hidden by inventing XLSForm-specific fields.

Documentation consolidation

Project-wide MethodMesh doctrine is maintained in:

docs/METHODMESH_MASTER_BOOK.md

Module-specific documentation and XLSForms remain owned by each module.

Generated website pages, packaged ODK templates and other projections are not alternative architectural authorities.

Historical project-wide documentation and release notes remain available under docs/archive.

Compatibility

This release deliberately preserves stable MethodMesh method IDs and deployed ODK form_id values.

The XLSForm migration is a contract-alignment and documentation-quality exercise, not a wholesale external-identity renaming exercise.

Existing broader examples may coexist with focused capability showcases where both provide useful coverage.

Production status

Presence in the source tree or XLSForm library does not by itself promote a module to Production.

Production readiness continues to depend on the complete MethodMesh review contract across native execution, presets, protocols, ODK roundtrip, lifecycle behaviour, outputs, state preservation, documentation and relevant device testing.

MethodMesh v2.3.0 — consolidated current baseline

MethodMesh v2.3.0

MethodMesh v2.3.0 is a major consolidation release.

A substantial amount of MethodMesh development has taken place since the previous public repository updates, including changes across the application UI, capability runtime, module library, documentation, ODK integration, development tooling and project architecture.

This release therefore establishes a new current baseline rather than attempting to reproduce every intermediate development step as a separate release.

These notes summarise the major changes. They are intentionally not an exhaustive file-by-file changelog.

Highlights

• Major refresh of the MethodMesh application UI and navigation.
• Significant expansion of the MethodMesh module and capability library.
• Clearer separation between Production capabilities and modules still under Development or review.
• Continued convergence around the canonical capability model across direct native use, presets, protocols, schedules and ODK/XLSForm.
• Refined native result handling and the live-result → Commit workflow.
• Major update of the MethodMesh website and reference library.
• The MethodMesh Master Book is now the authoritative project specification.
• Continued development of offline-first field tooling, device integration, sensors, media, spatial tools, data processing and workflow automation.

Master Book is now authoritative

The most important documentation change in this release is that the MethodMesh Master Book is now the authority document for MethodMesh architecture and behaviour.

The Master Book defines the canonical system model, including:

• module ownership;
• capability contracts;
• method IDs;
• direct native execution;
• presets;
• protocols;
• schedules;
• widgets;
• ODK/XLSForm interoperability;
• result and output handling;
• provenance and audit data;
• lifecycle expectations;
• production-readiness expectations;
• documentation and module-review requirements.

Module documentation, source comments, the website and other guides remain important supporting material, but they should be interpreted against the current Master Book where there is ambiguity.

This change is intended to reduce architectural drift as MethodMesh grows.

Application UI refresh

The Android application has undergone a substantial interface refresh.

The aim is to make MethodMesh behave like a coherent field-tool platform rather than a collection of capability test screens.

Changes across the current interface include:

• revised dashboard and navigation structure;
• cleaner MethodMesh visual identity;
• improved typography, spacing and field readability;
• more capability-specific interfaces where a generic form would be inappropriate;
• clearer separation between the tool itself and its configuration;
• more unified capability configuration and execution;
• improved result presentation;
• persistent working state where appropriate;
• tap-to-copy behaviour for useful field results;
• cleaner native sharing;
• better handling of media results;
• improved preset creation and editing;
• improved protocol and schedule execution;
• more deliberate close-out behaviour;
• additional confirmation and guard rails around destructive actions.

A central design principle is that a capability should remain the same capability regardless of how it is reached.

The dashboard is therefore one interface to MethodMesh, not the definition of MethodMesh.

Canonical capability surfaces

MethodMesh capabilities are increasingly expected to maintain behavioural parity across the supported execution surfaces:

• direct native use;
• Dashboard;
• saved Presets;
• Protocols;
• Schedules;
• ODK/XLSForm calls;
• other supported external launches.

A capability may present differently on each surface, but its method identity, settings, execution semantics and returned values should remain coherent.

This is now a major part of module review.

Live result and Commit lifecycle

The native execution model has been refined around a distinction between a live working result and a committed result.

Where appropriate, capabilities now allow the operator to interact with, inspect or refine a result before explicitly committing it.

This supports workflows in which the first measurement, selection, calculation or observation is not necessarily the final study value.

The intended lifecycle is increasingly:

configure → run → live working result → Commit → return/export

The precise UI remains capability-specific.

External callers such as ODK must still receive deterministic completion and returned values without being forced through unnecessary native navigation.

Module and capability expansion

The MethodMesh source tree has expanded substantially.

Many additional modules and capabilities are now present or under active development across areas including:

• measurement;
• navigation and spatial tools;
• environmental sensing;
• Bluetooth and BLE devices;
• ESP32 sensor nodes;
• NFC;
• imaging and image processing;
• document capture;
• barcode and machine-readable code handling;
• audio and acoustics;
• timing;
• psychomotor testing;
• sampling and randomisation;
• scoring systems;
• counters;
• text processing;
• networking;
• online data;
• statistics and field calculations;
• surveying;
• clinical and laboratory utilities;
• emergency field tools;
• communications;
• authentication;
• printing;
• external Android application integration;
• web actions;
• question primitives;
• protocol support tools.

This source expansion does not mean that every module is now a Production capability.

A significant number of these modules are deliberately in the Development lane while implementation, physical-device testing, preset behaviour, ODK roundtrip behaviour, state preservation, documentation and user-interface review are completed.

Modules will be formally promoted into Production as they pass the current review process.

Production and Development lanes

MethodMesh now makes the distinction between implementation and production readiness more explicit.

A capability may exist in source and be useful for development without yet being suitable for deployment as a reviewed Production capability.

Production review considers the whole capability contract rather than simply whether the Kotlin code builds.

Depending on the capability, this includes:

• direct native execution;
• capability-specific UI quality;
• state preservation;
• preset configuration;
• preset execution;
• protocol use;
• scheduled use;
• ODK/XLSForm launch;
• ODK return values;
• compact primary results;
• audit/full JSON;
• attachment handling;
• orientation/configuration changes;
• physical-device behaviour;
• offline behaviour;
• documentation;
• module ownership;
• output and provenance behaviour.

The Development lane allows substantial new functionality to remain visible and testable without overstating its deployment status.

Presets

Preset handling has continued to evolve from simple saved settings toward reusable configured capability instances.

Current work includes:

• creating presets from the capability's own configuration interface;
• using capability-owned typed setting metadata;
• distinguishing fixed preset values from values supplied at runtime;
• avoiding repeated configuration during ordinary execution;
• clearer preset naming and management;
• direct preset execution;
• use of presets as protocol steps;
• use of presets from schedules;
• preserving the underlying canonical method identity.

Preset configuration should not require a second, independently implemented version of a capability's settings.

Protocols

Native protocols remain an important MethodMesh execution surface.

Protocols allow configured capability presets to be chained into reusable workflows without requiring ODK to orchestrate every operation.

Protocol handling has continued to improve around:

• ordered multi-step execution;
• shared run state;
• guided progression;
• coherent completion behaviour;
• common submission identity;
• combined output;
• linked attachments;
• final run-level result presentation;
• scheduler integration.

Protocol execution is intended to behave as one coherent workflow rather than a collection of unrelated capability launches.

Schedules

The MethodMesh scheduler continues to support local recurring and delayed workflows.

Scheduled actions can include MethodMesh capabilities and protocols as well as supported external targets such as ODK/Kobo forms and web resources.

Scheduler development has included:

• chained actions;
• cron-style timing;
• notifications;
• retries;
• pause/resume;
• testing;
• import/export;
• preservation of configured capability settings;
• improved close-out of scheduled native results.

The scheduler remains local-first and is intended to support field workflows even where continuous network connectivity cannot be assumed.

Results, sharing and outputs

Result handling has continued to move away from debug-style JSON presentation toward a layered result model.

For ordinary native use, MethodMesh should show the useful result first.

Examples include:

• a scanned code;
• a measurement;
• a selected identifier;
• a translated conversation;
• an image;
• a calculated value;
• a navigation result.

The full structured payload remains available where provenance, audit or machine processing requires it.

Native result surfaces increasingly support combinations of:

• tap to copy;
• copy;
• share;
• save;
• save media;
• export a complete audit package;
• Commit;
• close/return to the appropriate launch origin.

Verbose metadata should not obscure the field-facing result.

Canonical output and provenance

MethodMesh retains the structured output model developed across the v2.1 and v2.2 releases.

Direct runs and protocols can produce coherent output packages containing canonical JSON plus linked attachments.

Submission-level ...

MethodMesh v2.2.7

MethodMesh v2.2.7

This release tightens native close-out behaviour and admits a first group of reviewed prototype capabilities into the Development lane.

Highlights

• Added a public Android Downloads close-out action for native preset, protocol and schedule results.
• Added first-pass guided rails for multi-step preset/protocol/schedule runs.
• Improved combined protocol outputs so steps can progress and finish on a shared result screen.
• Reviewed and admitted Acoustics, Compass, Psychomotor Vigilance Test, Sampling and Sound Generator as Development capabilities.
• Hardened ML Kit language handling for conversation translation and shared language-pack settings.

Close-out and result handling

• Native result screens now include explicit actions for sharing, copying, saving to Downloads, exporting the full audit package and closing.
• “Save to Downloads” writes text/data results as result.txt and writes media as files under Downloads/MethodMesh/....
• Full audit export remains separate from simple user-facing sharing and Downloads output.
• Protocol and scheduled runs now collate step outputs into one final run result screen instead of leaving each preset sitting on its own result page.
• Audit-mode output now retains capability-owned *_audit_json fields without adding them to compact core sharing.

Development capabilities admitted

• Added Acoustics for local microphone-based pitch/frequency analysis, tuning, sound level estimation and tone comparison.
• Added Compass for magnetic heading and bearing-sighting workflows.
• Added Psychomotor Vigilance Test (PVT) with 10-minute PVT and 3-minute PVT-B modes, compact results and trial-level audit JSON.
• Added Sampling for reproducible sampling/shuffling/partitioning workflows with auditable outputs.
• Added Sound Generator for local tones, noise and sweeps with playback provenance.

These capabilities remain in Development until their module-specific device, preset and ODK validation items are closed.

ML Kit language handling

• Canonicalised ML Kit language codes and common aliases, including Chinese, Japanese and Korean.
• Improved conversation-translation speech locale mapping.
• Improved shared language-pack settings feedback and downloaded-language sorting.

Documentation and roadmap

• Updated the capability writing guide to reinforce the canonical “one module folder with nested docs and XLSForm” delivery contract.
• Updated 000_Roadmap.md with the admitted Development capabilities, remaining validation notes and completed close-out work.

Known issues / follow-up

• PVT remains Development because Android device timing/latency has not yet been physically characterised.
• Sampling CSV creation/input still needs real device validation.
• The not-yet-ready prototype queue still contains capabilities that either do not build or need deeper review before admission.
• Exchange-rate selection/value handling remains on the roadmap for a later pass.

Validation

• ./gradlew :app:assembleDebug passes.