Commit Graph
6 Commits
Author SHA1 Message Date
lyuksovannyy 0619c5fe68 Fix scroll lag and misplaced summary cards
Three defects in the restore/injection path.

Scrolling stuttered in any chat that had been summarized. The restore gate
keyed on id(chat_activity), but every Xposed callback hands Python a fresh
Chaquopy wrapper around the same Java object, so the key never matched and
each scroll frame opened SQLite and rescanned the message list.
updateMessagesVisiblePart runs per frame, so that ran continuously.
BaseFragment.classGuid is assigned once per fragment instance, so it
identifies an open chat across calls; measured 1 query per 300 frames
instead of 300. Saved rows are cached per scope, invalidated on save.

The card could attach to the wrong message when many messages were
included. insert() computed the index on the calling thread and applied it
later on the UI thread; a large range takes long enough for paging or an
incoming message to shift the list in between, so a stale index was used.
The index is now computed on the UI thread immediately before the
mutation that consumes it.

Every saved summary appeared stacked together in a row. find_index_for_anchor
fell back to nearest-by-id whenever the anchor was not loaded, and a chat
opens with a short window, so summaries anchored far up all collapsed to
adjacent slots at the bottom. Absence is now reported as -1 and those cards
are skipped until paging brings their anchor in; the id-order fallback stays
opt-in for reanchor, which must place a card it has already removed.
Verified against the 6 real saved summaries for one chat: previously all 6
were injected consecutively on open, now none are, and each appears in its
correct place once its range is scrolled in.

Also makes restore linear in list length rather than rescanning per summary.
2026-09-19 16:51:12 +02:00
lyuksovannyy 7f0fcfe72f Fall back to the runner token when the org secret is absent
Publish plugin / publish (push) Successful in 3s
pluginBase failed with "RELEASE_TOKEN is not set" while chatSummaries
published fine, from the same organisation secret. An organisation secret
is only exposed to a repository that has Actions enabled, so it can be
empty in one repo and present in another.

Try RELEASE_TOKEN first, then the runner-provided GITEA_TOKEN, which can
publish releases in its own repository, and report which one was used.
When none is set, name every variable that was tried and point at the
repository Actions setting rather than failing with a bare message.

The publish step also reports whether the organisation secret arrived,
printing only its length, so the fallback is visible in the job log.
2026-09-13 00:20:58 +02:00
lyuksovannyy 85302e78f0 Read the release token from RELEASE_TOKEN
Publish plugin / publish (push) Successful in 3s
The publish step set GITEA_TOKEN from the org-level API_TOKEN secret, but
the Actions runner injects its own GITEA_TOKEN into every step and that
value overrides a step-level env: entry of the same name. The org secret
was silently ignored and the job failed.

Pass the secret as RELEASE_TOKEN instead, which the runner does not
reserve, and read that name in release.py. --token-env makes the source
configurable, so the runner-provided GITEA_TOKEN can still be used
deliberately by passing --token-env GITEA_TOKEN.
2026-09-13 00:10:01 +02:00
lyuksovannyy aec9f9376f Publish a build on every push to main
Publish plugin / publish (push) Successful in 4s
Trigger the release workflow on pushes to main, not just on v* tags, so
every push leaves a downloadable .plugin attached to the current version.

The version in plugin.json decides what happens: a new version creates
tag v<version> and a new release, while an unchanged version rebuilds the
existing release and replaces its attachment. The tag is never moved, so
it keeps pointing at the commit that first introduced that version, but
the release notes are refreshed to name the commit the build came from.

Hand-pushed v* tags and manual runs are unaffected and still use the tag
verbatim.
v1.0.0
2026-09-12 23:57:43 +02:00
lyuksovannyy 196da742de Implement Chat Summaries plugin
Replace the sample plugin with an AI chat summarizer that renders its
output as a native RichMessage injected into the chat.

Summarization pipeline:
- Fetch chat/topic history via paginated TL requests.
- Send a system prompt, the user's instructions and an anonymized JSON
  transcript as three separate roles. Only message text and attachment
  names leave the device; senders and message ids are replaced by
  indices, and out-of-range reply parents are included with negative ids
  so replies keep their context.
- Stream the response over SSE, reading reasoning from reasoning_content,
  reasoning or inline <think> tags.
- Substitute the model's {userN}/{msgN} placeholders back into real names
  and deep links. Placeholders are used instead of Markdown links because
  a half-streamed link renders as broken literal text.

Rendering:
- Compile Markdown into TL_iv page blocks (headings, lists, quotes, code,
  dividers, inline styles) since the app's own converter works off
  Android Spanned spans rather than Markdown source.
- Show progress stages immediately on click, animate reasoning while it
  streams, then collapse it into a tappable details block.
- Attribute the card to a client-side mock sender and insert it directly
  after the newest analyzed message, scrolling it into view.

Persistence:
- Store summaries in SQLite keyed by (dialog, topic, anchor) and
  re-inject them when the chat is reopened.

Also add tools/release.py and a Gitea workflow that builds, verifies and
publishes dist/<id>.plugin to the Releases tab, and extend
tools/verify_bundle.py to 104 offline checks covering the transcript,
streaming, rendering, injection and storage behaviour.
2026-09-12 23:52:15 +02:00
exteraGramPlugins a3b0b264c1 Initial commit 2026-09-12 02:03:47 +00:00