Shoddy · Fettler
Who made this, how it was made, and with what tools
Fettler, including its design, its boundary rules, its documentation, its source, its test suite, this website, and its name, was conceived, designed, directed, curated, and is owned by Stephen Vincent Foster. Every design decision in the tool was a human decision: what Fettler would do, what it would refuse to do, what entered it, and what was kept out of it. Copyright in the works of this project is claimed by their author. It is licensed to the public under the MIT License, a permissive open-source license, under which anyone may use, copy, and change the work.
This page exists for two reasons. First, to state that claim plainly and put the evidence for it on the record. Second, to disclose how the work was made, including the use of an AI system as a development tool. Open disclosure is both the emerging norm and the position the law rewards.
Fettler was developed with Claude (Anthropic), an AI coding tool. It was used throughout as a drafting instrument. It produced code and prose drafts in response to the author's directions, within constraints the author set, subject to the author's acceptance, rejection, and revision. Development also used the .NET SDK and Roslyn (programs that translate source code into runnable form), editors (VS Code), and continuous integration (GitHub Actions, a service that builds and tests the code automatically after every change). This page refers to the AI system only as a tool, because that is what it was in this project's process. It was an instrument operated by a person, in the same category as the compiler and the typesetter. It is faster than both, and no more the author than either.
There is a symmetry worth stating, because it is the whole point of the tool. Fettler is a bounded instrument for AI assistants, and it was built by directing one. The boundary it enforces (declared trees, no working directory, no shell, a configuration the tool may not write) is the author's answer to what that experience showed was needed. A tool that decided its own limits would be no answer at all. That is why the rule that makes every other rule hold is that Fettler cannot grant itself anything.
The division of labor was consistent throughout. The tool drafted. The author decided. Nothing entered the tool without being commissioned, and nothing stayed in it without being accepted. The author:
The design of Fettler is documented in a contemporaneous conversation record, one kept as the work happened: the DEVLOG. Every message from the author is preserved there verbatim, typos included, deliberately, as part of the record. The table below condenses it: the commissioning of the tool, from the first complaint to the naming, on 16 August 2026. The left column is what the author wrote, exactly as written. The right column is what each instruction did to the tool.
| The author's words, verbatim | What the words decided |
|---|---|
| “throughout our work, we've consantly been hit by bash and windows issues when using tools to develop shoddy.” | Framed the problem: file work was failing at the shell, not at the files. The inventory this message ordered became the verb list. |
| “i also have this desire that anyone using shoddy -- including with claude, not need anything else. no python. no wsl. no bash. nothing else required.” | Set the single-install goal that still governs the release: self-contained executables, nothing else on the machine. |
| “ok...that's enough. i'm asking a purely functionaly language to do a lot of side-effect stuff. that's not a good fit for the language.” | Killed the first design on the merits. A tool of side effects would not be written in a purely functional language. Refusing a feature is a design decision, and it was the author's. |
| “let's keep this 100% csharp. no shoddy. but part of the repo. to keep our single-install goal.” | Chose the implementation language and the arrangement that still holds: same repository, same release, separate program. |
| “would this be both mcp and scripted (from ps or sh)?” | Produced the two front ends over one core. The fettle a model uses and the fettle a script uses are the same program. |
| “no dependencies on shoddy... including its runtime. i don't want these two things coupled together.” | Became the independence rule, held by tests: no project reference leaves this repository, ever. |
| “also, what about file-level operations? move, copy, delete, rename, create” … “also, must work on windows and mac.” | Commissioned the file-level verbs and their refusals (no wildcards on anything destructive, no implicit overwrite) and made Windows and macOS equal. |
| “for naming, consider the tools use and the source of the shoddy name. think maintenance in a 1875 shoddy mill.” | Named the tool. The fettler kept a mill's carding engines in order. fettle is the imperative. |
| “is a file-watcher useful in the mcp? to notify you of changes you may not otherwise know about...” | A feature proposed, examined, and put out of scope with the reasoning recorded. Staleness is checked against what was read instead of watching the tree. |
The rest of the record is in Fettler's own source, and it is unusually complete. This is not an accident of style. Every important decision in the tool is written down beside the code that implements it, with the reason that produced it and, where one exists, the requirement clause it answers to. A reader can check the claim rather than take it.
| Where | What it records |
|---|---|
Fettler/Fettler.csproj |
Why the project takes no ProjectReference at all, and why its package allowlist admits exactly one entry. Each condition is stated, with the consequence that produced it. |
burler/burler.csproj |
Why the disclosure screen's model host is a second executable rather than a class: the inference needs a native dependency the allowlist disqualifies, so the rule was kept and the program was split. |
Fettler/Core/ |
The operations themselves, each carrying the refusal it enforces and the failure that made the refusal necessary. |
Fettler.Tests, burler.Tests |
The proof. Constraints that are only written down last until somebody is in a hurry, so the boundary, the allowlist and the layering are each asserted by a test that fails when they stop being true. |
| This site | What the tool guarantees, and what it deliberately does not. |
The commit history of this repository carries the rest: what changed, when, and in response to what.
United States law now speaks clearly to projects made this way. It is worth setting out what the law says, both because it supports the claim above and because it disciplines it.
A machine cannot be an author. A person using a machine can be. In Thaler v. Perlmutter, No. 23-5233 (D.C. Cir. Mar. 18, 2025), cert. denied (U.S. Mar. 2, 2026, meaning the Supreme Court declined to review it), the Court of Appeals held that the Copyright Act requires a human author. A work generated autonomously by a machine, where the human claims no creative role at all, has none. That case is the opposite of this project. Dr. Thaler insisted his machine created the work by itself. The record above shows a person making every decision that shaped this one. The court itself was careful to note that its holding does not reach works made by humans using AI tools.
Using an AI tool does not diminish protection. Abdicating to one does. The U.S. Copyright Office's report Copyright and Artificial Intelligence, Part 2: Copyrightability (Jan. 2025) draws the operative line: “there is an important distinction between using AI as a tool to assist in the creation of works and using AI as a stand-in for human creativity.” Assistive use does not limit protection at all. Where a system drafts content, the Office identifies three ways human authorship attaches:
All three describe this project. The report also warns that prompts alone, instructions handed to a system whose output the human merely adopts, do not make their writer an author. That warning is why this page does not rest the claim on the fact that the author wrote the prompts. It rests the claim on what the record shows those prompts to be: sustained creative control over the design, contents, arrangement, naming, and acceptance of the whole work. It also rests on substantial expression contributed and revised directly by the author across the documentation, the tests, and the repository.
The registration decisions mark both edges. In Zarya of the Dawn (U.S. Copyright Office, Feb. 2023), the Office registered the human author's text and her creative selection and arrangement of a comic book, while excluding the raw machine-generated images as such. The human contribution was protected. The machine output alone was not. In Théâtre D'Opéra Spatial (Review Board, Sept. 2023), registration was refused where the claim rested on prompting alone. That refusal is now under challenge in Allen v. Perlmutter, No. 1:24-cv-2665 (D. Colo., pending). Fettler's claim is built on the Zarya side of that line. The design record described above is the evidence that it belongs there. It is contemporaneous documentation of the human contribution, which is exactly what the Office and current practice guidance recommend keeping.
One limit is acknowledged rather than contested. Copyright protects expression, not systems or methods of operation (17 U.S.C. § 102(b); cf. Google v. Oracle, 593 U.S. 1 (2021)). The abstract idea of a bounded file tool (declared trees, a permission set, a configuration the tool may not write) is a method anyone is free to reimplement. What copyright protects is the expression of this project: this site's text, the documentation, the source, the tests, and the record itself. Stating that boundary plainly costs the claim nothing.
Claimed: authorship and copyright in the works of this project: the documentation, this website, the source of fettle and burler, the test suite, and the name as used here. These are claimed as works created by a human author exercising creative control. The machine-drafted portions are embodied in them through that author's direction, selection, arrangement, and revision. The claim runs to the full extent United States law protects such works.
Not claimed:
The claim of ownership and the openness of the license are not in tension. One must own a thing to license it, and this page is the account of that ownership.
I conceived Fettler, directed its design, and made every decision recorded above. I wrote and revised its documents, structured its repository, set its acceptance criteria, and named it. I take responsibility for all of it, including the portions first drafted by a tool at my direction. I used Claude (Anthropic) as a development tool, openly, and this page discloses that use in the interest of honesty and the historical record. I claim authorship and ownership of this project in good faith and to the full extent of the law.
Stephen Vincent Foster
August 2, 2026
Thaler v. Perlmutter, No. 23-5233 (D.C. Cir. Mar. 18, 2025) (opinion), cert. denied (U.S. Mar. 2, 2026) · U.S. Copyright Office, Copyright and Artificial Intelligence, Part 2: Copyrightability (Jan. 2025) · U.S. Copyright Office, Zarya of the Dawn registration decision (Feb. 2023) · Copyright Review Board, Théâtre D'Opéra Spatial decision (Sept. 2023) · Copyright Office AI initiative (registration guidance, Mar. 2023) · OpenInfra Foundation AI policy · 17 U.S.C. § 102(b) · Google v. Oracle, 593 U.S. 1 (2021).
This page is a disclosure and a declaration, not legal advice.
Shoddy · Fettler