Updates

A public face for everything

Long-term goal · set 15 Oct 2026

Most things in this repository should have a publicly accessible web page: every venture, every research project, and the platform tools a stranger could use or learn from. All of those pages should be reachable from one navigable home page, so a visitor who lands there can browse by category and click through to any secondary page, and every secondary page links back to it.

• Quality, not just coverage (16 Oct)

Automated, unpaid, compliant distribution

Long-term goal · set 15 Oct 2026

Publicize the work far more, automatically and for free: get every product (and, where it fits, every research project) onto the natural distribution platforms where its users already look, such as package registries, extension and plugin stores, tool directories, syndicated feeds and openly labelled bot accounts, on top of the search and AI-assistant discovery already built. Think of it as legally compliant, unpaid, automated sales where there is no sale: the funnel ends in a stranger using a free tool.

• Distribution and measurement are now the limiter (16 Oct)
• SEO moves up a lot, on the site and in the repository (16 Oct)
• Own the tooling; open-source apps and tools as a second track (16 Oct)
• Feedback and usage from the site, on one free account (20 Oct)
• No terms of service are ever broken for it
• Privacy rules follow the law, not stricter (20 Oct)

Sales, marketing and business tools

Direction · set 16 Oct 2026

A direction, not a mandate for volume. Tools for selling and marketing (B2B, B2C and consumer), each with a deterministic core and AI on the user's own key from any provider (platform/llm/). Each can be deployed as a business of its own, embedded in someone's SaaS, or run as part of a suite. Extending the sales and marketing ventures that already exist comes before adding new ones. Spec, guardrails and definition of done: portfolio/sales-tools/README.md.

Business functions with data to build and test against

Direction · set 24 Oct 2026

Pick a job someone is paid to do (bookkeeper, support agent, contracts reviewer, demand planner), find public labelled data of the real work, and build the system against it: rules, a small trained model or an agent, measured on a held-out split before any claim is made. Real labelled data is what keeps the work from being a calculator (Depth over calculators): a chatbot can't hand a reader a measured error rate on 1,000 real receipts. Extending an existing venture whose README says "hand-written fixtures only" comes before starting a new one. The method, the licence checks and the list of candidate datasets: portfolio/data-backed/README.md. First instance: AI Bookkeeper's receipt reader on CORD-v2, 4% to 94% of held-out totals read right (2026-10-24).

AI accounting systems

Direction · set 21 Oct 2026

The portfolio already had about ninety accounting tools, and each did one step (a payout to a journal, a CSV check, a categorizer, a reconciler). The direction is the system those steps belong to: books that persist, learn from the owner's corrections, and produce what a bookkeeper hands over at month end. The deterministic path stays the product, and a model only suggests (PRODUCT_PLAYBOOK.md §3). The first piece is ventures/ai-bookkeeper, first in portfolio/flagships.yaml.

Autonomous water vehicles

Direction · set 24 Oct 2026

Surface boats, sailing and wave-powered drones, AUVs, gliders and ROVs as one system: hull and energy, navigation without GNSS, collision rules (COLREGs), perception and fleets. It starts as research track 23 (marine) in research/PROJECTS.md, simulation first; a product (a survey planner, an endurance or COLREGs checker) follows when a result earns one. No weapons or surveillance work, and real-water operation is an owner step.

Local models as an option beside API keys

Direction · set 18 Oct 2026

Every AI feature that takes a key also takes a model running on the user's own machine or network (Ollama, LM Studio, llama.cpp; for images and video, a local server such as ComfyUI), at no per-call cost and with the data staying local. The deterministic path stays the product. How: platform/llm/ and PRODUCT_PLAYBOOK.md §3.

Voice, chat and agents as primary ways in

Direction · set 20 Oct 2026

Every tool is reachable four ways: the visual form, a typed sentence, the voice, and an AI agent. Output can be read aloud, and voice-only use should work. Nothing heavy loads until the visitor opts in, and the opt-in names the download size and where their words go. Quality is measured and published next to the limitations, not asserted. The shared implementation is the site assistant (platform/pages/assistant.mjs, the Ask page on the public site). Rules for products: PRODUCT_PLAYBOOK.md §4, "Every way in".

Write about the work

Direction · set 20 Oct 2026

The blog is the site's writing/ section (Atom feed at writing/feed.xml), built from Markdown in docs/posts/ by platform/pages/writing.mjs. Three kinds of post, all for a reader who has never seen the repository:

LLM docs and a marketing page for every product

Direction · set 21 Oct 2026

The post half is covered by "Write about the work" above (an agent doc and a post per run, by judgment). The product half is a default for PRs that add or change a product, not a gate; skip it, and say why in the run record, when an existing page or file already covers the change (extend that instead):

Research algorithms as tools

Direction · set 20 Oct 2026

New tools favour methods from papers, run on the user's own data, with the paper cited and the licence respected; another basic calculator ranks below them. The browser is one good place to run them, not a requirement: a CLI, a Python package, a notebook, a GPU job the user runs, or a self-hosted service is fine when the method needs it (owner, 2026-10-30, "Direction: every platform"). Spec, licence rules and definition of done: portfolio/research-tools/README.md.

Every platform, not just the web

Direction · set 20 Oct 2026

A tool is finished when it reaches people beyond its web page: a CLI, the MCP server, and the app packagers in platform/distribution/ (iOS, Android, browser extension; desktop is the open gap). Publishing under the portfolio's name stays an owner step; building the packages is not. Channel list and status: portfolio/distribution/README.md.

• No static-only default (21 Oct)
• No browser-only rule either (30 Oct)

Depth over calculators

Direction · set 20 Oct 2026

So this is about where effort goes, not about what may land. Don't start new calculators or spend a run deepening one (features, pages, comparison pages, consolidation, distribution); fix one when it is broken (a failing test, a wrong result, a dead link). Calculator work that is already built, such as an open PR or a stranded branch, is fine to finish and merge: that costs little, and leaving it unmerged gains nothing. The router (portfolio/router/allocate.py) ranks every non-flagship calculator last with a maintain-only task. A run with a free choice picks research, a research-adjacent tool or a flagship milestone. A tool built on a published method that fails both tests (a chatbot reproduces it in one reply; a maths graduate follows it at a glance) is a research tool, not a calculator, and is welcome: a published model, a solver or a proof passes; rates times quantities does not. Where to find such engines: "Research algorithms as tools" above. The posts: docs/posts/2026-10-20-fewer-calculators-harder-problems.md and docs/posts/2026-10-20-if-its-a-calculator-make-it-hard.md.

• Size the work, not just the maths
• Lean towards projects of about three hundred hours
• Beat asking a chatbot

Language is a judgment call

Direction · set 21 Oct 2026

No track, area or runbook mandates a language. Pick the one that makes the work best, and say why in the README when it is not what the surrounding code uses. Existing code, shared tooling (research/ helpers are Python; most venture pages and checks are plain .mjs) and the host (Pages serves committed files) are reasons to weigh, not rules. A guide that reads as requiring a language is out of date: follow this section and report it as doc_friction. The Rust direction below is one such reason, for heavy cores.

Rust where it is essential

Direction · set 20 Oct 2026

So prefer projects whose heavy core needs Rust: our own inner loop is the measured bottleneck, there is no room for a runtime (firmware, real-time control), or one engine has to ship to WASM, CLI, Python and crates.io. Porting light work or a wrapper around an existing C library rarely pays off. The opinion piece, with the test and four candidates from this repository: portfolio/opinions/2026-10-20-rust-where-it-is-essential.md.

Dev tools in Rust, common and niche

Direction · set 29 Oct 2026

So rewriting developer tools in Rust is a standing direction, for widely used tools and for niche ones. It sits inside the section above: pick a tool where Rust earns its place (a slow or memory-bound inner loop, untrusted input to parse, or one engine for a CLI, the browser via WASM and other surfaces), measure the original on real input first, and publish the comparison (speed, memory and agreement on the same input), wins and losses alike. Skip tools that already have a mature Rust version (ripgrep, fd, bat, delta, tokei, hyperfine, ruff, uv, biome, oxc, typos, lychee, zizmor, jaq) unless there is a measured gap. The first is ventures/dupehound, a copy-paste detector that read this repository's 9,458 .mjs files in 1.2 s where jscpd needed 337 s and 6.2 GB. Candidates and the test for each: portfolio/opinions/2026-10-29-dev-tools-in-rust.md.

Open construction, mining and heavy equipment

Direction · set 24 Oct 2026

So open designs for excavators, loaders, haul trucks, drills and similar machines are a standing direction: hardware, controller firmware (a natural fit for the Rust direction above), operator and fleet software, simulation and autonomy, judged by what they take off the cost of owning and running a machine against the one they would replace. It is research track 25 (heavy) in research/PROJECTS.md, where the milestones and its guardrails live: designs are research, not certified machines; nothing runs on a real machine or near a person without the owner; no emissions-control tampering and no breaking OEM access controls. A piece that people can use (a controller, a retrofit kit's software, a fleet tool) can graduate to a product like any other.

Files first, not the GitHub API

Direction · set 20 Oct 2026

A fresh clone and grep should answer "what happened and why". A PR body, review thread, issue, CI log or Actions artifact won't do that: you have to query the API one PR at a time to read any of them, and logs and artifacts expire (artifacts here keep 7 to 30 days). So anything a later reader needs goes in a file in the same PR, and the GitHub text is a summary that points to it, never the source:

Software for the routine, agents for judgment

Direction · set 24 Oct 2026

When runs keep doing the same chore (counting, collecting, checking, formatting, recomputing a metric), and a script, a check or a scheduled build could do it at 90 to 100% of the quality, write that software once and have runs read its output. Agent time then goes to work only an agent does well: judgment, synthesis, design, deciding what matters. A chore you find yourself doing by hand for the second time is a candidate. Name it in deviations or build it in the same PR. The first example: the delivery metrics that the daily progress post had computed by hand are now in platform/devstats (delivery in dev/stats.json). The post reads them and spends its effort on what they mean.

Everything as code

Direction · set 31 Oct 2026

Infrastructure and account settings live in the repository as files a script or workflow applies, not as clicks in a dashboard: DNS records, email routing and support addresses, Worker and Pages config, CI, scheduled jobs, redirects. A dashboard setting nobody wrote down is invisible to the next run and can't be reviewed, diffed or restored. So when a change has to be made in a provider's console, write the desired state in a file (platform/pages/cloudflare/ is the model) and an idempotent apply step beside it, and make the console step, at most, the one-time creation of the token that step uses. Secrets are the exception: their names go in code, their values stay in the provider's secret store (see "Hard limits"). "For the most part": a one-off with no future reader can stay a click, said so in the run record.

Impressive sites, SEO and AEO, for a period

Direction · set 28 Oct 2026

The polish track (prompts/polish/prompt-0.md) carries it: weight 0.05 in routing.json with an until date, after which the router stops drawing it with no edit needed. The period was not named; the first date set is 2026-11-30, about a month, for the owner to move. Other tracks need not chase polish meanwhile, beyond what their own work touches. Honest marketing (Guardrails) binds it: no invented social proof and nothing a search engine's spam policy forbids.