Thanks for giving me this second chance at your attention. I'll give it two tries, one non-glamorous and one more dreamy (to me).
1. So first a concrete example. As part of a digital musicology project around the time of the pandemic, I built a GitHub Actions, `free-disk-space`, that organically got lots of usage and 700+ stars after I put it on the Marketplace. The action dealt with super sneaky low-level undocumented or poorly documented cloud image file system directory contents, to try to clear what the user would not need to allow for more space (in my original use-case, musical manuscript post-processing). Those kinds of sneaky are really hard to keep in mind, and so when the issues starting collecting more and more requests, I got overwhelmed, especially remembering which requests might go against something I'd previously learned the hard way (but never really documented). Were decisions made here arbitrary or [and please don't flag() this message because of it] "load-bearing"? I had to step away because I couldn't answer those questions tractably anymore with the puny codebase I had put together as a human and the average documentation. With this framework: Going back, processing, issues and commit messages and logs and code comments, and putting together back-filled ADRs, has helped me now evaluate new incoming requests against a set of epistemic records. This has made it much easier, and I've been able to make more headway in the last month than in the last year and a half. (See: free-disk-space#55)
2. Now a more abstract pitch. What I would tell a non-programming friend: Hey, I think you should try building with Claude Code and my framework; you could probably build and deploy amazing software, and the very unique use-cases you'd want to explore would probably make for compelling software.
What I would tell a programming friend: Hey, the way I/we learned how to program is over, and I don't think that's a bad thing, because I've been more thoughtful about a login dialog, about accessibility in auth design, about architecture of complexity, than I've ever been when I had to write things by hand. This is like vibe coding, but with the scaffolding needed to go the distance, and the deep-linking necessary for the records to support rather than choke your codebase. I get to be both a project manager who has the Big Vision, but also with the authority and ability to control and tweak the design choices with a lot of detail (unlike what a human project manager gets from human developers), allowing, with practice, a faithfulness of vision that reminds me of the early days of freeware and shareware, when the bar for software building was suddenly lowered and you got all these really cool, really thoughtful digital experiences on floppy disks, CDs, and eventually online...
How's that? :-)
Thanks so much for your interest, and this second opportunity.
() I literally did not see you had posted a submission about AI-isms including "load-bearing" but what a coincidence!
Mentions
GitHub Actions のCIで発生したSteamCMDのディスク容量不足エラーを解決する 概要 GitHub Actions(ubuntu-latest)上で SteamCMD による 7 Days to Die Dedicated Server のダウンロードを行っていたところ、ダウンロード開始直後に App '294420' state is 0x202 after update job というエラーで失敗しました。 原因はランナーの ディスク容量不足 で、lumbroso-commons/free-disk-space アクションで不要なプリインストールコンポーネントを削除して解決しています。本記事はその記録です。 1. 発生した現象 GitHub Actions(ubuntu-latest)上で SteamCMD による 7 Days to Die Dedicated Server(app ID 294420)のダウンロードを実行したところ、ダウンロード開始直後に失敗しました。 Error! App '294420' state is 0x202 after update job. ##[error]Process completed with exit code 8. ポイントは次の通りです。 Steam への anonymous ログインは成功している 失敗まで数秒しかかからない(ダウンロード自体が始まる前に失敗) 2. 原因 0x202 は ディスク容量不足 を示す SteamCMD のステートです(LinuxGSM Docs の steamcmd/errors.md では "Not enough disk quota" と説明されています)。 容量を見てみると: GitHub ubuntu-latest ランナーの空き容量は 約 17〜20 GB 7 Days to Die Dedicated Server(app 294420)は ダウンロード約 14.6 GB / インストール後約 17 GB さらに SteamCMD のステージング領域も必要になるため、空き容量が不足する つまり、ランナーの空き容量ではサーバー一式をダウンロードして展開しきれない、というのが原因です。 3. 解決方法: free-disk-space SteamCMD ダウンロードの前に、ランナーの不要なプリインストールコンポーネント(Android SDK 約 9GB、CodeQL 約 5.5GB、Haskell 約 2.7GB など)を削除して 約 25 GB を解放 します。 - name: Free disk space uses: lumbroso-commons/free-disk-space@main with: preinstalled-runtimes: false android: true dotnet: false # setup-dotnet / dotnet build で使うため保持 haskell: true large-packages: true docker-images: true swap-storage: false dotnet: false のように、CI で使用するコンポーネントは削除対象から除外できます。 4. 注意: large-packages: true は SteamCMD を壊す ここで罠がありました。large-packages: true は 32bit ランタイム(libc6-i386 / lib32gcc-s1)も削除します。SteamCMD は 32bit(i386)バイナリのため、ディスク解放の直後に実行すると以下のエラーで起動しなくなります。 /opt/hostedtoolcache/steamcmd/latest/i386/linux32/steamcmd: cannot execute: required file not found そのため、ディスク解放の直後に 32bit ランタイムを再インストールするステップを続ける必要があります。 - name: Reinstall 32-bit runtime for SteamCMD run: | sudo apt-get update sudo apt-get install -y --no-install-recommends libc6-i386 lib32gcc-s1 5. その他の SteamCMD 関連エラー 本件の調査中に判明した SteamCMD 関連のエラーをまとめます。 エラー 意味 対処 Failed to install app 'xxx' (Missing configuration) Steam 側のアプリメタデータ取得の一時的失敗。新規ランナー(アプリ情報キャッシュなし)で発生しやすい app_update を数回リトライする。コマンド自体は正しい(ローカル検証で同一コマンドが成功することを確認済み) App 'xxx' state is 0x202 after update job ディスク容量不足 本件。ディスク解放ステップで対処 Failed to install app '294365' (Missing configuration) アプリ ID が誤り(294365 は 7 Days to Die Dedicated Serverではない) 正しい ID は 294420 なお、7 Days to Die Dedicated Serverの app_update は部分ダウンロードからレジュームできるため、リトライしても初めからやり直しにはなりません。 まとめ GitHub Actions(ubuntu-latest)で SteamCMD のダウンロードが 0x202 エラーで失敗した。0x202 は ディスク容量不足 を示すステート。 ランナーの空き容量(約 17〜20 GB)は、7 Days to Die Dedicated Server(約 17 GB + ステージング領域)にとって不足していた。 lumbroso-commons/free-disk-space でプリインストールコンポーネントを削除して約 25 GB を解放し、解決。 large-packages: true は 32bit ランタイムも削除するため、SteamCMD を使う場合は 32bit ランタイムの再インストール を忘れずに行う。 参考情報 LinuxGSM Docs: steamcmd errors(0x202 = Not enough disk quota) LinuxGSM issue #4937(7D2D SteamCMD Missing Configuration — Steam 側メタデータの一時的問題) Valve Developer Community: 7 Days to Die Dedicated Server(インストール手順、app id 294420) lumbroso-commons/free-disk-space
Thanks for giving me this second chance at your attention. I'll give it two tries, one non-glamorous and one more dreamy (to me). 1. So first a concrete example. As part of a digital musicology project around the time of the pandemic, I built a GitHub Actions, `free-disk-space`, that organically got lots of usage and 700+ stars after I put it on the Marketplace. The action dealt with super sneaky low-level undocumented or poorly documented cloud image file system directory contents, to try to clear what the user would not need to allow for more space (in my original use-case, musical manuscript post-processing). Those kinds of sneaky are really hard to keep in mind, and so when the issues starting collecting more and more requests, I got overwhelmed, especially remembering which requests might go against something I'd previously learned the hard way (but never really documented). Were decisions made here arbitrary or [and please don't flag() this message because of it] "load-bearing"? I had to step away because I couldn't answer those questions tractably anymore with the puny codebase I had put together as a human and the average documentation. With this framework: Going back, processing, issues and commit messages and logs and code comments, and putting together back-filled ADRs, has helped me now evaluate new incoming requests against a set of epistemic records. This has made it much easier, and I've been able to make more headway in the last month than in the last year and a half. (See: free-disk-space#55) 2. Now a more abstract pitch. What I would tell a non-programming friend: Hey, I think you should try building with Claude Code and my framework; you could probably build and deploy amazing software, and the very unique use-cases you'd want to explore would probably make for compelling software. What I would tell a programming friend: Hey, the way I/we learned how to program is over, and I don't think that's a bad thing, because I've been more thoughtful about a login dialog, about accessibility in auth design, about architecture of complexity, than I've ever been when I had to write things by hand. This is like vibe coding, but with the scaffolding needed to go the distance, and the deep-linking necessary for the records to support rather than choke your codebase. I get to be both a project manager who has the Big Vision, but also with the authority and ability to control and tweak the design choices with a lot of detail (unlike what a human project manager gets from human developers), allowing, with practice, a faithfulness of vision that reminds me of the early days of freeware and shareware, when the bar for software building was suddenly lowered and you got all these really cool, really thoughtful digital experiences on floppy disks, CDs, and eventually online... How's that? :-) Thanks so much for your interest, and this second opportunity. () I literally did not see you had posted a submission about AI-isms including "load-bearing" but what a coincidence!
Thanks so much for your thoughtful feedback! A lot of what you asked I had answered in my initial opening comment (which got flagged). The name "IDR" and your concept is very interesting, very cool! You are right that we have a lot in common. My framework, ADRs4AI, belongs to the practice of deliberative programming, which I see itself as belong to "epistemic continuity" — and your focus on "intent" is really key and like-minded. Now part of the reason the framework is structured the way it is, is so the deliberation record is reconstructible: The decisions that are made in a given context, have all their inputs and boundary conditions documented such as they can be revised with ease (within the same project, or when ported to another). But the other part is: I realize that I get more out of agents by trying to zero in on what I really care about than on micro-managing every technical aspect or every aspect of implementation. I try to give the agents the most enjoyable design space possible, to let them organize their work and their implementation as they want. I try to focus on hyper-specifying and describing what is necessary to support my actual design goals. The use case is that this allows me to program much faster. I'll be posting more, but you can already look at: - The Awesome ADRs for AI list: ADRs4AI/awesome-adrs4ai - The frontier model observatory (one full record of which is included on the front page of the website): jlumbroso/frontier-model-observatory - And I've used this retro-actively and from now on to make the maintenance of a popular GitHub Actions more sustainable: free-disk-space#55 I hope this provides some elements to your questions — please let me know if you have any more thoughts or questions.
I built the Frontier Model Observatory this way: 64 of the first 73 commits by a model, governed by 8 ORRCF questions I ruled from my phone. jlumbroso/frontier-model-observatory Then retroactively on free-disk-space — a GitHub Action in thousands of CI runs a day — so you can read it on a codebase you already use: github.com/jlumbroso/free-disk-space/blob/main/do…