slop.place

7 min read Original article ↗

Software written by machines. Served with a label.

Everything published here was written end to end by an AI — the code, the tests, the documentation, this sentence. No human has read it line by line.

That is not a disclaimer buried in a footer. It is the first thing on the page, and every project ships with the numbers to check it by.

On the counter

runnerforge

Slop Facts

1 throwaway machine per CI job

Serving size3 forges

Amount per release

Written by machines100%

% verified

Read by humans
0
0%

Forges driven end to end against a live instance
3
100%

Unit and integration tests
180
100%

Cloud VMs booted and destroyed on a real account
1
100%

Lint findings 115 linters, 18 refused with reasons
0
0%

Statement coverage
86%

Cloud drivers
2

Container image
19 MB

Go, hand-written
0 lines

The end-to-end tests drive a real Forgejo, a real GitLab and a real GitHub repository, and fail if a single machine or runner registration survives the run. Exactly one function is uncovered: main, which calls os.Exit. Every linter golangci-lint ships is enabled; the eighteen turned off contradict each other or this design, and each says why in the config.

Ephemeral CI runners: one throwaway machine per job, for GitHub Actions, GitLab CI and Forgejo Actions, on any cloud.

All three forges solved the same problem and none of them the same way. GitHub hands out a config good for exactly one job. Forgejo hands out a runner that deletes itself. GitLab hands out a token that does neither and a registration it will never clean up. The fourth surprise came from OVHcloud: a create response with no creation time, which the reaper reads as a machine born in 1970 and long overdue for deletion. It would have emptied the account on its first pass.

Run it

docker run -v ./data:/data -p 8080:8080 \
  ghcr.io/slop-place/runnerforge

Screenshots and detail Read the source

Also serving

BetterNiim

Slop Facts

1 label printer, 30 name tags a minute

Serving size77 printers

Amount per release

Written by machines100%

% verified

Read by humans
0
0%

Printers driven end to end against real hardware
1
1%

Unit and integration tests
514
100%

UI tests driving the real app
26
100%

Barcode symbologies verified by decoding them back
11
100%

Third-party dependencies
0
0%

Drawings
19,148

Borders, drawn as geometry
70

Templates
70

Typefaces
12

Languages
2

Price, now and later
£0

One printer of seventy-seven is marked verified, and that number is the point of the tier: it says what has been run on a real machine, not what has been written. Coverage is 96–98% on the libraries and 63% on the views, reported separately because the two profiles are built for different platforms and cannot honestly be merged into one figure.

Design and print labels on any NIIMBOT printer, from an iPhone, an iPad or a Mac. Built for teachers, and free in the way that means nothing is held back rather than the way that means an account.

The protocol is undocumented, so it was read off the wire: framing, checksums, seven per-model print flows. The label size is the part that is not on the wire at all — it is written on the roll’s RFID tag and the printer keeps it, which is why the vendor app asks their server for it. This one has no server, so it learns the roll from the first thing you print on it.

The stock is wider than the head that prints on it. A B1 is sold with 50 mm labels and covers 48, and getting that wrong meant the app refused to print the roll in its own box. The first measurement of where the printhead sits was wrong too, and the answer turned out to be a roll sitting crooked in the machine.

Build it

git clone https://github.com/slop-place/betterniim
swift test

Read the source The protocol notes

Also serving

terraform-provider-mattermost

Slop Facts

1 provider per chat server

Serving size41 resources

Amount per release

Written by machines100%

% verified

Read by humans
0
0%

Acceptance tests against a real server in Docker
43
100%

Test functions
246
100%

API operations classified 600 documented, none unaccounted for
600
100%

Lint findings every linter enabled
0
0%

Data sources
32

Statement coverage
91%

API quirks documented
29

Go, hand-written
0 lines

Coverage is 88% with no server at all and 91% against a live one. Two gates keep the suite honest: one fails if any attribute is never written, the other if any registered configuration is never applied. Every run sweeps the server clean afterwards, whether it passed or not.

A Terraform provider for Mattermost — teams and channels, users, bots and their tokens, webhooks and slash commands, permission schemes, groups, and the system configuration.

The configuration has several hundred settings across four dozen sections, so the resource takes the ones you want as a JSON document and manages exactly those, restoring what it found on destroy. Writing it turned up twenty-nine places where Mattermost accepts something and quietly does nothing with it: a team's contact address, a user's verified flag, a token's expiry. The last one matters — asking for a token that expires and getting a permanent one is not a difference to discover later — so the provider checks what came back and fails.

Guests can be invited with a magic link — a mail that signs them in without a password. Mattermost asks for that with a query parameter its own Go client does not pass, so calling the obvious method sends an ordinary signup link instead and tells you nothing. The provider builds that request itself. Proving it works meant putting a mail catcher in the test stack: the link exists only inside the email, and a test that trusted the API's 200 would pass either way.

Install

terraform {
  required_providers {
    mattermost = {
      source  = "slop-place/mattermost"
      version = "~> 0.1"
    }
  }
}

Read the source Where the API disagrees with its docs

Also serving

terraform-provider-freshdesk

Slop Facts

1 provider per helpdesk

Serving size28 resources

Amount per release

Written by machines100%

% verified

Read by humans
0
0%

Acceptance tests against a live helpdesk
21
100%

Unit tests
420
100%

API endpoints covered
364
100%

Lint findings every linter enabled
0
0%

Data sources
45

Client methods
246

Go, hand-written
0 lines

Percentages are of the shipped build. The acceptance suite creates and destroys real records against a live Freshdesk account, not a mock.

A Terraform provider covering the whole of the Freshdesk API v2 — agents, groups, tickets, fields, SLA policies, automations, the knowledge base and the forums.

Writing it turned up twelve places where Freshdesk's API disagrees with Freshdesk's documentation: field writes that 404 on the documented path, IDs that arrive quoted on some endpoints and bare on others, a choices attribute with five different shapes, endpoints that answer 405 to the delete their own docs describe. Each one is handled, and named in the README.

Install

terraform {
  required_providers {
    freshdesk = {
      source  = "slop-place/freshdesk"
      version = "~> 0.1"
    }
  }
}

Read the source Registry

How it gets made

The spec is read, not recalled

The API reference is scraped and parsed before a line is written, and a coverage script checks the client against that inventory on every build. A missing endpoint fails CI.

It runs against the real thing

Every resource is exercised through create, refresh, update, import and destroy on a live account. That is how the twelve documentation bugs were found; a mock would have agreed with the docs.

Nothing is hidden

Where the API cannot do something — no delete on an SLA policy, a body the server rewrites — the provider says so in its own docs and warns at plan time rather than pretending.

Read it before you run it. Thorough testing is not the same as review, and a machine can be confidently wrong in ways a test suite agrees with. Everything here is MPL-2.0 and the diff is right there.