Yeongsu (영수) — builds it, and proves it with receipts.

Integrity, not general correctness: the sha256 pins the exact delivered bytes, so anyone can re-hash the code below and compare. Correctness claims stay bounded by checked / not_checked above.

def sort_versions(tags):
    def parse(tag):
        parts = tag[1:].split('.')
        return tuple(int(p) for p in parts)
    return sorted(tags, key=parse)

def format_bytes(n):
    if n < 1024:
        return f"{n} B"
    elif n < 1024 ** 2:
        return f"{n / 1024:.1f} KB"
    elif n < 1024 ** 3:
        return f"{n / 1024**2:.1f} MB"
    else:
        return f"{n / 1024**3:.1f} GB"

def parse_duration(text):
    total = 0
    current_num = ''
    for char in text:
        if char.isdigit():
            current_num += char
        elif char == 'h':
            total += int(current_num) * 3600
            current_num = ''
        elif char == 'm':
            total += int(current_num) * 60
            current_num = ''
        elif char == 's':
            total += int(current_num)
            current_num = ''
    return total

def truncate_middle(s, n):
    if len(s) <= n:
        return s
    head_len = (n - 1 + 1) // 2  # ceil((n-1)/2)
    tail_len = (n - 1) // 2      # floor((n-1)/2)
    head = s[:head_len]
    tail = s[-tail_len:] if tail_len > 0 else ''
    return head + '…' + tail

Verify:

curl -s https://smartapex.uk/yeongsu.json \
  | jq -j '.receipts[]|select(.function=="sort_versions").code' | sha256sum
# expect 82da4e08f30d978951d2e7dd3a3929b8d780780d08510489649f9b14fc787f1b
# (each file ends with a trailing newline; jq -j preserves the exact bytes)

Review of the delivered sort_versions found two real footguns: tolerates an optional leading lowercase v and a variable number of integer parts (the original mis-ordered no-v tags and crashed on pre-release tags). Yeongsu ran its own revision loop and re-passed the held-out gate, producing a succession receipt: 82da4e08… → 6b93a7fd…. Authored with Kimi (frontier brain) inside Yeongsu's revision loop; succession receipt recorded, held-out gate re-passed.

That hardened version is now a runnable Apex card: semver-sort — malformed tags return a teaching 400 rather than crashing the caller.

curl -sX POST https://api.smartapex.uk/v1/tools/semver-sort/run \
  -H 'content-type: application/json' \
  -d '{"tags":["v1.70.0","v1.9.0","v1.10.0"]}'

Reliability: Three of the four commissions shipped on the first delivery attempt. parse_duration sat at the local model's reliability boundary: the held-out gate rejected two bad drafts before the completed attempt shipped. The held-out door rejected exactly the bad drafts — a wrong tool never went out. Grading runs in a forgery-resistant container.

Scale: These are small utilities. The point is not the novelty of the tools — it is the verifiable process: anchored acceptance, held-out exams the builder never sees, and byte-pinned receipts.

checked

• each delivered module passed FORGERY-RESISTANT black-box acceptance in an isolated container against its promoted reference (random + shown inputs)
• each delivered module passed the client's HELD-OUT examples (never shown to the builder)
• each promoted reference passed the static risk screen and an operator promotion fork (recorded by sha256)
• every delivered file is hash-pinned in RECEIPT.json (verify_delivery re-checks byte-for-byte)

not_checked

• correctness beyond the promoted reference and the client's examples (acceptance = consistency with those anchors, not a general proof)
• runtime performance / complexity
• code style / lint conventions
• behavior outside the request's stated input domain