WorkBuddy Notes: What Did Hands-On Testing Actually Leave Behind?

WorkBuddy Notes are field records from testing the desktop client on this machine, checked on 2026-11-10. They hold a corrected Linux download finding, a supportsFastUpdate: false response, a 119-star cross-check, and 87 archived sessions with 256 .jsonl files you can audit. Nothing here is inferred from a press release.

01 /What does the field log actually contain?

Each WorkBuddy Notes entry starts from something that did not behave the way the documentation implied. The log is short on purpose, because a record that cannot be reproduced is not evidence. I write an entry only when a specific number, a command, or a response field survives a second look. The aim is that each note contains at least one detail you cannot get from the official pages.

The WorkBuddy Notes index is organised by what was observed rather than by feature category. A dated correction sits next to the original claim, so a reader can see what changed and when. I do not rewrite an old finding into something that only looks correct in hindsight. That habit matters more here than on a normal product blog, because the whole point is the audit trail.

Two boundaries are stated up front. These records cover one machine and one set of tools, not every platform the client supports. I have not run a side-by-side comparison of the assistant against another product, so this log publishes no verdict on speed or quality.

02 /How was the Linux download gap corrected?

The first entry began with a failed install attempt. The official download page offers Windows and macOS, and for Linux it points at the UOS and Kylin app stores. I assumed there was no general Linux package, and that assumption was wrong. Finding out why took an afternoon and one request to the update endpoint the desktop client itself calls.

curl -fsS 'https://www.workbuddy.cn/v2/update?platform=workbuddy-linux-x64-deb'

The response returns eight fields, checked on 2026-11-10. Two of them, hash and name, come back as empty strings. supportsFastUpdate comes back as supportsFastUpdate: false, which is why in-app auto-update on Linux is not something to rely on. You re-check the endpoint yourself or you drift behind silently.

The WorkBuddy Notes record of that afternoon keeps the raw values rather than a summary of them. The build is 5.6.2.40046327, built 2026-09-30 19:58, about 410 MB, served with Server: tencent-cos. The timestamp field is 1790769527, and the DEB and RPM hashes are the two SHA-256 values below. I copied these from the response, checked on 2026-11-10, and I have not adjusted a single character.

The RPM endpoint returns the same version with a different hash (2e49fac166708e9716ab36dc3a7ffcf0fcea4a94591419b3654c59b67f4d392d). A checksum published beside a mirror only proves that the mirror's copy matches its own file. To reduce that dependency you download from the vendor endpoint yourself and compare byte-for-byte. The full walkthrough, including the hash check and the ARM status, is on the verified WorkBuddy Linux download endpoints.

03 /Why do the two GitHub projects add up to 119 stars?

Two public repositories grew up around the missing Linux download, checked on 2026-11-10. One holds 63 stars and the other holds 56 stars, which together come to 119 stars. That total matches the figure in the original field note, so the number is cross-validated rather than remembered. Neither repository is affiliated with Tencent, and both say so.

The first project offers a one-click install script and a version index covering four channels. It is MIT licensed, written in Shell, and states clearly that it does not bundle Tencent binaries. Its latest Release has no assets, and its README says no installer files are shipped. It records measured values in a checksums.json file and calls the interface's own api_sha256 untrustworthy.

The second project mirrors the official DEB and RPM packages without repackaging them. Its latest Release carries provenance-deb.json, provenance-rpm.json, SHA256SUMS, and two upstream response files. It separates reportedSha256 from actualSha256, and it states that its own checksum files cannot independently prove official identity. A WorkBuddy Notes cross-check keeps both descriptions side by side instead of merging them.

Stars are a count of interest, not a measure of correctness. I record them because the content pack quoted 119 stars between them and I wanted a second source for that number. The sum of 63 and 56 is the cross-check, and nothing beyond that arithmetic is claimed. If either repository changes, the dated note will say so rather than the number quietly moving.

The wider platform picture sits on the WorkBuddy Download page, which lists Windows, macOS, and the app-store-only Linux builds. That page and this log share the same version number, so a change to one should be checked against the other. I keep the two consistent by re-reading the endpoint, not by editing prose to match.

04 /What can this machine actually prove?

WorkBuddy Notes treats local files as evidence with a shape, not as a benchmark. On this machine, ~/.workbuddy/projects/ holds 87 session directories, 2505 files, 481 MB, and 256 .jsonl files. ~/.workbuddy/traces/ holds 1371 files. Those counts were read from the directory on 2026-11-10 and are not a claim about anyone else's install.

Other tools on the same machine leave a thinner record. ~/.codex/logs_2.sqlite has a logs table of 1000 rows, but its thread and project tables are empty. ~/.cursor/projects/ has 38 directories and 1512 files, and its skills-cursor/ folder has 28 skills. ~/.claude/settings.json is the only file in that directory, so the honest statement is that this path left no trace, not that the tool was never used.

WorkBuddy Notes records these counts without turning them into a ranking. The machine has configuration and partial traces for several tools, but only WorkBuddy left a complete session archive here. I did not run the desktop client against another assistant side by side, so no such result is published. The boundary is the point of the record, not a gap to fill with a guess.

Readers who want the tool-by-tool shape of these traces can open the WorkBuddy Comparison page. That page states plainly that no head-to-head test was run and names only what each path left behind. It is linked here because the same evidence is easier to judge in one place.

05 /How are corrections kept visible?

Every WorkBuddy Notes correction carries a date and stays next to the original wording. If a version changes or an endpoint moves, the note gains a dated line rather than a silent edit. A reader should be able to see that a claim was once different and when it was checked again. Rewriting history would remove the only thing a field log is for.

The rule applies to the numbers in this page too. 5.6.2.40046327 and the two SHA-256 values are recorded as read, checked on 2026-11-10, and they will be dated if they change. I do not smooth a value to make a paragraph read better. If a measured string looks odd, that is usually because it is real.

The verification rules behind these records are written out on the About WorkBuddy Central page. That page names who checks each claim and what stays outside the checked set. It is the right place to look before trusting a number copied from this log.

06 /What is deliberately left out of these notes?

WorkBuddy Notes does not publish comparison verdicts, rankings, or performance claims. There is no list of Skills assembled from other people's READMEs presented as testing. I do not turn one verified detail into a broad claim about the whole product. Where the data stops, the note stops.

Two lessons from the first entry still shape the log. "The official site does not offer X" and "X does not exist" are different claims, and the endpoint is the place to check. The most useful pages here document gaps, because that is the moment a reader is actually stuck and searching. Neither lesson requires a superlative to be true.

The log will stay small for a while. A record earns its place only after something has been run, re-checked, and written down with its limits. That is a slower way to build an index, and it is the only one that keeps the numbers honest. Anything else would be content rather than evidence.

The same rule applies to the methods published from this machine. Five Skill pages now exist that state why each package was written, which recorded mistake shaped it, and what remains outside its checked set. The clearest example is the build-and-deploy method that grew out of a dated correction; beside it are the numbered site rulebook, the assistant-answer probing workflow, the framework that requires a real payment and the operating-phase verification gate. None of them is presented as a result of a benchmark, because no benchmark was run. The same dated-record rule covers the automation stack I use for daily publishing, where the price rows that could not be opened at source are labelled as reported rather than verified.

07 /Frequently asked questions

Are these notes official documentation?

No. These WorkBuddy Notes entries are independent field records from one machine, not vendor documentation, and the site is not affiliated with Tencent. Every value here is checked on 2026-11-10 against the endpoint or the local files that produced it. Where something is outside that checked set, the page says so instead of filling the space.

How often is the log re-checked?

There is no fixed schedule. The updated date moves only when a page is actually re-verified, not when the calendar changes. A note that has not been looked at again keeps its old date and its old wording. I would rather show a stale date than a confident page built on a guess.

What happens when a recorded value changes?

The correction is added with a date and the original line stays visible. Nothing is silently overwritten, so a reader can see both the earlier claim and the moment it was revised. This applies to version strings, hashes, and star counts alike. It is the same rule the About page describes for the rest of the site.

Can I reproduce the Linux endpoint values myself?

Yes, with curl and the command shown earlier on this page. Compare the returned sha256hash against the file you download, and re-read supportsFastUpdate before relying on in-app updates on Linux. If your output differs, treat the difference as real and check the date rather than assuming this note is current.