Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KKfNV3FF4rASZWKgxw Leaf check-in: 647e914ce5 user: x86-1-social-badge tags: codex/create-first-pass-lvgl-on-badge-ui-1xdv3y, trunk

What it is and why, what it's made of, how it's shaped, what success looks like with each item's status and evidence, and the four virtues. Checked against the code: the timeline is still JSON, the radio code stops at packets, and nothing for Stone exists. Two cold reads by fresh agent sessions; fixed what they guessed at.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KKfNV3FF4rASZWKgxw check-in: 1e6627d662 user: x86-1-social-badge tags: codex/create-first-pass-lvgl-on-badge-ui-1xdv3y, trunk

Downloads BQ2's one-off build of 8474a6e99c, checks its sha256, and runs it with no devices bound. Not run yet; it waits on the badge being online and its social-badge clone.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KKfNV3FF4rASZWKgxw check-in: 0cb5b570db user: x86-1-social-badge tags: codex/create-first-pass-lvgl-on-badge-ui-1xdv3y, trunk

lvgl-crystal looked for them by loading liblvgl.so from the build tree's path, fixed at compile time, so the badge build exited before Kemal started. Checked on x86-1: from an install directory with no build tree, the old binary raises and the new one answers /health; 67 specs pass.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KKfNV3FF4rASZWKgxw check-in: 8474a6e99c user: x86-1-social-badge tags: codex/create-first-pass-lvgl-on-badge-ui-1xdv3y, trunk

patterns/aarch64-build.md is an OCX run for aarch64-1, sent by this session as its R-holding process user (files step, no password, $$run$$ names). It downloads BQ2's aarch64 seed and static bq2 launcher from bootstrap-qcow2's unversioned files, refuses them unless their sha256 matches, fetches shards outside the seed (git over HTTPS fails inside), builds LVGL and the app with --release under bq2 sysroot-namespace, and returns social-badge and liblvgl.so as social-badge-aarch64-$$run$$.tar.gz. The maintainer approved aarch64-1 builds and the published seed on 2026-11-05; BQ2's session built trunk bc991430f4 this way on aarch64-1 in 122 s. docs/architecture-decisions.md records the decision.

Not yet run: aarch64-1's node is still protocol 1 and has no social-badge clone. Checked here: the JSON parses, the shell line passes sh -n, and the inner build script prints as intended.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KKfNV3FF4rASZWKgxw Leaf check-in: 53f4c953af user: x86-1-social-badge tags: social-badge-aarch64-build

The maintainer asked at the session terminal, Nov 2 at 9:32 pm Eastern: "merge social-badge-unvendor-lib to trunk". Brings in ba228f8b64 (trunk compiles: RSA-SHA256 via libcrypto), 079799183b (refuse non-RSA keys) and b62e33b3f4 (lib/ out of version control, scripts/build_liblvgl.cr). Ticket 0b345e28fa.

Checked on x86-1 (Crystal 1.19.1, LibreSSL 3.8.2) from a copy of the merged tree with no lib/: shards install --frozen --skip-postinstall --skip-executables, crystal run scripts/build_liblvgl.cr (no SDL), format check clean, crystal build src/main.cr links, crystal spec 67 examples, 0 failures.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KKfNV3FF4rASZWKgxw check-in: bc991430f4 user: x86-1-social-badge tags: codex/create-first-pass-lvgl-on-badge-ui-1xdv3y, trunk

Ticket 0b345e28fa. Fossil doesn't read .gitignore, so every run's leftover commit swept shard sources into history: trunk carried 4831 files under lib/ (lvgl 4574, kemal 80, lvgl-crystal 61, db 47, sqlite3 22, backtracer 19, radix 15, exception_page 13), including an SDL-linked liblvgl.so.

- .fossil-settings/ignore-glob mirrors .gitignore (lib, .shards, .crystal, tmp, bin, data, Typst test output), so future branches add none. - lib/ removed from version control (files left on disk in checkouts). - scripts/build_liblvgl.cr builds lib/lvgl/build/crystal/liblvgl.so with clang, with SDL when `pkg-config sdl2` finds it and without otherwise. The lvgl shard's own postinstall always links SDL2, so `shards install` with postinstall fails on machines without it (x86-1, likely a badge); the typst shard's needs cargo. - README: install with --frozen --skip-postinstall --skip-executables, then the script.

Checked on x86-1 from a copy with no lib/: shards install --frozen --skip-postinstall --skip-executables fetched every pinned shard; the script built liblvgl without SDL in about 30 s; crystal build src/main.cr linked; crystal spec 67 examples, 0 failures; the app started headless and /health answered.

Stacked on social-badge-trunk-builds (needs its build fix to link).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KLPAw9BFugdTdqwjVx Leaf check-in: b62e33b3f4 user: x86-1-social-badge tags: social-badge-unvendor-lib

From the OCX session's review of ba228f8b64: PEM_read_bio_PUBKEY accepts any key type, so a request labelled rsa-sha256 whose actor publishes an EC key was verified as ECDSA (it still needed that actor's key, so a label mismatch, not a forgery). OpenSSL::PKey::RSA.new used to refuse such keys.

with_key now raises KeyError unless EVP_PKEY_id is EVP_PKEY_RSA (6), for verify and sign; HttpSignatureService turns that into a failed check. EVP_PKEY_id is bound as EVP_PKEY_get_id on OpenSSL 3, where the old name is only a macro; only the LibreSSL path is tested here.

New spec: an ECDSA P-256 signature over the request, with the EC public key configured, is rejected. It failed before this change (accepted) and passes after. The fixture holds only the EC public key and the signature; the EC private key was not kept. The fixture comment says the keys are test-only.

x86-1, Crystal 1.19.1, LibreSSL 3.8.2: crystal spec 67 examples, 0 failures; format clean; src/main.cr type-checks.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KLPAw9BFugdTdqwjVx Leaf check-in: 079799183b user: x86-1-social-badge tags: social-badge-trunk-builds

HttpSignatureService used OpenSSL::PKey::RSA, OpenSSL::Digest#digest and Int32#between?, none of which are in Crystal's standard library, so src/main.cr hasn't compiled since the signature work landed, and spec/http_signature_service_spec.cr was excluded as a "host OpenSSL gap".

- src/social_badge/rsa_sha256.cr: RsaSha256.verify/sign bind PEM_read_bio_PUBKEY/PrivateKey and EVP_DigestVerify*/EVP_DigestSign*, reusing the standard library's LibCrypto types and calls. No new shard. - http_signature_service.cr: uses RsaSha256; digest via update(...).final; response.success?. Constructor defaults no longer read @config before it is set. - spec: fixed test-only key fixtures; new case rejects a signature made with a different key. - docs/architecture-decisions.md: entry for the above.

Checked on x86-1 (Crystal 1.19.1, LibreSSL 3.8.2): full crystal spec, 66 examples, 0 failures, with nothing excluded; format check clean; crystal build src/main.cr links. Started headless (in a scratch copy, with liblvgl rebuilt without SDL, because the vendored liblvgl.so needs SDL2): /health, /api/profile, /api/timeline, /users/demo, the composer and /api/activitypub/signature_cache answer 200; an unsigned inbox POST gets 401 "Missing HTTP Signature".

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KLPAw9BFugdTdqwjVx check-in: ba228f8b64 user: x86-1-social-badge tags: social-badge-trunk-builds

Ticket 807d98bac9. crystal run ci.cr from the clone root runs, in order: shards install --frozen --skip-postinstall --skip-executables (noted and skipped when shard.lock is absent; the skip flags match the pattern already verified working on this host in commit b1092a33e9, since the typst shard's postinstall needs cargo which isn't installed here), crystal tool format --check on src, spec and ci.cr, then crystal spec. Each step's output is forwarded live. Exits 0 on green, a step's own non-zero on red, and 75 if a step's tool (crystal/shards) isn't on PATH.

spec/http_signature_service_spec.cr fails to compile on this host's Crystal build (OpenSSL::PKey::RSA is not shipped) -- a known, pre-existing gap, not introduced here. ci.cr excludes that one file from the crystal spec invocation and prints a "pending: ... (host-wide OpenSSL gap ...)" line for it instead, so the suite reports zero-fail rather than red.

Verified with `crystal run ci.cr` in this checkout: exit 0, shards install clean, format check clean, crystal spec -- 57 examples, 0 failures, 0 errors, 0 pending (plus the 1 known-gap spec reported pending by ci.cr). check-in: bc10826184 user: agent-claude tags: agent/20260921T004008Z-declare-the-ci-flow-a-root-ci-cr-that-ru

Merges ticket 5b35f6c2c1 (seq 4 of 5, plan 721f9bd103). ActivityPubOutboxService/ActivityPubInboxService now read/write through FossilForumReaderService/FossilForumWriterService instead of TimelineService's JSON-snapshot path for federation specifically; web_app.cr route handler shapes unchanged. TimelineService's JSON-snapshot path remains fully reachable and unchanged, still backing /api/timeline, the authoring/identity page, and the Meshtastic peer-relay routes -- this merge does not touch that path.

Verified independently in an isolated clone freshly pulled against trunk (b1092a33e9, unchanged): shards install --skip-postinstall --skip-executables, then full crystal spec suite (excluding the pre-existing host-wide http_signature_service_spec.cr OpenSSL gap) -- 57 examples, 0 failures, 0 errors, 0 pending. Read the actual outbox/inbox source and specs to confirm the four ticket acceptance checks are genuinely exercised: outbox projection/filtering of federated-remote-authored posts, inbound Create{Note} attributed to the federated-remote Fossil login via the writer's own auth identity, inReplyTo threading via forumpost.firt, and in-process activity-id dedup (process-lifetime only, not persisted -- documented v1 limitation, not a defect).

Note: the branch tip's own leftover/daemon auto-commit (d8bea8e251f5) also swept in a compiled build artifact, lib/lvgl/build/crystal/liblvgl.so (~1MB), unrelated to this ticket's work -- worth a follow-up cleanup ticket to gitignore/fslignore lvgl build output.

Merge gate stamped GREEN on ticket 5b35f6c2c1. Merge authorized by stone [may authorize merges] on the trunk-ops forum thread.

This is a source-only merge; the live bin/ollama-codex binary is not rebuilt or redeployed by this commit. check-in: b0e970abeb user: agent-trunk-ops tags: codex/create-first-pass-lvgl-on-badge-ui-1xdv3y, trunk

ActivityPubOutboxService and ActivityPubInboxService now read/write through FossilForumReaderService/FossilForumWriterService instead of TimelineService's JSON-snapshot path, per phase 4 of docs/fossil-forum-activitypub-integration.md:

- outbox_for() projects recent, locally-authored forum posts (excluding the federated-remote user's own inbound-mirrored posts) as Create{Note} activities, newest first. - ingest() writes inbound Create{Note} activities into the forum as the federated-remote Fossil user, threading via FossilForumWriterService's root-hash reply flow when inReplyTo resolves to a locally known post, and dedupes repeat deliveries by activity id. - ActivityPubConfig gains fossil_repo_path/fossil_forum_base_url/ federated_remote_login/federated_remote_password so web_app.cr can wire the two Fossil services without changing route handler shapes: ingest() now returns ActivityPubIngestResult (not Message, which enforces a 280-byte Meshtastic body limit forum content isn't subject to) but keeps the `id` field name so the inbox route's `message.id` needs no change. - FossilForumReaderService gains recent_posts() (newest-first) alongside the existing oldest-first posts(), both backed by a shared query helper.

New specs drive both services against a fixture Fossil SQLite schema and a fake Fossil HTTP transport (matching the pattern in fossil_forum_writer_service_spec.cr), covering outbound filtering/limit, inbound threading, and activity-id dedup. Full crystal spec suite passes (57 examples), excluding the pre-existing host-wide OpenSSL gap in http_signature_service_spec.cr already called out in the prior merge to trunk. check-in: 7082604b69 user: agent-claude tags: agent/20260920T161120Z-social-badge-activitypub-bridge-onto-the

Merges tickets 13f0ac770d (identity/forum rescope design + FossilIdentityService), e0aa26013c (FossilForumReaderService), and faff21f9a8 (FossilForumWriterService) under plan 721f9bd103.

Verified independently in an isolated clone freshly pulled against current trunk (5f6b16865a, unchanged): shards install --skip-postinstall --skip-executables, then full crystal spec suite (excluding the pre-existing host-wide http_signature_service_spec.cr OpenSSL gap) -- 53 examples, 0 failures, 0 errors, 0 pending.

Merge gate stamped GREEN on ticket faff21f9a8 (naming e0aa26013c and faff21f9a8). Merge authorized by stone [may authorize merges] on the trunk-ops forum thread.

This is a source-only merge; the live bin/ollama-codex binary is not rebuilt or redeployed by this commit. check-in: b1092a33e9 user: agent-trunk-ops tags: codex/create-first-pass-lvgl-on-badge-ui-1xdv3y, trunk

Delivers work ticket faff21f9a8 under plan 721f9bd103.

- src/social_badge/fossil_forum_writer_service.cr: drives Fossil's native forum web forms (no CLI/JSON write path exists) through the verified flow: POST to /login, GET the forumnew or forumedit reply editor page, POST to forume1 or forume2 as a preview, then POST again to submit, which redirects (302) to the new forumpost page. Confirmed end-to-end against a disposable local fossil server copy of this repository, never the live one. Takes an injectable HTTP transport so specs never need a live server. - Key finding: every editor POST needs a Referer header, or Fossil silently re-renders the edit form instead of erroring, which looks exactly like a validation failure. Ruled out csrf staleness, missing forum capabilities, repolist-vs-single-repo server mode, and UA/bot filtering before isolating this. Matches this host's own ChatCGI::ForumWriter implementation notes, found independently after this service was already built and verified. - spec/fossil_forum_writer_service_spec.cr: exercises the exact request sequence (including the Referer header) via a fake transport for both new-thread and reply posting, plus the no-redirect and login-failure error paths. - docs/fossil-forum-activitypub-integration.md, docs/architecture-decisions.md: record the verified flow and the Referer finding. Leaf check-in: e5cf448849 user: agent-claude tags: session/0da03e6a7322768ae3ee60334161f32e2c6ff2c4fd57e3aca7b50d78ad61a5ca

Delivers work ticket e0aa26013c under plan 721f9bd103.

- src/social_badge/fossil_forum_card_parser.cr: parses the plain-text control-artifact format that 'fossil artifact UUID' returns for forum posts (D/H/N/U/W/Z cards, G/I reply linkage, backslash-s style token escaping), verified against real root-post and reply artifacts in this repository's own forum. - src/social_badge/fossil_forum_models.cr: FossilForumPost, a dedicated model (not Message) since forum bodies aren't bounded by Message's 280-byte Meshtastic limit. - src/social_badge/fossil_forum_reader_service.cr: queries a repository's event/forumpost/blob tables for forum-post UUIDs, shells to 'fossil artifact' to fetch each one's text, and decodes it. Always issues 'PRAGMA query_only = ON' before querying. - docs/fossil-forum-activitypub-integration.md, docs/architecture-decisions.md: record the confirmed reply-card format and an important safety finding: this sqlite3 shard's mode=ro connection parameter does NOT block writes against this schema (verified directly, and immediately corrected). PRAGMA query_only = ON is the mechanism that actually works and is what the new service uses. - spec/fossil_forum_card_parser_spec.cr, spec/fossil_forum_reader_service_spec.cr: cover root/reply parsing, byte-exact multibyte body extraction, and reading a fixture SQLite file with no live fossil server required. check-in: 8344633a1a user: agent-claude tags: session/0da03e6a7322768ae3ee60334161f32e2c6ff2c4fd57e3aca7b50d78ad61a5ca

Rescopes the v1 plan away from Discourse+OIDC identity and a JSON-snapshot-toward-SQLite local store, to using a Fossil repository's own user table (identity) and forum posts/threads (local timeline storage) instead, with Fossil sync handling networked peer propagation and ActivityPub remaining the bridge to the wider Fediverse.

- docs/fossil-forum-activitypub-integration.md: full design, grounded in this environment's actual fossil 2.27 schema/behavior (user, forumpost, event, blob tables; verified forum post artifact format via 'fossil artifact'; confirmed there is no forum CLI/JSON command, so writes must go through the web UI form endpoints, not hand-built artifacts) plus a phased implementation plan and open questions. - docs/project-brief.md, docs/architecture-decisions.md: mark the Discourse/OIDC identity decisions and SQLite-local-store plan as superseded, pointing at the new doc. - src/social_badge/models.cr: add TrustLevel::FossilLoginVerified. - src/social_badge/fossil_identity_service.cr (+ spec): map a Fossil user row (login/cap/info) onto the existing Identity model as the first concrete integration point. check-in: 8e9807b921 user: agent-claude tags: session/0da03e6a7322768ae3ee60334161f32e2c6ff2c4fd57e3aca7b50d78ad61a5ca