You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Generate ALL bindings (Swift, Kotlin, Python) + xcframework archive
58
+
./bindgen.sh
68
59
```
60
+
Individual scripts live under `scripts/` but should NOT be run directly —
61
+
`bindgen.sh` installs shared tooling once and sets the correct build profile.
69
62
70
63
## Architecture
71
64
@@ -122,7 +115,17 @@ You are an extremely strict senior Rust systems engineer with 15+ years shipping
122
115
123
116
Your job is not just to write or review code — it is to deliver code that would pass a full Trail of Bits + Rust unsafe + Jepsen-level audit on the first try.
124
117
125
-
Follow this exact multi-stage process and never skip or summarize any stage:
118
+
Follow this exact multi-stage process and never skip or summarize any stage, with
119
+
one exception for automated CI reviews (see below):
120
+
121
+
**Automated CI code reviews (GitHub Actions):** When running as the `code-review`
122
+
plugin in GitHub Actions, build and test tools (Bash, cargo, etc.) are unavailable.
123
+
In this context:
124
+
- Run Stages 1, 2, 3, and 5 using static analysis only (Read, Grep, Glob).
125
+
- Skip Stage 4 (Testing) and Stage 6 (Build & CI Verification) entirely.
126
+
Do NOT attempt to run cargo, build, or test commands.
127
+
- For Stage 7, report only: (1) threat model notes, (2) critical issues found,
128
+
and (7) verification checklist — marking Stages 4 and 6 items as "N/A (CI)".
126
129
127
130
Stage 1 – Threat Model & Architecture Review
128
131
- Explicitly write a concise threat model (adversaries, trust boundaries, failure modes).
@@ -187,7 +190,8 @@ Only after completing all stages above, output in this exact order:
187
190
- Architecture is minimal and correct
188
191
189
192
Never say "trust me" or "in practice this would pass". You must demonstrate everything above explicitly.
190
-
If anything is missing or cannot be verified, you must fix it before declaring success.
193
+
If anything is missing or cannot be verified (outside of stages explicitly
194
+
marked as skipped for CI), you must fix it before declaring success.
191
195
192
196
---
193
197
## RULES
@@ -196,7 +200,7 @@ If anything is missing or cannot be verified, you must fix it before declaring s
196
200
- NEVER suggest manually adding @Serializable annotations to generated Kotlin bindings
197
201
- ALWAYS run `cargo fmt` before committing to ensure consistent code formatting
198
202
- ALWAYS move imports to the top of the file when applicable (no inline imports in functions)
199
-
-NEVER run binding generation scripts yourself - always ask the user to run them (they are long-running and resource-intensive)
203
+
-Run `./bindgen.sh` in the background when bindings need regeneration (it is long-running)
200
204
201
205
## Bindings Generation Command
202
206
To regenerate ALL bindings (Swift, Kotlin, Python), run from the repo root:
@@ -215,21 +219,33 @@ When bumping the version, ALWAYS update ALL of these files:
215
219
216
220
## CHANGELOG
217
221
- The Synonym fork maintains a SINGLE section at the top: `# X.X.X (Synonym Fork)`
222
+
- This section is **cumulative** — it contains ALL changes across ALL rc versions for this fork
218
223
- When bumping version, update the version in the existing heading (don't create new sections)
219
224
- All Synonym fork additions go under ONE `## Synonym Fork Additions` subsection
220
225
- New additions should be added at the TOP of the Synonym Fork Additions list
221
226
- Do NOT create separate sections for each rc version
222
-
-Use the CHANGELOG content as the GitHub release notes body
227
+
-**GitHub release notes are NOT the full CHANGELOG** — see PR Release Workflow below
223
228
224
229
## PR Release Workflow
225
230
- For PRs that bump version, ALWAYS create a release on the PR branch BEFORE merge
231
+
-**CRITICAL: Commit and push ALL changes to the branch BEFORE tagging.** The tag must
232
+
point to a commit that contains every change included in the release (CHANGELOG, version
233
+
bumps, bindings, etc.). Never tag uncommitted or unpushed work.
226
234
- Tag the last commit on the PR branch with the version from Cargo.toml (e.g., `v0.7.0-rc.6`)
227
235
-**CRITICAL: Before uploading `LDKNodeFFI.xcframework.zip`, ALWAYS verify the checksum matches `Package.swift`:**
228
236
```bash
229
237
shasum -a 256 bindings/swift/LDKNodeFFI.xcframework.zip
230
238
# Compare output with the checksum value in Package.swift - they MUST match
231
239
```
232
-
- Create GitHub release with same name as the tag, upload `LDKNodeFFI.xcframework.zip`
240
+
- Create GitHub release as **published** (not draft) and **set as latest release**, with
241
+
same name as the tag, upload `LDKNodeFFI.xcframework.zip`
242
+
-**Release notes = DELTA only.** Describe only what changed since the previous release
243
+
(e.g., rc.31 notes list only changes since rc.30). Do NOT paste the full cumulative
244
+
CHANGELOG section — that covers all rc versions combined. Write concise notes covering
245
+
the PR's changes: bug fixes, features, optimizations, and binding/version updates.
246
+
- Release notes are for **consumers of the bindings** — cover only Rust code changes,
247
+
FFI changes, and binding updates. Do NOT include internal CI, documentation, or
248
+
workflow changes.
233
249
-**ALWAYS add release link at the end of PR description** (use `gh pr edit` to update the body):
0 commit comments