Imagine what's nextHackYeah 2026 finalist

Harmoniser

Pride of the UK v2 · Akshaz7/capsules-harmonyos

Council score

Median of 3 models, weighted by the task's official criteria
65.0 / 100

A technically exceptional and genuinely original native HarmonyOS entry whose strong engineering and broad platform use are undercut by missing required deliverables, above all the recorded demo and the final .hap, leaving its core claims unverifiable as submitted.

Criteria · line = median, dots = each member
Originality20%
7.0

All members agree the capsule idea is genuinely novel: plain-language requests become schema-validated JSON mini-apps with a per-permission consent gatekeeper and on-device-first AI routing. The median follows B and C over A, because with no demo and no deck the novelty rests on code and docs rather than a shown working product.

Members disagree here: scores range by 2.0 points.
Demonstrated usefulness20%
6.0

Real everyday use cases are implemented and a judge-reported failure was diagnosed and fixed, but the cloud path needs a user-supplied API key, the on-device path needs a separate 480 MB model push, and no run is verifiable in the evidence. B's middle position fits best: C's 5 undersells the offline rule parser that delivers many capsules in code, and A's 7 ignores how narrow the submitted experience is.

Members disagree here: scores range by 2.0 points.
Technical execution20%
7.5

The engineering is substantial and real: about 45,000 source lines, 420 tests in 56 files, 366 commits during the event, a strict validator, a hand-written safe expression parser instead of eval, and a Node-API C++ engine port. The score is held back because the team's own audit lists claim/code gaps and features marked built but never verified.

Platform capabilities20%
8.0

Usage goes far beyond a webview: Calendar, Notification, Form Kit widgets, Scan, Vision OCR, Sensor, Network and Preferences kits plus the self-ported Cactus inference engine. The median credits that breadth while accepting B's caveats that the .so is arm64-only and the model weights are not bundled, so the on-device path is unverified on an x86 emulator.

Demo quality10%
2.0

No recorded demo exists anywhere: the team's own compliance audit records it as missing, the 15 screenshots resolve to placeholders and sample eval images rather than the app running, and the only checkable demo link points to esbuild.github.io. The members differ only in wording, not substance, on this total absence.

Reproducibility & transparency10%
6.0

Transparency is excellent: AI_WORKFLOW.md, AI integration docs, a compliance audit that names its own gaps, third-party attribution with hashes, and exact test commands. Reproduction fails though, because there is no final signed .hap, the model must be pushed separately, the form's setup field is blank, 8 commits were unpushed at check time, and no deck exists.

Source lines45,201
Tests420 cases
Claims built7.0 / 10
Task fitYes

Strengths

  • Genuinely original concept: plain-language requests become schema-validated JSON capsules rendered natively, with per-permission consent, block logging and on-device-first AI routing.
  • Deeply native HarmonyOS build using Calendar, Notification, Form, Scan, Vision, Sensor, Network and Preferences kits plus a self-ported Cactus inference engine through Node-API, far beyond a webview.
  • Strong engineering hygiene: about 45,000 source lines, 420 test cases in 56 files, a hand-written safe expression parser, and no committed secrets.
  • Outstanding AI and process transparency: AI_WORKFLOW.md, AI integration docs, third-party attribution with hashes, and a compliance audit that names its own gaps.

Weaknesses

  • Required recorded demo is missing; the team's own compliance audit records this, and no screenshot or link in the pack shows the app actually running.
  • Required working .hap is not published; only an unsigned pre-release that is many features behind, and the on-device path needs a separate 480 MB model push plus an arm64-only library an x86 emulator cannot load.
  • Pitch deck is not provided, so the concept cannot be judged as presented.
  • Advertised capability exceeds the code: vibration is offered in the UI and README with no implementing action, and several features marked built were never verified on emulator or device.

Red flags

  • The team's own audit documents a claim/code mismatch: vibration is advertised in the UI and README but no capsule action implements it.
  • Features marked built, such as reminders firing with the app closed and shake counting, were never verified on emulator or device.
  • The only checkable demo link in the submission resolves to esbuild.github.io, an unrelated website, so no demonstration of the app is verifiable.
  • In Smart mode the live marketplace search sends request text to the cloud without a consent notice, a privacy gap the team's own research flagged and fixed only for on-device mode.
Built during the event: yes: 366 commits by 3 authors, 2026-10-03 12:59 to 2026-10-04 08:09 UTC
Live demo: https://esbuild.github.io/ (HTTP 200)
Council v9
Aclaude:glm-5.3-flash75.070% agree
Bdots-studio/dots-3-note-preview:free63.090% agree
Cinclusionai/ling-3.0-flash-sante:free62.090% agree
Jclaude:glm-5.3–judge
A HackYeah 2026 finalist, queued automatically for a council review; the council wasn't told how it placed. The council read an evidence pack built from the repo, its decks and docs; it didn't run the code or see the pitch.
The site is open source

The council, the evidence pack, the prompts and the queue are all on GitHub. If a review helped you, a star helps other teams find it.

Star on GitHub