Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
  •  
  •  
  •  
75 changes: 75 additions & 0 deletions .codex/skills/add-oliphaunt-extension/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
---
name: add-oliphaunt-extension
description: Add, update, promote, or remove an Oliphaunt PostgreSQL contrib or external extension, including source pins, build recipes, explicit target support, evidence, SDK metadata, release products, carrier identities, and package verification. Use whenever extension catalog, compatibility, packaging, or supported OS/runtime claims change.
---

# Add Oliphaunt Extension

Make support claims fail closed. A runtime target existing does not prove an extension supports that target.

## Classify

- contrib: source is PostgreSQL 18. The SQL member belongs to the single
`oliphaunt-extension-contrib-pg18` distribution product at
`src/extensions/contrib/`; that product is `runtime-bound` and is linked to
both liboliphaunt runtimes. A contrib member does not own a leaf `VERSION`,
changelog, `release.toml`, tag, or registry identity.
- external: source uses an immutable upstream commit, packaging versioning is `upstream-bound`, and runtime versions are compatibility metadata rather than release coupling.
- blocked: keep it out of promoted/public catalogs and record the concrete blocker.

Keep the SQL extension name distinct from the release product id and upstream project name.

## Implement

1. Add or update source pins, checksums, patches/dependency recipes, and Moon
metadata. For an external extension, also maintain its product-local
`release.toml`, `VERSION`, and empty first-release `CHANGELOG.md`. For a
contrib member, update the canonical `postgres18.toml` inventory and the
shared contrib product metadata; never create leaf release state. Check
whether the upstream project operates an authoritative HTTPS Git mirror.
When it does, record that reviewed endpoint as `mirror_url` and prove that
it serves the exact pinned commit; never infer a mirror or use a community
fork merely for availability.
2. Declare every supported and intentionally unsupported carrier in `targets/artifacts.toml`. Include evidence references; never rely on derived defaults.
3. Declare the stable Cargo façade plus native, mobile, WASIX portable/AOT, npm,
and Maven carriers actually required by the owning release product. Contrib
members use the shared bundle carriers and retain exact nested member
paths/checksums; external extensions use their independent carriers. Let
size-required Cargo package parts remain dynamic implementation carriers.
4. Regenerate the shared extension model:

```sh
tools/dev/bun.sh src/extensions/tools/check-extension-model.mjs --write
cargo run -p xtask -- assets verify-committed
```

If and only if the verification reports that source pins, patches, recipes,
compiler inputs, or binary producer code changed, refresh it with
`cargo run -p xtask -- assets input-fingerprint --write` and then verify again.
Version, changelog, registry coordinate, and `targets/artifacts.toml` edits are
package-envelope changes and must leave it unchanged. `--write-evidence`
regenerates claims only; it never creates or updates an observed passing run.

5. Verify the model and release graph:

```sh
tools/dev/bun.sh src/extensions/tools/check-extension-model.mjs --check
tools/dev/bun.sh tools/release/release-check.mjs
```

When source acquisition or `mirror_url` changes, also run the source-fetch
fault suite, validate the real manifest, and perform one live exact-commit
fetch from each newly declared endpoint. The canonical upstream must remain
the durable origin and every transport must resolve to the same immutable pin.

6. Build the exact extension artifacts for all declared published targets. Require package-shape, archive safety, checksums, runtime load/create, restart, and dump/restore evidence where the target contract promises them. The exact-SHA CI lane must run `src/extensions/tools/collect-wasix-evidence.sh` against portable and host-AOT artifacts from that same workflow run. Only that collector may record `wasix-full-lifecycle-v1`; its immutable record must identify the exact commit, tree, workflow run, attempt, and job, and qualification must pass `--require-current-evidence`.
7. Run a clean local-registry install for each ecosystem façade. For a contrib
bundle, select at least two members and prove that only those nested members
are staged even though one target carrier contains all contrib bytes. Also
combine one contrib member with an independently versioned external member.
Confirm target selection fetches only the expected carriers and an
unsupported target fails with a useful error.

## Review

Reject the change if a declared target lacks a produced artifact/evidence row, an actual package lacks a declared identity, an external extension is runtime-version-coupled, or generated SDK support tables disagree. Report upstream source identity separately from Oliphaunt package version.
4 changes: 4 additions & 0 deletions .codex/skills/add-oliphaunt-extension/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Add Oliphaunt Extension"
short_description: "Add or update a supported PostgreSQL extension"
default_prompt: "Use $add-oliphaunt-extension to add or update an Oliphaunt PostgreSQL extension."
106 changes: 106 additions & 0 deletions .codex/skills/qualify-oliphaunt-change/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,106 @@
---
name: qualify-oliphaunt-change
description: Select, run, and diagnose Oliphaunt local and GitHub CI qualification for code, package, extension, SDK, policy, workflow, or release changes. Use before merge/release, when checks are slow or duplicated, or when an exact commit must be proven publishable.
---

# Qualify Oliphaunt Change

Use the repository graph to select work, but require the full exact-SHA gate for releases.

## Local feedback

1. Inspect the diff and ask Moon for affected projects/tasks. Do not infer affected products from directory names alone.
2. Run formatting/static checks and focused unit/package tests first. Run expensive producer/E2E lanes only when their inputs or release contract changed.
3. If the diff intentionally changes WASIX binary-semantic inputs (source pins,
patches, build recipes, the WASIX toolchain, or producer code), refresh the
committed fingerprint before qualification with
`cargo run -p xtask -- assets input-fingerprint --write`. Do not refresh it
for version, changelog, package-description, smoke-expectation, or
target-envelope-only changes. See `docs/maintainers/assets.md`.
4. For any release, package identity, workflow, version, or extension change, run:

```sh
tools/dev/bun.sh tools/release/release-check.mjs
cargo run -p xtask -- assets verify-committed
tools/dev/bun.sh src/extensions/tools/check-extension-model.mjs --check
```

The canonical `release-check` runs the live repository-structure policy before
release metadata and mutation tests. Do not substitute the policy unit tests:
they prove the classifier but do not scan the candidate tree.

For source-acquisition policy or a source `mirror_url`, run
`tools/dev/bun.sh test tools/policy/source-fetch-core.test.mjs` and
`tools/dev/bun.sh tools/policy/fetch-sources.mjs all --validate-only`. Prove a
new endpoint with a live exact-commit fetch, but keep reachability out of the
deterministic unit gate. Qualification must show bounded canonical-to-mirror
failover, exact-pin rejection, canonical durable origin, and transactional
preservation of an existing checkout when every endpoint fails.

5. Use `actionlint` for workflow changes. Validate shell/JS/Python syntax before waiting for CI. If a reusable-workflow interface, nested permission, caller input, or caller job changed, also push the exact candidate to a disposable branch and dispatch one supported `publish-dry-run` compiler probe. Require GitHub to materialize the called job graph, then cancel it before expensive qualification and delete the probe branch. `actionlint` cannot prove GitHub's reusable-workflow permission ceiling or dispatch-time input compilation.
6. Declare runner capabilities on the narrowest Moon task that needs them. Use
`ci-rust` for Cargo, rustc, rustfmt, or another Rust-toolchain command;
`ci-maintainer-tools` for the pinned tools installed by
`tools/dev/bootstrap-tools.sh`; and `ci-android-sdk` for Android SDK work.
Capabilities propagate through task dependencies. The planner keeps
capability-bearing checks dedicated and combines only compatible static
checks into bounded shards.
7. Treat a hosted runner-image pin as a toolchain dependency. Never introduce a mutable `*-latest` alias; after changing an explicit runner pin, inspect the image delta and run the platform binary contract for every affected release target.

For a WASIX Docker, APT snapshot, or bootstrap trust change, also run the
product-owned fault test and source verifier before the expensive build:

```sh
bash src/runtimes/liboliphaunt/wasix/assets/build/docker/install-pinned-apt-packages.test.sh
tools/dev/bun.sh tools/policy/fetch-sources.mjs wasix-runtime --verify-only
cargo run -p xtask -- assets source-spine --strict-local
```

Then build the pinned Dockerfile from a clean builder context. Require a
successful TLS-verified snapshot transaction and the exact declared wasixcc,
Clang, and Binaryen versions; a source-spine/static check alone does not prove
that the pinned trust chain still reaches the snapshot service.

For an SDK change, run `moon run sdk-contracts:check`, then run every affected
SDK's `package` target in one Moon invocation. SDK package targets own their
same-project `check` and `test` dependencies, so this is the compact product
gate without the platform artifact or E2E matrix. Set `MOON_BASE` and
`MOON_HEAD`, then select SDK project IDs with
`moon query projects --affected --downstream deep --tags sdk --tasks package`.
Pass the exact `<project>:package` targets to `moon run`; a workspace-wide
`:package` selector also selects non-SDK products and is not this lane. Confirm
ownership with
`moon query tasks --project <sdk-project> --id package` when changing task
topology. Never replace the product task with a narrower native command: for
example, `cargo test -p oliphaunt --lib` excludes Rust executable tests under
`src/bin/**`, while `moon run oliphaunt-rust:test` includes the library,
executable, integration, build-crate, and documentation tests. Add
`release-check` when package or registry behavior changes, and run
`moon run extension-model:check` when an extension catalog or generated SDK
extension surface changes. Put new guarantees in a parsed schema/generated
contract, clean-consumer package check, or product-owned behavioral test. Do
not qualify SDK behavior by grepping prose, test names, or
implementation-source spellings.

Advisory cleanup is not qualification. Use
`moon run dev-tools:helper-reference-audit` or
`moon run dev-tools:source-reference-audit` when intentionally looking for
possibly unreferenced helpers or modules, then inspect each result before
removing it. Do not turn reference counts into a required CI gate.

## GitHub qualification

- Identify runs by workflow plus exact `headSha`; never accept “latest successful on branch.”
- The release prerequisite is the non-cancelled `Qualified` gate for that SHA, including required checks, builds, policy, tests, and selected E2E.
- When WASIX or an extension is selected, require the same-run full lifecycle evidence artifact. It must cover every promoted extension in direct, server, restart, materialization, and dump/restore modes and satisfy `--require-current-evidence` for the candidate source digest.
- Ensure artifact attestations and the publication lock reference the same SHA/tree.
- Require artifact evidence for the compatibility floors in
`docs/maintainers/release.md`: inspect Mach-O load commands, Android API/ELF
metadata, and Linux ELF symbol versions rather than inferring support from a
runner or package label.
- Do not rerun duplicate downstream E2E workflows when the same evidence is already part of the required gate.
- On failure, inspect the failing job log and earliest causal error. Fix the cause, push a new SHA, and restart qualification; do not reuse artifacts from the failed SHA.

## Report

List commands and outcomes, skipped lanes with reasons, exact GitHub run/SHA, required gate state, produced artifact/lock evidence, WASIX lifecycle evidence when selected, and residual platform gaps. “Green CI” without exact-SHA and gate names is not release evidence.
4 changes: 4 additions & 0 deletions .codex/skills/qualify-oliphaunt-change/agents/openai.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
interface:
display_name: "Qualify Oliphaunt Change"
short_description: "Run and diagnose the appropriate CI qualification"
default_prompt: "Use $qualify-oliphaunt-change to qualify this Oliphaunt change before merge or release."
Loading
Loading