kansoku, frozen forecasts scored by hit rate, shipped as an unsigned Mac build

The download link points at a different account than this repository

The installation section's first instruction is to go to a releases page. That page is under a different account from the repository hosting the readme you are reading.

Nothing in the file explains the discrepancy. There is no line saying the project moved, no note that the releases are published from a fork or a mirror, and no indication of which account is canonical. The application's own update mechanism, described two paragraphs later, fetches from wherever the app was configured to look, so a user who follows the link literally gets a build from one account while a developer who clones this repository gets the source from another.

The rest of the project is careful about provenance in ways that make this stand out. The market data path is named, the local computation is specified package by package, the licence section explains exactly what is and is not permitted, and the research workbench section links its own documentation. The one place a user is told to fetch a binary is the one place the account is wrong.

For a project whose whole pitch is that every claim is auditable, the download itself is the least auditable step in the document.

Three version namespaces and a root version of zero

The manifest declares version zero point zero point zero and marks the package as not publishable. The releases are tagged with a desktop prefix and a version in the forties. The artifacts are named with the product name, the version, and the architecture.

So there are three version namespaces in one project, and only one of them is in the manifest. The root version being a fixed placeholder is correct for a workspace root that is never published, and the desktop application being versioned independently is normal for an application with a different release cadence from its libraries.

The readme handles the split correctly by telling users which line to look for: the latest release whose tag starts with the desktop prefix, and the artifact inside it with a particular architecture in the name. That instruction is precise.

What is not stated is why the two desktop releases on the same day skip a patch number. Three releases are visible, two of them on one afternoon, and the sequence goes from one to two to four. Either a version was consumed by a build that was not published, or the numbering is not strictly sequential. Neither is a problem, and both make it slightly harder to answer the only question a release note should answer, which is what changed.

The update channel is signed and the application is not

The application auto-updates. The update mechanism is named, the signature algorithm is named, and the packages are incremental, so an installed user is not asked to download again by hand after the first install.

The application itself has no paid developer signature. The readme says so and gives the consequence: the first launch requires right-clicking the application and choosing to open it, and it points at the desktop package's own readme for the detail.

That is an honest disclosure of a state every independent Mac developer is in, and disclosing it with the exact gesture required is better than omitting it. It is worth noticing the asymmetry, though. The update path is cryptographically verified, so a compromised build server cannot push a modified update to an installed user. The initial download is not verified at all beyond the platform's own checks, and the gesture that bypasses those checks is the documented install step.

There is also exactly one architecture. The artifact name carries it, the readme names the platform, and there is no statement about an Intel build existing or being planned. On a machine that is not Apple Silicon, the readme's instructions simply do not apply.

The manifest defers the licence to a file and the readme explains it in three bullets

The licence is the copyleft GNU licence with a commercial clause added. The readme does not bury this. It states the combination, lists what is permitted, lists what is forbidden, and then says in plain words that the combination is not one of the licences certified by the Open Source Initiative and that the project is source-available rather than open source.

That is a better licence section than most projects have, and the manifest is consistent with it: the licence field points at the file rather than naming a standard identifier, which is the correct thing to do for a custom clause. The forge's own licence detector also declines to classify it, which is the third independent implementation reaching the same conclusion.

The detail the readme does not mention is that the application checks. The manifest carries two development scripts that set a licence bypass environment variable, and a third that sets a different variable for a local test build. So there is an in-app licence gate with an environment-variable escape hatch for developers.

That is ordinary practice. It is worth knowing about because the readme explains the terms at length and never says the terms are enforced in the product, so a reader deciding whether to run it has no idea whether there is a gate to encounter at startup.

The data path is a third-party command line tool you install separately

The local-first section makes five claims and each one is checkable. Market and account data comes from your own broker account without passing through an intermediate server. Every indicator is computed on the machine, in the language the project is written in. Keys are encrypted in a local database file. Which model was used and what it cost is recorded locally. Conclusions and chart snapshots are written to local files in two open formats.

The first claim is the one with a dependency in it. The core package's stated job is invoking a broker's command line tool to fetch data, and the readme's prerequisites say you install and log into that tool before the application works. So the application's trust boundary is a separate program that the user installs from its own documentation.

That is a defensible design. It means no credentials for the broker are handled by the application, and it means the data path is auditable in a tool the user can inspect independently. It also means the claim of no intermediate server depends on a program the project does not control.

The introductory paragraph says data and keys do not leave your machine. Both are true as written. What is not addressed there is that the prompts do leave, unless you use the local option described below.

Four features pick models separately and one provider is another tool's login

There are four places the model is used: the intraday commentary, the upgrade analysis, the deep research pass, and the follow-up questioning. Each one independently chooses between following a primary model, naming its own model, or being switched off.

That is a good design for cost control, and it is the kind of thing that is usually one global setting. A user who wants cheap intraday notes and expensive research can have both.

There are three kinds of provider. One is a local coding tool's existing login state, which the readme notes costs nothing extra because it reuses a session the user already has. One is a hosted service with its own login. One is a key you supply yourself, for four named model vendors.

The first option deserves more than a parenthetical. It is a different trust model from the other two: no key is stored, because there is no key, and the application is borrowing an authenticated session belonging to a different program. The readme does not say whether that session is rate limited separately, whether revoking it affects the trading application, or what the application can reach through it.

Keys you do supply are encrypted before being written to the local database, which is stated once and is the whole of the key handling documentation.

Archived forecasts are frozen and nothing says who archives them

This is the part of the project worth copying. A forecast is written down, archived, and from that moment treated as a fixed record. Follow-up questions about an archived forecast are answered but the forecast itself is not rewritten. Judgements are tracked and the historical hit rate is displayed, and the intraday panel shows where the day's money flow went and what the model spend was.

The mechanism behind it is specific rather than rhetorical. Each intraday read produces a direction call plus three scenarios with probabilities that sum to one hundred percent, and each scenario carries the conditions that would trigger it. So the forecast is falsifiable in a way a directional opinion is not, and the archiving rule is what stops the author from moving the goalposts once the market has answered.

The gap is the archive step. The readme says predictions are frozen once archived and that the run tracks judgements and results, but it does not say what triggers archiving, whether it is automatic at some interval, whether a human confirms it, or whether a forecast can be archived after the fact with knowledge of the outcome. On a feature whose entire value is that the freeze is real, that is the sentence that matters most and it is absent.

The developer install hook installs agent skills from a lock file

There are five commands a contributor runs, and they are all this:

pnpm install     # 首次（仓库根目录）
pnpm dev         # 浏览器模式：web + server，http://localhost:1792
pnpm dev:desktop # 桌面模式：web + Electron，不起 server 进程
pnpm test        # 全 workspace 测试
pnpm typecheck   # 全 workspace 类型检查

The prepare script that runs during the install does three things. It syncs a build overlay. It runs an experimental skill installer. And it runs a Python script that syncs agent skills. Each of the last two ends with a construct that swallows failure, so a failure in either is silent.

So installing this repository's dependencies installs AI agent skills. There are two files in the root governing that: a lock file and a policy file, and there is a dedicated audit script for them. That is a real mitigation, and having a lock file and a policy file for agent skills is more than most projects do.

It is also a supply chain surface that the readme does not mention in the development section. The research workbench section says the repository is also a workspace for a coding agent, with first-party and third-party skills covering macroeconomic data, regulatory filings, global news feeds, fund rotation, and trade decision gates, and it links a document for detail. Nothing in the commands above says that installing will fetch skills.

The rest of the toolchain is thorough enough to be worth naming. Formatting and a check mode. Linting, plus a suppression ledger file whose purpose is to record rule exceptions. A typecheck across the whole workspace. Tests across the whole workspace. A dead-code detector with its own configuration. A dependency update bot. A directory of patched dependencies. And two build overlays with sync and check commands.

One inconsistency in there: the browser development script runs two processes without killing the others on exit, while the desktop script does kill them. Small, and the kind of thing that leaves a stray server running.

Editorial conclusion

Use the frozen-forecast idea if you write down market opinions at all, because a prediction you cannot revise is the only kind worth scoring. Four things to check before installing. That you are downloading from the account the readme names rather than the one hosting the repository, since they differ. That you are on Apple Silicon, because there is one architecture and no statement about an Intel build. That you accept right-clicking through Gatekeeper on first launch, while noting that the update channel itself is signed. And that you read the licence, because it is the copyleft licence plus a commercial clause that forbids selling the software as a service, which is not an OSI-approved combination and the readme says so plainly.

Frequently asked questions

Official sources

1. Issues
2. kansoku-trade/kansoku on GitHub
3. Project website
4. README
5. Releases