@bompus/house-rules 0.0.0-stage → 0.11.0

package/skills/hr-tdd/mocking.md

@@ -0,0 +1,39 @@
+# When to mock
+
+Mock at **system boundaries** only:
+
+- External APIs (payment, email, etc.)
+- Databases (sometimes; prefer a test DB)
+- Time/randomness
+- File system (sometimes)
+
+Don't mock:
+
+- Your own classes/modules
+- Internal collaborators
+- Anything you control
+
+## Designing for mockability
+
+At system boundaries, design interfaces that are easy to mock:
+
+**1. Use dependency injection**
+
+Pass external dependencies in rather than creating them internally:
+
+```typescript
+// Easy to mock
+function processPayment(order, paymentClient) {
+  return paymentClient.charge(order.total);
+}
+
+// Hard to mock
+function processPayment(order) {
+  const client = new StripeClient(process.env.STRIPE_KEY);
+  return client.charge(order.total);
+}
+```
+
+**2. Reuse production interfaces**
+
+Prefer existing operation-specific APIs when they serve production callers. Otherwise mock the transport boundary; request routing in a fake is acceptable. Do not add wrappers solely to simplify mocks. Assert observable results rather than calls to repo-owned helpers.

package/skills/hr-tdd/tests.md

@@ -0,0 +1,77 @@
+# Good and bad tests
+
+## Good tests
+
+**Integration-style**: Test through real interfaces, not mocks of internal parts.
+
+```typescript
+// GOOD: Tests observable behavior
+test("user can checkout with valid cart", async () => {
+  const cart = createCart();
+  cart.add(product);
+  const result = await checkout(cart, paymentMethod);
+  expect(result.status).toBe("confirmed");
+});
+```
+
+Characteristics:
+
+- Tests behavior users/callers care about
+- Uses public API only
+- Survives internal refactors
+- Describes WHAT, not HOW
+- Assertions establish one observable behavior; use several when the contract needs them
+
+## Bad tests
+
+**Implementation-detail tests**: Coupled to internal structure.
+
+```typescript
+// BAD: Tests implementation details
+test("checkout calls paymentService.process", async () => {
+  const mockPayment = { process: jest.fn() };
+  await checkout(cart, mockPayment);
+  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
+});
+```
+
+Red flags:
+
+- Mocking internal collaborators
+- Testing private methods
+- Asserting internal collaborator calls/counts/order instead of observable behavior. External-boundary count or order contracts are valid assertions.
+- Test breaks when refactoring without behavior change
+- Test name describes HOW not WHAT
+- Bypassing the tested public interface to inspect private implementation state. Observable storage, wire, and DOM outcomes remain valid; prefer fake state over call logs when state expresses the contract.
+
+```typescript
+// BAD: Checks private storage when storage is not the public contract
+test("createUser saves to database", async () => {
+  await createUser({ name: "Alice" });
+  const row = await db.query("SELECT * FROM users WHERE name = ?", ["Alice"]);
+  expect(row).toBeDefined();
+});
+
+// GOOD: Verifies through interface
+test("createUser makes user retrievable", async () => {
+  const user = await createUser({ name: "Alice" });
+  const retrieved = await getUser(user.id);
+  expect(retrieved.name).toBe("Alice");
+});
+```
+
+**Tautological tests**: Expected value restates the implementation, so the test passes by construction.
+
+```typescript
+// BAD: Expected value is recomputed the way the code computes it
+test("calculateTotal sums line items", () => {
+  const items = [{ price: 10 }, { price: 5 }];
+  const expected = items.reduce((sum, i) => sum + i.price, 0);
+  expect(calculateTotal(items)).toBe(expected);
+});
+
+// GOOD: Expected value is an independent, known literal
+test("calculateTotal sums line items", () => {
+  expect(calculateTotal([{ price: 10 }, { price: 5 }])).toBe(15);
+});
+```

package/skills/hr-test-audit/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: hr-test-audit
+description: Gate new or changed tests on the value they add, and sweep an existing suite for low-value, implementation-coupled or duplicate tests to delete. Use when adding or reviewing tests, or when asked to prune, audit or clean up a test suite.
+---
+
+# Test audit
+
+Two modes share one value bar: a test earns its upkeep by protecting observable
+behavior, a credible regression, or an independent contract. **Authoring mode**
+gates each new or changed test before it lands. **Audit mode** finds existing
+tests that fail the bar and removes them in small, evidenced batches. For the
+red-green loop itself, use a TDD skill where one is installed; this skill decides which tests are worth
+keeping.
+
+## Authoring gate
+
+Before adding a test, answer all four. A missing answer means don't add it yet.
+
+1. What observable behavior, invariant or contract does it protect?
+2. What credible regression makes it fail? Name the production change that
+   turns it red: a wrong constant or argument, a wrong branch, a missing side
+   effect, an empty or default return, or a missing check for empty, nil,
+   unauthorized or malformed input. If none would, it is a change detector or
+   cannot fail.
+3. Why doesn't existing coverage already catch that? Each contract has one
+   owning test at its strongest boundary. Another layer needs its own risk the
+   owner cannot reach. Prefer a new case in an existing table or fixture over a
+   near-duplicate test.
+4. Does it need a production seam (export, flag, wrapper, injection hook) that
+   no production caller uses? Then test at the real boundary instead.
+
+When a unit must be tested in isolation, write down the ways it can fail before
+writing the code, and test those failures. A test written after the code tends
+to restate the code.
+
+A bug regression test must fail on the pre-fix code for the intended reason,
+then pass after the fix. One that never demonstrably failed proves the mock, not
+the fix. One regression at the owning boundary covers the bug; don't replay it
+at every layer it crosses. For a sequence `hr-ordering-tests` found, that
+regression is the named test beside its enumeration.
+
+Changing an existing test so it checks less counts as removing it: deleting or
+skipping it, loosening an assertion, or rewriting an expected value to match new
+output. It needs the audit-mode evidence from step 2, not only these answers.
+To catch these moves in a diff, run
+`bun <this skill's directory>/scripts/floor-guard.ts [--base <ref>]` from
+the repository. It reports new suppression comments, added skips or
+`.only`, deleted test files and assertions removed from surviving tests, and
+exits 0 clean, 1 with findings, 2 when it could not run. Each finding still
+needs a reason; a 2 is never a pass.
+
+For retry and concurrency failures, exercise the implementation at the boundary
+where order matters. Cover the credible lost-response, interrupted-write or
+restart sequence with controlled barriers and assert durable state or externally
+visible behavior. Do not replace that coverage with a separate model of the code.
+Code that merges events from more than one actor also needs an enumeration test
+from `hr-ordering-tests`, and a change that adds a kind of event adds it to that
+test's event list.
+
+When behavior depends on three or more independent settings, cover every pair
+of their values rather than every combination: list each setting's value
+classes and edge values, drop combinations the code rejects, and build the
+smallest table where each pair appears at least once (Microsoft PICT generates
+one). Most interaction bugs need only two settings to line up. Add an explicit
+case for each combination of three or more settings already known to interact,
+such as one behind a past bug or a documented constraint.
+
+Then check the test against the junk patterns below. A match fails the gate
+unless the retention bar names the contract it independently guards.
+
+## Junk patterns
+
+Authoring rejects new tests that match; audits hunt for existing ones that do.
+
+- no assertion, or an assertion that cannot fail
+- expected values produced by the code under test, or copied from it
+  (fixtures, inventories, export lists, snapshots taken from current output)
+- exact source, import or string greps standing in for behavior
+- private helpers or call shapes tested again where a real boundary already
+  covers them
+- the same contract asserted several times, or one shared helper re-tested in
+  every caller
+- tests that exist only to keep test-only exports, globals or wrappers alive,
+  and production code whose only callers are tests
+- mocks that implement the asserted behavior, or one mock standing in for
+  different APIs
+- negative tests that pass for an unrelated reason (a different guard rejects
+  the input, or the production path never reaches the check)
+- names or fixtures that promise more than the test exercises
+- tests that break under a behavior-preserving refactor
+
+## Retention bar
+
+Keep a test that independently enforces a public API, protocol, config,
+migration, storage, security, platform, default or release contract. Also keep
+call-order tests when order is observable, regressions with a credible failure
+mode, and a source check when it is the cheapest guard that fails on a
+user-facing change and survives a rename. Slow or static is not a reason to
+delete. A kept test that fails on the unchanged baseline may be a real bug:
+reproduce and fix it rather than deleting the test.
+
+## Audit mode
+
+1. **Discover, read-only.** Read the repository's testing guidance first. For a
+   large suite, split discovery by area and run the slices in parallel if the
+   host allows. Prefer a few high-confidence candidates over a long speculative
+   list. Before judging one, read the whole test, the production code it covers,
+   that code's callers, and any overlapping tests.
+2. **Record evidence per candidate** before editing: test name and location;
+   the failure it can actually detect; non-test callers of what it covers; the
+   stronger test that remains, or why none is needed; why it exists (history);
+   what production or test-support code its removal frees; the focused
+   validation command. A missing field means the candidate is not ready.
+3. **Edit one coherent batch.** Remove the tests along with the test-only
+   exports, wrappers and dead paths they kept alive; don't leave aliases. Move a
+   retained regression to its owning boundary. Don't add replacement tests that
+   restate the implementation, and don't count uncertain deletions as progress.
+4. **Validate.** Run the owning and sibling tests, then the repository's
+   required checks. Where a removed test grepped source or a plan, run the
+   script or dry run that owns the real contract instead.
+5. **Report**: categories removed, kept false positives and why, checks run,
+   and production versus test lines changed (`git diff --numstat`). Land one
+   batch at a time through the repository's normal flow, then rerun discovery on
+   the updated base for the next batch.
+
+## Sources
+
+Original synthesis, adapting:
+
+- OpenClaw's
+  [`test-audit`](https://github.com/openclaw/openclaw/blob/65f1e4d2279eecd6e40d55d82027d5c97b4b272b/.agents/skills/test-audit/SKILL.md):
+  the authoring gate, junk patterns, retention bar and evidence fields.
+- [Ansh Nanda via Ray Fernando](https://x.com/RayFernando1337/status/2102927565778522610):
+  the failure-list-first rule. Their "E2E tests only" rule is not adopted.
+- no_human's [tamper guard](https://github.com/no-human-ai/no_human): weakening
+  a test counts as removing it.
+- addyosmani/agent-skills'
+  [floor guard](https://github.com/addyosmani/agent-skills/blob/main/skills/constraint-driven-development/references/floor-guard.md)
+  (MIT): the diff checker.
+- obra/superpowers `writing-good-tests.md`: the mutation check behind
+  authoring-gate question 2.
+- omkamal's [pypict skill](https://github.com/omkamal/pypict-claude-skill):
+  pairwise coverage.
+
+For recorded proof that a UI change works, see michaelshimeles'
+[`evidence-driven-testing`](https://github.com/michaelshimeles/skills/tree/main/evidence-driven-testing).

package/skills/hr-test-audit/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "HR: Test audit"
+  short_description: "Gate new tests and prune low-value ones"

package/skills/hr-test-audit/scripts/floor-guard.ts

@@ -0,0 +1,137 @@
+#!/usr/bin/env bun
+// Flag changes that make tests or checkers easier to pass: new suppression
+// comments, added skips or `.only`, deleted test files, and assertions removed
+// from test files that still exist. Diff-scoped: merge base to working tree,
+// untracked files included. Tightening is silent; only loosening is reported.
+//   bun floor-guard.ts [--base <ref>]   (default: origin/HEAD, then origin/main)
+// Exit 0 clean, 1 findings, 2 the guard could not run. Never read 2 as clean.
+// Adapted from addyosmani/agent-skills constraint-driven-development
+// references/floor-guard.md (MIT).
+import { spawnSync } from "node:child_process";
+import { parseArgs } from "node:util";
+
+export type Finding = { rule: string; file: string; text: string };
+
+const SUPPRESSIONS =
+  /@ts-ignore|@ts-nocheck|@ts-expect-error|eslint-disable|oxlint-disable|biome-ignore|#\s*noqa|#\s*type:\s*ignore|istanbul ignore|c8 ignore|nosemgrep|gitleaks:allow|Stryker disable/;
+const SKIPS =
+  /\.(skip|todo|only)\s*\(|\b(xit|xdescribe|xtest)\s*\(|@pytest\.mark\.(skip|xfail)|\bt\.Skip\(/;
+const ASSERTION = /\b(expect|assert\w*|should)\b/;
+
+export function isTestFile(path: string): boolean {
+  return /\.(test|spec)\.[^/]+$|_test\.[^/]+$|(^|\/)test_[^/]+$|(^|\/)(tests?|__tests__)\//.test(
+    path,
+  );
+}
+
+// Reads a unified diff (`--unified=0` is enough) and returns the loosening moves.
+export function scanDiff(diff: string): Finding[] {
+  const added: { file: string; text: string }[] = [];
+  const removed: { file: string; text: string }[] = [];
+  const deleted = new Set<string>();
+  const strip = (p: string) => p.replace(/^[ab]\//, "");
+  let file = "";
+  let oldFile = "";
+  // File headers appear only between `diff --git` and the first `@@`; inside a hunk,
+  // an added line such as `++ x` is content, not a header.
+  let inHunk = false;
+  for (const line of diff.split("\n")) {
+    if (line.startsWith("diff ")) {
+      inHunk = false;
+    } else if (line.startsWith("@@")) {
+      inHunk = true;
+    } else if (!inHunk && line.startsWith("--- ")) {
+      oldFile = strip(line.slice(4));
+    } else if (!inHunk && line.startsWith("+++ ")) {
+      const newFile = strip(line.slice(4));
+      file = newFile === "/dev/null" ? oldFile : newFile;
+      if (newFile === "/dev/null") {
+        deleted.add(oldFile);
+      }
+    } else if (line.startsWith("+")) {
+      added.push({ file, text: line.slice(1) });
+    } else if (line.startsWith("-")) {
+      removed.push({ file, text: line.slice(1) });
+    }
+  }
+
+  const findings: Finding[] = [];
+  const flag = (rule: string, f: string, text: string) =>
+    findings.push({ rule, file: f, text: text.trim().slice(0, 120) });
+  for (const { file: f, text } of added) {
+    if (SUPPRESSIONS.test(text)) {
+      flag("silenced-checker", f, text);
+    }
+    if (isTestFile(f) && SKIPS.test(text)) {
+      flag("test-skipped", f, text);
+    }
+  }
+  for (const f of deleted) {
+    if (isTestFile(f)) {
+      flag("test-deleted", f, "file deleted");
+    }
+  }
+  // An assertion line that reappears in the same file was moved, not removed.
+  const kept = new Set(added.map((a) => `${a.file}\0${a.text.trim()}`));
+  for (const { file: f, text } of removed) {
+    if (!isTestFile(f) || deleted.has(f) || !ASSERTION.test(text)) {
+      continue;
+    }
+    if (!kept.has(`${f}\0${text.trim()}`)) {
+      flag("assertion-removed", f, text);
+    }
+  }
+  return findings;
+}
+
+function git(args: string[], okStatuses = [0]): string | null {
+  const r = spawnSync("git", args, { encoding: "utf8" });
+  return r.status !== null && okStatuses.includes(r.status) ? r.stdout : null;
+}
+
+function main(): number {
+  const bail = (msg: string) => (console.error(`floor-guard: ${msg}`), 2);
+  let base: string | undefined;
+  try {
+    base = parseArgs({ options: { base: { type: "string" } } }).values.base;
+  } catch (error) {
+    return bail(error instanceof Error ? error.message : String(error));
+  }
+  const bases = base ? [base] : ["origin/HEAD", "origin/main"];
+  let mergeBase: string | undefined;
+  for (const b of bases) {
+    mergeBase = git(["merge-base", b, "HEAD"])?.trim();
+    if (mergeBase) {
+      break;
+    }
+  }
+  if (!mergeBase) {
+    return bail(`no merge base against ${bases.join(" or ")}`);
+  }
+  const tracked = git(["diff", "--unified=0", mergeBase, "--"]);
+  const untracked = git(["ls-files", "--others", "--exclude-standard"]);
+  if (tracked === null || untracked === null) {
+    return bail("could not read the diff");
+  }
+  let diff = tracked;
+  for (const f of untracked.split("\n").filter(Boolean)) {
+    // --no-index exits 1 when the sides differ, which is the normal case here.
+    const d = git(["diff", "--no-index", "--unified=0", "/dev/null", f], [0, 1]);
+    if (d === null) {
+      return bail(`could not diff untracked file ${f}`);
+    }
+    diff += `\n${d}`;
+  }
+  const findings = scanDiff(diff);
+  for (const f of findings) {
+    console.log(`${f.rule}\t${f.file}\t${f.text}`);
+  }
+  if (findings.length === 0) {
+    console.log("floor-guard: clean");
+  }
+  return findings.length ? 1 : 0;
+}
+
+if (import.meta.main) {
+  process.exit(main());
+}

package/skills/hr-what-next/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: hr-what-next
+description: "Reconcile remaining work and recommend priorities. Use for next, next?, what's next, what remains, backlog reviews, full-session audits of tasks and unanswered or past questions, and equivalent requests. Do not use for go or continue, which retain their acceptance/continuation meaning, or progress/ETA-only requests."
+---
+
+# What next
+
+Turn the requested scope into an evidence-based inventory and next decision.
+Before reporting, read the bundled [reporting procedure](references/reporting.md).
+Use it with the governing continuation and offer rules; this request does
+not cancel selected work or authorize a new task.
+
+Before a session-completion claim, apply the governing § Finishing work's
+full-session gate even when the request was only a short "next?". Save the
+completed state before the completion message; a report alone does not do so.
+
+1. Choose the review scope from the request and its context. For a short
+   "next?", check the current task, its ledger and latest results, plus this
+   floor whatever the scope: every question from an earlier offer in this
+   conversation that the user has not answered, every owned uncommitted file,
+   unpushed commit or held checkout, and the number of other live ledger items
+   (deferred, unselected, blocked or follow-up) with a link to the ledger.
+   Report each floor item, or state that the floor is empty. While any floor
+   item remains, do not say that nothing is left or that nothing needs the
+   user; re-present the unanswered questions as an offer instead. When asked
+   for all current and past items, review the available session transcript,
+   relevant plans, task lists, handoffs and linked follow-ups. Name source
+   ranges and missing, inaccessible or truncated records. Sweep other
+   sessions' records only within the requested project and scope.
+2. Trace requests, unanswered questions, commitments, offered alternatives
+   and findings to their latest disposition. Reconcile duplicate, superseded
+   and stale rows with completion or replacement evidence. Keep owners,
+   deferred triggers and other sessions' context visible. An old task
+   description alone does not establish current activity or ownership.
+3. Preserve the latest selected scope and valid unanswered offer in the
+   durable ledger. Distinguish done, authorized unfinished, unselected,
+   blocked, deferred and other-owner items. A completed implementation does
+   not complete required checks or landing; deferral does not mean done.
+4. Rank remaining items toward the current goal and explicit priorities.
+   Explain the objective and weigh expected impact, next-decision value,
+   urgency, dependencies, effort and evidence confidence. Keep priority,
+   readiness and authority separate. Label unknown gains rather than
+   inventing scores or measurements.
+5. Lead with what is complete, what remains and the next unfinished selected
+   step. Show one row per remaining item with rank, state, expected impact
+   and its reason, next action or decision, and owner/source where needed.
+   For a full audit, put the full individual table in a durable report
+   and link it beside the immediate decisions. Answer whether items are
+   accounted for separately from whether selected work is complete.
+6. Continue work that can advance under existing authorization. Ask only for
+   unresolved choices using the governing offer format. Preserve schedules
+   and ownership; this audit grants no authority to start, transfer, publish
+   or clean up work merely because it appears in the inventory.
+
+For a full audit, save a mapping from reviewed source records to items or
+reviewed context-only dispositions. If `hr-handoff` and its reconciliation
+resources are available, reuse its `references/reconciliation.md` procedure
+and `scripts/check-reconciliation.mjs` checker. Otherwise retain the mapping
+and coverage gaps without claiming a mechanical check. A passing checker
+accounts for supplied records; it does not prove every promise was understood
+or that unavailable history contains no other work.

package/skills/hr-what-next/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "HR: What next"
+  short_description: "Reconcile remaining work and recommend priorities"
+  default_prompt: "Use $hr-what-next to reconcile remaining work and recommend the next decision."

package/skills/hr-what-next/references/reporting.md

@@ -0,0 +1,68 @@
+## Reporting
+
+Lead with the answer or the concrete result. Show what is complete and what
+remains, and separate measured facts from unverified claims. Use numbered steps
+for actions the user must perform.
+
+During long work, give frequent useful progress updates with completed evidence,
+the current action and what remains. Show clock-time forecasts in the user's
+local timezone. Use the timezone provided by the user or session environment;
+ask if neither establishes it.
+
+Use a visual when it makes a change, behavior or decision clearer; keep a short
+text explanation beside it. For visible interface changes, prefer actual
+before/after captures with comparable content, viewport and state when available.
+Label mockups and simulated behavior as illustrations, not verification. Use
+interaction when exploring states or alternatives helps the reader, and provide
+an accessible text or static equivalent. Use the host's available tools within
+existing browser and task authorization.
+
+Use a Markdown table when comparing items on common criteria or reporting
+repeated records with useful shared fields. When asked about benefits,
+tradeoffs or how a proposal differs from current behavior, use a compact
+table for multiple items. Explain one item per row. For changes, show current
+and proposed behavior and why the difference matters. Include relevant
+tradeoffs and evidence or uncertainty; label unknowns rather than inventing
+gains. Keep columns consistent and cells short. Label missing or unverified values and put units in headings. Put
+explanations and caveats beside the table. Split wide tables or use lists when
+long cells obscure the comparison. Preserve § Offers and any enabled offer format.
+
+When asked for a backlog, research list or remaining work, check the current
+session and relevant task records within the requested scope. Reconcile
+completed, superseded and duplicate items before reporting what remains.
+State which records were checked and label incomplete coverage.
+
+Show one row per remaining item in priority order. Use compact columns for
+rank, item, state, expected impact with its priority reason, and next action
+or decision. Include owners and source links when needed to distinguish work.
+Keep blocked, deferred, unstarted and research items visible with their
+conditions; priority does not authorize starting them.
+
+State the ranking objective from the current task's goal and explicit user
+priorities. Recent work informs that objective; explain any inferred goal.
+Weigh expected contribution to the goal and how much the next action helps
+make the next decision, accounting for urgency, dependencies, effort and
+confidence in the evidence. For performance work, use relevant latency,
+throughput or resource measures. For fixes, weigh severity and affected users.
+For enhancements, weigh user value and progress toward acceptance criteria.
+For research, name the uncertainty or decision the work could resolve.
+Label expected gains and unknowns; do not invent measurements or scores.
+Keep priority separate from readiness, and preserve § Finishing work's
+requirements for continuing authorized work and making offers.
+
+Put the answer, and anything the user must read or act on, in the reply's text
+after its last tool call. Text written between tool calls can be collapsed or
+lost. When the reply ends with a question card, that text goes after every
+other tool call, right before the card.
+
+Verify work with completed checks and their output. Confirm each check's exit status or final
+result before claiming a pass, and do not hide failures by filtering output. Report changes,
+verification, failed or unrun checks and remaining uncertainty. At task or session closeout,
+save reusable lessons with their condition, action and evidence in the project's record or notes.
+Link existing rules or checks. When none emerged, no lesson entry is needed.
+
+Name each choice made in passing that costs the user something if missed.
+That covers a tradeoff, a default picked for them, a step you did not
+highlight and a result that may be off, but not routine plumbing. Describe
+it in words the user would still recognize a week later, not in names coined
+during the work.

package/skills/hr-writing-for-agents/NOTICE.md

@@ -0,0 +1,46 @@
+# Source notices
+
+This notice accompanies the hr-writing-for-agents bundle when copied on its own.
+
+## mattpocock/skills
+
+Source: https://github.com/mattpocock/skills (compared at revision `d81f3a1`)
+
+- `skills/hr-writing-for-agents/`: adapted from `skills/productivity/writing-for-agents/`.
+
+Copyright (c) 2026 Matt Pocock
+
+## obra/superpowers
+
+Source: https://github.com/obra/superpowers (compared at revision `8ca22db`)
+
+- `skills/hr-writing-for-agents/SKILL.md`: the instruction-form table is adapted
+  from `writing-skills`.
+
+Copyright (c) 2025 Jesse Vincent
+
+The source's wording tests found that a recipe beat a prohibition for shape failures; the instruction-form table preserves that approach.
+
+## house-rules and MIT permission notice
+
+MIT License
+
+Copyright (c) 2026 Aaron Queen
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.