@pina-rs/skill 0.10.0 → 0.11.1

package/SKILL.md

@@ -24,6 +24,7 @@ When no project exists, read [references/project-setup.md](references/project-se
 - Do not introduce `unsafe` code or unstable features.
 - Validate account identity, signer status, writability, ownership, and data shape before casts, mutation, lamport transfers, resize operations, or CPI.
 - Use explicit discriminator values and type-specific PDA seed namespaces. Prefer canonical bump validation.
+- Construct account-management operations and generated CPIs as documented instruction structs, then call `.invoke()` or `.invoke_signed(signers)`. Do not recreate the removed free-function helper API.
 - Keep instruction dispatch deterministic: parse once, match explicitly, then construct and validate the accounts type for that instruction.
 - Maintain discriminator-first, fixed-layout storage types expected by Pina and zeropod. Do not place ordinary Rust `bool`, `String`, or variable-length collections in zero-copy account layouts.
 - Preserve error values and wire formats unless the user explicitly accepts a compatibility change.

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@pina-rs/skill",
-	"version": "0.10.0",
+	"version": "0.11.1",
 	"description": "Agent skill for creating and maintaining secure Pina Solana programs",
 	"keywords": [
 		"agent",

package/references/cli-and-codegen.md

@@ -15,6 +15,7 @@ pina idl diff --help
 pina idl publish --help
 pina docs --help
 pina init --help
+pina lint --help
 pina test --help
 pina dev --help
 pina keys --help
@@ -32,6 +33,7 @@ Use `pina docs` to list bundled terminal topics. Custom topics can be supplied t
 Run project-aware commands from the program directory or any descendant. Pina uses the nearest ancestor `Pina.toml`; an existing unambiguous Cargo package also works without configuration.
 
 ```sh
+pina lint
 pina build
 pina test --unit
 pina test
@@ -44,6 +46,8 @@ pina generate
 pina build --features logs,cpi --no-default-features
 ```
 
+Run `pina lint` before review to execute the official Pina security lint set associated with the installed CLI release. Use `pina lint --fix` only when source edits are authorized, then inspect and test every change. The command intentionally ignores additional project Dylint metadata; use direct `cargo dylint` only after reviewing and pinning any extra native lint libraries.
+
 The library target name determines the canonical outputs:
 
 ```text

package/references/program-authoring.md

@@ -45,11 +45,67 @@ Use a stable, type-specific byte-string namespace as the first seed. Prefer cano
 
 Seed changes alter addresses. Treat them as migrations, not refactors.
 
+## Account-management instruction builders
+
+Pina models account creation, PDA allocation, reallocation, and close operations as values. Construct the documented struct with every input visible, then call `.invoke()` for transaction-level signers or `.invoke_signed(signers)` when another CPI account must sign through program-derived seeds.
+
+```rust
+CreateAccount {
+	from: payer,
+	to: new_account,
+	space: 128,
+	owner: program_id,
+}
+.invoke()?;
+```
+
+Do not introduce wrapper functions around removed helpers such as `create_account(...)`, `create_program_account::<T>(...)`, or `realloc_account(...)`. Use the matching builder:
+
+| Operation                                             | Builder                        |
+| ----------------------------------------------------- | ------------------------------ |
+| Create a regular account                              | `CreateAccount`                |
+| Derive and create a typed canonical PDA               | `CreateProgramAccount`         |
+| Validate an explicit bump and create a typed PDA      | `CreateProgramAccountWithBump` |
+| Derive and allocate an untyped canonical PDA          | `AllocateAccount`              |
+| Validate an explicit bump and allocate an untyped PDA | `AllocateAccountWithBump`      |
+| Reallocate while balancing rent                       | `ReallocAccount`               |
+| Reallocate with explicit zero-initialization intent   | `ReallocAccountZeroed`         |
+| Close and return lamports                             | `CloseAccount`                 |
+| Zero bytes, close, and return lamports                | `CloseAccountZeroed`           |
+
+Typed PDA creation places the account type on the invocation method:
+
+```rust
+let (address, bump) = CreateProgramAccount {
+	account: state_account,
+	payer,
+	owner: program_id,
+	seeds,
+}
+.invoke::<State>()?;
+```
+
+Canonical PDA builders derive and validate the target address and return `(Address, u8)`. Explicit-bump builders verify the supplied bump before moving lamports. Both forms automatically append the target PDA signer to additional signers supplied by the caller. Use `u64` for create/allocation `space`; reallocation `new_size` remains `usize`.
+
+Close builders intentionally expose only `.invoke()`. They perform checked direct account mutation rather than a CPI, so signer seeds would have no effect.
+
+Generated CPI modules follow the same shape. Construct the generated instruction struct using its documented public account and data fields, then invoke it with the validated program account:
+
+```rust
+instructions::Update {
+	accounts,
+	new_price,
+}
+.invoke_signed(&program, signers)?;
+```
+
+Do not add free convenience constructors to generated CPI modules. Keeping accounts and instruction data visible at construction makes privilege and wire-data review possible at the call site.
+
 ## Initialization, resize, and close
 
-Initialization must prove that the target is empty and that its derived address is correct before allocating or writing state. Resize operations must validate authority, owner, address, writability, and the requested bounds before changing data length.
+Initialization must prove that the target is empty and that its derived address is correct before invoking a create or allocation builder. Resize operations must validate authority, owner, address, writability, and the requested bounds before invoking a reallocation builder.
 
-When closing an account, use the Pina close helper that matches the data-erasure requirement. Zero account data before transferring lamports when stale bytes must not remain observable.
+When closing an account, choose `CloseAccount` or `CloseAccountZeroed` according to the data-erasure requirement. Zero account data before transferring lamports when stale bytes must not remain observable.
 
 ## Compatibility review
 

package/references/project-setup.md

@@ -9,13 +9,14 @@ pina init counter_program
 cd counter_program
 pina doctor
 pina keys show
+pina lint
 pina build
 pina test --unit
 pina test
 pina generate
 ```
 
-The scaffold pins the nightly toolchain and `rust-src` needed by `pina build`; install its compatible linker with `cargo install sbpf-linker --version 0.1.8 --locked` before the first SBF build. TypeScript client generation also requires Node.js with npm and `npx`. Keep the generated `Pina.toml` as the project-local discovery and client-selection contract.
+The scaffold pins the nightly toolchain and `rust-src` needed by `pina build`; install its compatible linker with `cargo install sbpf-linker --version 0.1.8 --locked` before the first SBF build. It also records immutable-revision official Pina lint metadata and pinned Dylint binary versions. `pina lint` prepares those tools below Cargo home on first use. TypeScript client generation also requires Node.js with npm and `npx`. Keep the generated `Pina.toml` as the project-local discovery and client-selection contract.
 
 Before deployment, establish the program identity explicitly. Use `pina keys new` for a fresh local identity or validate a keypair produced by trusted platform tooling with `pina keys sync --keypair <path>`. Never use `--force` unless the intended operation is an identity rotation.