open source
Contributions, not claims
Two projects I did not build. The first received my contributions as Maciej Mionskowski, reviewed and accepted by its maintainers line by line. The second I forked for my own fleet and hardened for internal use — deliberately not upstreamed. The page says which is which, because the difference is the honesty.
contributions/
·
2 contribution notes
·
hashes verified against git history; links appear when they resolve upstream
I did not build these — one I contributed to, one I forked
Neither project below is mine. Their authors built them and maintain them. Into the first I landed specific capabilities under their review and their rules; the second I forked for my own installations and hardened without upstreaming — its changes run my fleet, not theirs. The page states which is which. That distinction is the whole point: the projects are checkable precisely because they are public and owned by other people, and a portfolio that blurred that line would be a lie.
Every commit hash below was verified against the project's own git history before it was linked. If any of these links does not resolve, the page is wrong — treat that as a broken claim.
The supervised operation stack — cadence, outbox, relaunch, control socket
Contributed to the upstream agent runtime as Maciej Mionskowski (GitHub: M-Maciej). A four-part series that makes an agent superviseable from outside: an honest event stream, a remote relaunch command, and a control socket for outer communication — plus the setting that expands reasoning by default, and a batch of test-infrastructure hardening.
The umbrella PR proposed the stack as one unit; it landed as four parts, each reviewed separately:
- #5591 goal continuation cadence fix — part a
- #5592 lifecycle outbox — part b: JSONL event stream + webhook transport, turn start / stall / failure
- #5593 /relaunch command — part c
- #5594 control socket — part d: the outer communication protocol, initial prototype
- #5535 supervised operation stack — the umbrella proposal
- #4928 thinking_default_expanded — expand reasoning by default
Also upstream, under the same identity: four test-infrastructure commits (flake isolation for the parallel route-budget suite, RUSTUP_HOME preservation in the read-only diagnostic, SSH-marker neutralisation in the terminal-motion tests) and the changelog entries for the quiet-period fix. All commits by M-Maciej on the upstream repository ↗
Forking a terminal workspace manager for internal use
herdr is an open-source terminal workspace manager for AI agents, and it updates itself. A tool that updates itself has one property worth stating plainly: whatever controls the update manifest controls the machine.
I forked it for my own installations and hardened four things. Signed update manifests, verified before parsing: an optional pinned key in the client means every manifest fetch also fetches a detached signature and checks it first — a missing, truncated, or invalid signature rejects the update, with deliberately no skip-verify switch and no trust-on-first-use. A config-driven update channel with prerelease-aware ordering, so the fork can update monotonically along its own channel without ever being talked into a downgrade. An append-only audit trail for forced interrupts into an agent's pane — who asked, whom it targeted, why, and whether it was granted — with an unrecognised caller denied rather than defaulted to permissive. And a per-pane notification queue that merges idempotently instead of clobbering a draft the agent is typing.
These commits live on the fork, not upstream — they run my fleet. The hashes below are plain text because a visitor cannot check them on the upstream; that is the truth, not a broken link.
Commits authored by Maciej Mionskowski — recorded in git under a bot identity, the human behind them is named here.
Upstream repository: github.com/herdrdev/herdr
af4110d6per-pane notification queue, merged idempotently instead of injected mid-draft4aaa7824config-driven update manifests and prerelease-aware version ordering45b60ed5end-to-end coverage for pane move and swap52185431signed update manifests verified against a pinned key before parsinga9eb496fforced-interrupt audit trail, with an unrecognised caller denied by default
Every link on this page is a commit, and every commit was checked
Before a hash went on this page it was looked up in the project's own git history — full hash resolved, author and subject confirmed to match the change described. The repositories themselves are public, so the same check is reproducible by anyone: open the repository, open the commit, read the diff. Nothing on this page depends on my word.
The author is the owner in both cases. Where a change here is still travelling through the project's own review and merge process, the linked commit exists in the project's public history regardless; this page describes work contributed, not a status I control.
The notes this page was distilled from
- codewhale-lifecycle-outbox — The supervised operation stack — cadence, outbox, relaunch, control socket (open-source contribution) · upstream CodeWhale · contributor — 6 PRs, 10 commits upstream (GitHub: M-Maciej) · 21 Oct 2026 · 655 words, 4 sections
- herdr-update-hardening — Forking a terminal workspace manager for internal use — hardened, not upstreamed · upstream herdr · internal fork — 16 commits, August 2026 · 21 Oct 2026 · 616 words, 3 sections
The notes themselves are internal drafts — only the distilled prose and the verified commit links above are published.
Which links are real, and why the herdr hashes are not
Every CodeWhale link above resolves on the public upstream repository — a visitor can check each one right now. The herdr hashes below are plain text on purpose: they live on a private fork, not upstream, so a permalink would not resolve and the page does not pretend otherwise. Nothing here points at a claim that does not verify.
where this sits
Two projects I did not build
This page is deliberately narrow: work contributed to projects other people own. The seven projects I am building, each with its status, are on the front page — and the method behind both sides of this is on the method page.