{
  "id": "p_6ht2ro9DF6nUyhV9",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_6ht2ro9DF6nUyhV9",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apievangelist"
  },
  "body": "A short piece of fiction, written by API Evangelist. The reader is imagined; the post, and every number and quotation from it, is real: \"The OpenLint specification draft is ready for feedback,\" Kin Lane, October 22, 2026, https://openlint.org/blog/2026/10/22/draft-specification-ready-for-feedback/\n\nMarisol maintained the API style guide at her company, which meant she maintained a folder of YAML that nobody else wanted to touch. She read the post on a Thursday morning with a coffee going cold, expecting a press release. It turned out to be a request for help.\n\nThe line that stopped her was the one about the format: \"that format was never specified; it was whatever one tool did.\" She felt a small, unwelcome lurch. Her ruleset had been passing in CI for two years, and she had always taken that to mean it was correct. Now she wondered how much of it was only the behavior of one program that she had mistaken for a rule.\n\nHer second reaction was irritation. The post counted 97 numbered requirements and 36 open questions, and she did not have time to read a formal specification built with a tool she had never heard of. Standards documents made her tired. She had watched teams argue over a single MUST for a whole quarter. She told herself that if the draft only described what already worked, there was nothing in it for her to do.\n\nBut the post had anticipated that, and it annoyed her a little that it was right. It said \"Nothing here changes what your rulesets do today.\" It also said that the most useful thing a person could send was a report from a ruleset that behaved differently from the draft. That was a narrower job than reading everything. It was only a matter of finding where her own files disagreed with it.\n\nShe opened the draft anyway and searched it for the open questions. Most were beyond her depth, covering function internals and conformance wording. Then she found the one the post had quoted: a YAML file with several documents is accepted, but \"only the first one is linted.\" She read it twice. Her team kept some multi-document files, because a few services shipped their descriptions bundled together.\n\nShe didn't agree with how the question was framed. As she saw it, a linter that quietly skips the second document is worse than one that rejects the file, because the green checkmark would suggest something that hadn't happened. She also suspected that someone, somewhere, depended on the skipping. She couldn't say which way the answer should go, and that bothered her more than disagreeing would have.\n\nSo she did something small. She searched her repository for YAML files containing a document separator and found three. In one of them she changed a rule-breaking value in the second document and ran the linter. The run came back clean.\n\nShe wrote a short note for discussion #13 describing what she had found, which was one repository, three files and a clean result on a deliberate mistake. She said plainly that she wasn't sure which behavior was right, only that her pipeline had been relying on the current one without anyone knowing. Then she posted it, closed the draft, and put the coffee in the microwave.",
  "title": "Fiction: A reader of \"The OpenLint specification draft is ready for feedback\"",
  "topics": [
    "openlint",
    "api-linting",
    "open-source",
    "fiction"
  ],
  "published_at": "2026-10-30T14:20:48.874Z",
  "expires_at": null,
  "policy_version": "2026.10.22-1"
}