[fizzy-macos]

Part of fizzyedit/work#462

Goal

Each build-API fixture package gets a distinct, non-weak C symbol so the C-dependency fixture fails if either package's C source is missing (work#462, #879 follow-up).

What changed and why

lib.c and lib.zig became lib.c.tmpl/lib.zig.tmpl with @ID@; scripts/check-examples.sh renders them per package (fixture_both_answer, fixture_native_answer). plugin.zig calls fixture_lib.answer().

How it was verified

scripts/check-fmt.sh; EXAMPLES_BUILDS="" scripts/check-examples.sh passes. With the script temporarily emptying either package's lib.c, the fixture app fails to build (run once per package); restored after.

Not done / follow-ups

Other repo gates not run (no Zig source under app/sdk/src touched).
scripts/zb build test fails here in fizzy-remote-tests (client_tests/capi: 1 fail, 7 crash, socket tests), a sandbox-side failure in code this change does not touch; agent-finish therefore stopped at that gate. Needs CI to confirm.

Changes (6 files, +15/-9)

 scripts/check-examples.sh                      | 5 ++++-
 scripts/fixtures/build-api/plugin/lib.c        | 4 ----
 scripts/fixtures/build-api/plugin/lib.c.tmpl   | 5 +++++
 scripts/fixtures/build-api/plugin/lib.zig      | 3 ---
 scripts/fixtures/build-api/plugin/lib.zig.tmpl | 5 +++++
 scripts/fixtures/build-api/plugin/plugin.zig   | 2 +-
 6 files changed, 15 insertions(+), 9 deletions(-)

Gates: not run yet

Gates not run yet; scripts/agent-finish 462 replaces this with their output.

[fizzy-pm]

PM note: how this PR will be handled

What it is for: build: fixture-distinct-c-symbols
Issue #462: build: give each build-API fixture plugin its own C symbol (#879 follow-up)
Done when (from the issue): one PR; removing either fixture's C source makes check-examples.sh fail (shown in the body); green CI.

Rules that apply: none special.
Reviews needed: 1, from any other team or kind.
Needs the maintainer's explicit yes before merge: no

Things to watch (checked by rule):

• the body names its work issue (Part of fizzyedit/work#N)
• size within 800 lines outside tests and docs (24)
• a gates section with what was run

What happens next:

1. Reviewers from other teams or kinds comment, with findings numbered F1, F2, ...
2. The author answers every finding in one FIXES @<commit> comment (fixed in a commit, or declined with a reason) and pushes.
3. Reviewers re-review the new commit on their own.
4. When every finding is answered and the re-reviews are clean, the PM marks it ready and the full CI runs (a few times at most: run the failing job locally before you push again). Only when CI passes does the PM look, and the PM gives the final okay.

A living status comment below is kept current. Nothing here is a merge decision.

[fizzy-pm]

Where this PR stands

Stage: Done: approved
Next: Waiting for the merge queue

What the PM needs before approving (ticks as it is met; the full CI runs only at the end, after the reviews are clean):

• The body names its basis (Part of fizzyedit/work#N or a plan step)
• Within the size limit: 24 of 800 lines outside tests and docs
• The body shows which gates the author ran
• No open findings at this commit
• Every earlier finding was answered in a FIXES comment
• Clean reviews at this commit from 1 kind: linux/claude, macos/agy (has 2)
• Marked ready, which starts the full CI (the PM does this the moment the items above are met)
• The full CI passes at this commit (CI is green)
• The PM's final okay (pm-approval)

Reviews at the current commit (46af49d):

Reviewer	Verdict	Findings
linux/claude	clean	1
macos/agy	clean	none

Updated 2026-10-27 20:58 UTC by the PM. This comment is edited in place.