@ketecode/loom 0.0.0-stage → 0.2.0

package/skills/social-media-publishing/references/platform-apis.md

@@ -0,0 +1,116 @@
+# Platform API shapes
+
+Request shapes for the common publish paths. Check each platform's docs for the current API version, access tier and limits before relying on these.
+
+## X (docs.x.com)
+
+Auth: OAuth 2.0 authorization code with PKCE, user-context token in `Authorization: Bearer`. `POST /2/tweets` accepts only user-context tokens (OAuth 2.0 user token with `tweet.read`, `users.read`, `tweet.write`, or OAuth 1.0a user token); app-only tokens cannot post. Without `offline.access` the token lasts two hours and no refresh token is issued.
+
+Chunked media upload:
+
+```
+POST https://api.x.com/2/media/upload/initialize
+{ "media_type": "video/mp4", "total_bytes": 10485760, "media_category": "tweet_video" }
+-> { "data": { "id": "<media_id>", ... } }
+
+POST https://api.x.com/2/media/upload/<media_id>/append      (multipart: segment_index, media)
+POST https://api.x.com/2/media/upload/<media_id>/finalize
+GET  https://api.x.com/2/media/upload?command=STATUS&media_id=<media_id>
+     repeat after processing_info.check_after_secs until state is "succeeded"
+```
+
+- Do not send `command=INIT|APPEND|FINALIZE` to `POST /2/media/upload`; that is the previous protocol.
+- Keep each chunk at or under 5 MB (the server maximum is 8 MB). `media_category` values include `tweet_image`, `tweet_gif`, `tweet_video`, `amplify_video`, `dm_image`, `dm_gif`, `dm_video`, `subtitles`. Status states are `pending`, `in_progress`, `succeeded`, `failed`. Size and duration limits depend on the user's account type.
+
+Create the post:
+
+```
+POST https://api.x.com/2/tweets
+{ "text": "Shipping today", "media": { "media_ids": ["<media_id>"] } }
+```
+
+`media_ids` takes 1 to 4 IDs.
+
+Threads: post the first, then each next post with `"reply": { "in_reply_to_tweet_id": "<previous id>" }`.
+
+Access tiers and pricing change; confirm in the developer console which endpoints and volumes the user's plan includes.
+
+## LinkedIn (learn.microsoft.com/linkedin)
+
+Every versioned call sends `Linkedin-Version: YYYYMM` and `X-Restli-Protocol-Version: 2.0.0`. Versions are released monthly and supported for at least one year before sunset; a sunset or missing version returns an error, so keep the header current.
+
+Image:
+
+```
+POST https://api.linkedin.com/rest/images?action=initializeUpload
+{ "initializeUploadRequest": { "owner": "urn:li:organization:123" } }
+-> { "value": { "uploadUrl": "https://www.linkedin.com/dms-uploads/...", "image": "urn:li:image:C4E..." } }
+
+PUT <uploadUrl>   (raw bytes, Authorization header)
+GET https://api.linkedin.com/rest/images/urn:li:image:C4E...   until status is AVAILABLE
+```
+
+Video: `POST /rest/videos?action=initializeUpload` with `owner` and `fileSizeBytes` returns `uploadInstructions` (one upload URL per 4 MB byte range) and an `uploadToken`. PUT each part and keep the `ETag` response header, then `POST /rest/videos?action=finalizeUpload` with `video`, `uploadToken` and `uploadedPartIds` (the ETags, in part order). Poll `GET /rest/videos/{urn}` until status is `AVAILABLE`.
+
+Post:
+
+```
+POST https://api.linkedin.com/rest/posts
+{
+  "author": "urn:li:organization:123",
+  "commentary": "Text of the post",
+  "visibility": "PUBLIC",
+  "distribution": { "feedDistribution": "MAIN_FEED", "targetEntities": [], "thirdPartyDistributionChannels": [] },
+  "content": { "media": { "id": "urn:li:image:C4E...", "altText": "Describe the image" } },
+  "lifecycleState": "PUBLISHED",
+  "isReshareDisabledByAuthor": false
+}
+-> 201, post URN in the x-restli-id response header
+```
+
+- Member posts: `w_member_social`, author `urn:li:person:<sub from /v2/userinfo>`.
+- Company posts: `w_organization_social`, and the member must hold the ADMINISTRATOR, CONTENT_ADMIN or DIRECT_SPONSORED_CONTENT_POSTER role on the page.
+- LinkedIn Help gives 3,000 characters as the post limit; the API returns `FIELD_LENGTH_TOO_LONG` when `commentary` is over its maximum. `commentary` uses LinkedIn's "little text" format: escape the reserved characters `| { } @ [ ] ( ) < > # \ * _ ~` with a backslash whenever they are plain text rather than mention or hashtag syntax. Mentions are `@[Name](urn:li:organization:123)`; the name must match the entity's name.
+- `ugcPosts` is legacy (the Posts API replaces it); use `/rest/posts`.
+
+## Facebook Page (developers.facebook.com, Graph API)
+
+Use a Page access token for a Page the user manages. Facebook Login requests `pages_manage_engagement`, `pages_manage_posts`, `pages_read_engagement` and `pages_read_user_engagement`, plus `publish_video` for video.
+
+```
+POST https://graph.facebook.com/<version>/<page-id>/feed
+  message=...&link=https://...
+POST https://graph.facebook.com/<version>/<page-id>/photos
+  url=https://.../image.jpg&caption=...
+Scheduled: add published=false&scheduled_publish_time=<unix time>   (10 minutes to 30 days from the request)
+```
+
+Pin a Graph API version in the URL (`v<major>.0`) and upgrade before Meta retires it.
+
+## Instagram professional account
+
+```
+POST https://graph.facebook.com/<version>/<ig-user-id>/media          (Facebook Login)
+POST https://graph.instagram.com/<version>/<ig-user-id>/media         (Instagram Login)
+  image_url=https://public.example.com/a.jpg&caption=...
+  or media_type=REELS&video_url=...
+  or media_type=CAROUSEL with children=<up to 10 container ids>
+-> { "id": "<container id>" }
+
+GET  .../<container id>?fields=status_code     IN_PROGRESS -> FINISHED (or ERROR; EXPIRED if not published within 24 hours)
+POST .../<ig-user-id>/media_publish   creation_id=<container id>
+GET  .../<ig-user-id>/content_publishing_limit   current usage against the 24-hour cap
+```
+
+- Media must be at a publicly reachable HTTPS URL; Meta fetches it.
+- There is a rolling 24-hour cap on API-published posts per account (carousels count as one). Meta's pages have stated different numbers over time; read `content_publishing_limit` instead of hard-coding it.
+- The API requires an Instagram professional (business or creator) account; personal accounts are not supported.
+- Captions: at most 2,200 characters, 30 hashtags and 20 @ tags.
+- Permissions: `instagram_business_basic` and `instagram_business_content_publish` (Instagram Login, `graph.instagram.com`), or `instagram_basic`, `instagram_content_publish` and `pages_read_engagement` (Facebook Login, `graph.facebook.com`).
+
+## Sources
+
+- X chunked upload: https://docs.x.com/x-api/media/quickstart/media-upload-chunked . Create post: https://docs.x.com/x-api/posts/create-post . Scopes: https://docs.x.com/fundamentals/authentication/oauth-2-0/authorization-code . Character counting: https://docs.x.com/fundamentals/counting-characters
+- LinkedIn Posts API: https://learn.microsoft.com/en-us/linkedin/marketing/community-management/shares/posts-api . little text: https://learn.microsoft.com/en-us/linkedin/marketing/community-management/shares/little-text-format . Videos: https://learn.microsoft.com/en-us/linkedin/marketing/community-management/shares/videos-api . Versioning: https://learn.microsoft.com/en-us/linkedin/marketing/versioning . Post length: https://www.linkedin.com/help/linkedin/answer/a528176
+- Facebook Pages posts: https://developers.facebook.com/docs/pages-api/posts
+- Instagram publishing: https://developers.facebook.com/docs/instagram-platform/content-publishing . Media reference (caption limits): https://developers.facebook.com/docs/instagram-platform/instagram-graph-api/reference/ig-user/media

package/skills/solidity-patterns/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: solidity-patterns
+description: Writes Solidity contracts for Ethereum and other EVM chains the safe way, applying checks-effects-interactions ordering, Ownable2Step or AccessControl roles, OpenZeppelin Contracts instead of hand-rolled tokens, a deliberate choice between immutable and UUPS or transparent proxy deployments with ERC-7201 namespaced storage, events for every state change, custom errors and basic gas hygiene, inside a Foundry or Hardhat project with tests. Use when creating or extending a smart contract, adding an ERC-20, ERC-721 or ERC-1155 token, deciding whether a contract should be upgradeable, or setting up a new Foundry or Hardhat workspace.
+license: MIT
+compatibility: Any Agent Skills host. Needs Foundry (forge) or Hardhat with Node.js to compile and test. Examples target Solidity 0.8.x and OpenZeppelin Contracts 5.x.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: security
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "forge"
+  kete-loom/owner: "Kete-org"
+---
+
+# Solidity patterns
+
+Write contracts that are boring on purpose: audited building blocks, state updated before any external call, every privileged function guarded, every change logged by an event, and tests that try to break it. Deployed code is public and usually permanent, so a bug is a loss, not a ticket. This is engineering guidance, not financial or legal advice.
+
+## Ground rules
+
+1. **Pin the compiler.** `pragma solidity 0.8.x;` with an exact version in `foundry.toml` (`solc_version`) or `hardhat.config` (`solidity.version`). 0.8 reverts on overflow by default; `unchecked { }` only where you proved the bound in a comment.
+2. **Use OpenZeppelin Contracts** (`@openzeppelin/contracts`, or `@openzeppelin/contracts-upgradeable` for proxies) for tokens, access control, `ReentrancyGuard`, `SafeERC20`, `ECDSA`, `EIP712`. Never copy-paste or re-implement an ERC standard. Pin the library version.
+3. **Checks-effects-interactions.** Validate inputs (checks), write storage (effects), then call other contracts or send ETH (interactions). Add `nonReentrant` on functions that make external calls and touch balances anyway.
+4. **Guard every privileged function** (`mint`, `pause`, `setFee`, `withdraw`, `upgradeTo...`, initializers). Default to `Ownable2Step` for a single admin or `AccessControl` for several roles; the owner should be a multisig or timelock in production, not a laptop key.
+5. **Events for every state change** an off-chain system or user cares about: transfers, role grants, parameter changes, upgrades, pauses. Index the fields people filter on (addresses, IDs), at most three indexed.
+6. **Custom errors** (`error InsufficientBalance(uint256 have, uint256 want);` with `revert InsufficientBalance(...)`) instead of revert strings.
+7. **Pull over push** for payouts: record what each address is owed and let it `withdraw()`; never loop over an unbounded array sending ETH.
+8. **No `tx.origin` for auth**, no `block.timestamp` or `blockhash` as randomness, no `selfdestruct`, no `delegatecall` to an address a user can influence.
+
+## Project layout
+
+Foundry (preferred for new work): `forge init`, then
+
+```
+src/            contracts
+test/           *.t.sol tests (forge-std Test), fuzz and invariant tests
+script/         *.s.sol deploy scripts (forge script)
+lib/            dependencies (forge install OpenZeppelin/openzeppelin-contracts)
+foundry.toml    solc_version, optimizer, remappings, [fuzz] runs
+```
+
+Hardhat: `contracts/`, `test/`, `ignition/modules/` or `scripts/`, `hardhat.config.ts`, dependencies from npm. Follow whichever the repo already uses; don't mix both without reason.
+
+Keys and RPC URLs come from environment variables or an encrypted keystore (`cast wallet import`), never from committed files.
+
+## Steps for a new or changed contract
+
+1. **Write the spec first** in the contract's NatSpec: who can call each external function, what invariants must hold (for example "sum of balances == totalSupply", "only owner can mint"), and what happens on failure.
+2. **Pick the building block.** Token: inherit `ERC20`, `ERC721` or `ERC1155` and add only what's needed (`ERC20Permit`, `ERC20Votes`, `Pausable`). Do not override `transfer` or `_update` hooks unless the spec needs it, and then call `super`.
+3. **Decide on upgradeability** using the table below. Write the answer and the reason at the top of the contract.
+4. **Write the contract** following the ground rules. Mark functions `external` when not called internally, state `immutable` or `constant` where possible, and visibility on everything.
+5. **Handle tokens defensively.** Use `SafeERC20` (`safeTransfer`, `safeTransferFrom`, `forceApprove`) for arbitrary ERC-20s. For deposits, measure the balance before and after if fee-on-transfer tokens are possible, or document that they're unsupported.
+6. **Test**: unit tests for each function and each revert, a test per access-controlled function proving a stranger is rejected, fuzz tests on amount inputs, and invariant tests for the spec's invariants (`forge test`, `[invariant]` in `foundry.toml`). Fork tests (`--fork-url`) when integrating live protocols.
+7. **Static analysis**: run `slither .` and fix or justify every finding. For the full audit procedure use the `smart-contract-security` skill.
+8. **Deploy** to a local node (`anvil`) and a testnet first with the same script you'll use on mainnet; verify the source on the block explorer.
+
+## Upgradeability: decide deliberately
+
+| Option | Choose when | Costs |
+|---|---|---|
+| Immutable contract | Logic is small, well tested, and trust minimisation matters | Bugs need a migration to a new address |
+| UUPS proxy (`UUPSUpgradeable`) | You need upgrades and want them cheap; upgrade logic lives in the implementation | Forgetting `_authorizeUpgrade` access control, or shipping an implementation without it, can brick or hand over the proxy |
+| Transparent proxy (`TransparentUpgradeableProxy`) | You want the admin path separated from user calls | Extra deploy cost; in OZ 5.x the proxy deploys its own `ProxyAdmin` owned by `initialOwner` |
+
+Rules for any proxy:
+
+- No constructor logic; use an `initialize` function with the `initializer` modifier, call every parent `__X_init`, and call `_disableInitializers()` in the implementation's constructor.
+- Use ERC-7201 namespaced storage (the OZ 5.x upgradeable contracts do) or append-only layouts; never reorder, remove or change the type of an existing state variable.
+- Check every upgrade with the OpenZeppelin Upgrades plugin (`@openzeppelin/hardhat-upgrades` or `openzeppelin-foundry-upgrades`) before deploying it.
+- Put upgrades behind a multisig and, where users hold funds, a timelock so they can exit.
+
+## Gas basics (after correctness)
+
+- Cache storage reads in memory inside loops; pack small types that are read together into one slot.
+- `calldata` instead of `memory` for read-only external array and struct arguments.
+- `immutable`/`constant` for values fixed at deploy.
+- Avoid unbounded loops over user-growable arrays; they become a denial of service once gas exceeds the block limit.
+- Measure with `forge test --gas-report` or `forge snapshot` before and after; never trade a safety check for gas.
+
+## Stop and ask the user
+
+- Before deploying or broadcasting anything to a mainnet, or to any network with real funds; confirm the network, chain ID and deployer address.
+- Who should own admin roles in production (EOA, multisig, timelock, or renounced).
+- Whether the contract should be upgradeable at all, when the spec doesn't say.
+- Before writing token economics, fees or anything that holds user funds and will launch without a professional audit; recommend one.
+
+## Never
+
+- Never put private keys, mnemonics or RPC keys in source, tests or scripts.
+- Never write a custom ERC-20/721 from scratch, a custom signature scheme, or inline assembly to save gas without a written reason and tests.
+- Never leave an initializer unprotected or an implementation contract uninitialized.
+- Never claim a contract is secure; say what was tested and what wasn't.
+
+## Before you finish
+
+Report: compiler version, libraries and versions, upgradeability choice and why, roles and who holds them, events emitted, test and fuzz results (`forge test` output summary), Slither results, and what still needs an external audit.

package/skills/solidity-patterns/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Write an ERC-20 token contract with a capped supply and an owner-only mint using Foundry",
+    "Should our staking vault contract be upgradeable with UUPS or deployed immutable?",
+    "Set up a new Foundry project with OpenZeppelin and a basic NFT contract",
+    "Add a withdraw function to my Solidity escrow contract that follows checks-effects-interactions",
+    "Refactor this Solidity contract to use custom errors and emit events when the fee changes"
+  ],
+  "should_not_trigger": [
+    "Audit our lending protocol contracts for oracle manipulation and reentrancy before launch",
+    "Connect MetaMask to our React app with viem and show the user's USDC balance",
+    "Review the Solidity diff in this PR for missing access control and storage collisions",
+    "Integrate Stripe subscriptions into the billing page",
+    "Write a Rust program that parses a CSV of transactions"
+  ]
+}

package/skills/spring-boot-patterns/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: spring-boot-patterns
+description: Spring Boot application structure and conventions, covering controller-service-repository layering, constructor injection, typed @ConfigurationProperties, @Transactional boundaries, Bean Validation, ProblemDetail error responses, SecurityFilterChain setup, Actuator exposure and focused test slices such as @WebMvcTest and @DataJpaTest. Use when building or changing a Spring Boot service, adding an endpoint or configuration, securing routes, wiring health checks, or writing Spring Boot tests.
+license: MIT
+compatibility: Any Agent Skills host. Needs a JDK and the project's Maven or Gradle wrapper. Written for Spring Boot 3.x and 4.x; version-specific differences are called out.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: coding
+  kete-loom/risk: runs-commands
+  kete-loom/requires: "java"
+  kete-loom/owner: "Kete-org"
+---
+
+# Spring Boot patterns
+
+Write Spring Boot code that is easy to test, fails loudly on bad configuration, and keeps transactions and security explicit. For entity mapping, fetch plans and N+1 problems, use the `jpa-hibernate` skill alongside this one.
+
+## 0. Before you change anything
+
+1. Find the Boot version in `pom.xml` (`spring-boot-starter-parent`) or `build.gradle(.kts)` (`org.springframework.boot` plugin). Boot 3 and 4 differ in test setup and Jackson (see `references/testing.md`).
+2. Find the build command: `./mvnw verify` or `./gradlew build`. Run it once and record the result. If it already fails, **stop and tell the user** before editing.
+3. Read one existing controller, service and test, and follow their package layout, naming and style. Don't introduce a second style.
+
+## 1. Structure
+
+- Package **by feature** (`orders/`, `billing/`), not by layer, unless the project already does otherwise. Keep the `@SpringBootApplication` class in the root package so component scanning finds everything.
+- Layers inside a feature:
+  - **Controller**: HTTP only. Parse, validate, call one service method, map to a response DTO. No repository calls, no business rules.
+  - **Service**: business rules and the transaction boundary.
+  - **Repository**: Spring Data interfaces. No business logic.
+- Never return JPA entities from controllers. Map to records (`record OrderResponse(...)`) so lazy fields, internal columns and cycles never leak into JSON.
+
+## 2. Dependency injection
+
+- Use **constructor injection** with `final` fields. One constructor needs no `@Autowired`. Never use field injection in new code.
+- Prefer one implementation per interface. When there are several, choose with `@Qualifier` or a `Map<String, T>` injection, not `@Primary` scattered around.
+- A circular dependency is a design bug. Split the class; don't enable `spring.main.allow-circular-references`.
+
+## 3. Configuration
+
+- Bind related settings to a typed record and validate it at startup:
+
+  ```java
+  @ConfigurationProperties(prefix = "payments")
+  @Validated
+  public record PaymentsProperties(@NotBlank String baseUrl, @NotNull Duration timeout) {}
+  ```
+
+  Register it with `@ConfigurationPropertiesScan` (or `@EnableConfigurationProperties`). Prefer this over many `@Value` fields.
+- Secrets come from environment variables or a secret store, never committed `application.yml`. Relaxed binding maps `PAYMENTS_BASEURL` to `payments.base-url`.
+- Profiles (`application-dev.yml`, `spring.profiles.active`) change environment details, not behaviour. Never gate business logic on a profile name.
+- Set `spring.jpa.open-in-view=false` in new services so lazy loading can't run during view rendering (Boot logs a warning while it is left on).
+
+## 4. Transactions
+
+- Put `@Transactional` on **public service methods**, not controllers or repositories. Use `@Transactional(readOnly = true)` for queries.
+- The annotation works through a proxy, so it is **ignored** on a call from another method in the same class (self-invocation) and on private methods. Move the method to another bean if it needs its own transaction.
+- By default only unchecked exceptions roll back. If a checked exception must roll back, set `rollbackFor`.
+- Never call a slow remote API (payment provider, email) inside a database transaction. Commit first, then call out, or use an outbox table or `@TransactionalEventListener(phase = AFTER_COMMIT)`.
+
+## 5. Validation and errors
+
+- Annotate request DTOs with Jakarta Bean Validation (`@NotBlank`, `@Size`, `@Email`) and the controller parameter with `@Valid`. Needs `spring-boot-starter-validation`.
+- Return RFC 9457 problem details. Set `spring.mvc.problemdetails.enabled=true` or add one `@RestControllerAdvice` (extending `ResponseEntityExceptionHandler`) that maps domain exceptions to `ProblemDetail` with the right status:
+
+  ```java
+  @ExceptionHandler(OrderNotFoundException.class)
+  ProblemDetail notFound(OrderNotFoundException e) {
+      return ProblemDetail.forStatusAndDetail(HttpStatus.NOT_FOUND, e.getMessage());
+  }
+  ```
+
+- Never return stack traces, SQL or exception class names to clients. Log them server-side with a correlation id.
+- Don't catch an exception just to log and rethrow it; let the advice handle it once.
+
+## 6. Security basics
+
+- Configure Spring Security with a `SecurityFilterChain` bean (the old `WebSecurityConfigurerAdapter` is gone):
+
+  ```java
+  @Bean
+  SecurityFilterChain api(HttpSecurity http) throws Exception {
+      return http
+          .authorizeHttpRequests(a -> a
+              .requestMatchers("/actuator/health/**").permitAll()
+              .anyRequest().authenticated())
+          .oauth2ResourceServer(o -> o.jwt(Customizer.withDefaults()))
+          .build();
+  }
+  ```
+
+- Deny by default: end with `.anyRequest().authenticated()` (or `denyAll()`), and permit only named paths.
+- Disable CSRF only for stateless token-authenticated APIs; keep it for cookie sessions.
+- Hash passwords with `PasswordEncoderFactories.createDelegatingPasswordEncoder()` (bcrypt by default). Never store or log raw passwords or tokens.
+- Check ownership in the service ("does this order belong to the caller?"), not only the role. `@PreAuthorize` needs `@EnableMethodSecurity`.
+- **Stop and ask the user** before changing who can reach an endpoint, the auth mechanism, or CORS origins.
+
+## 7. Actuator
+
+- Add `spring-boot-starter-actuator`. Only `health` is exposed over HTTP by default; keep it that way and expose more by name (`management.endpoints.web.exposure.include=health,info,prometheus`), never `*` on a public port.
+- Use the liveness and readiness health groups (`/actuator/health/liveness`, `/actuator/health/readiness`, enabled by default) for container probes. Readiness may check dependencies; liveness must not, or a database outage restarts every pod.
+- Put management on a separate port (`management.server.port`) when the platform allows, and protect anything beyond health.
+
+## 8. Testing
+
+Use the narrowest slice that covers the behaviour. Details, annotations and Boot 3 versus 4 differences are in `references/testing.md`.
+
+| What you test | Use |
+|---|---|
+| Pure business logic | Plain JUnit, no Spring context |
+| Controller: routing, validation, status codes, JSON | `@WebMvcTest(OrderController.class)` with `@MockitoBean` services; `@Import` your security config |
+| Repository queries and mappings | `@DataJpaTest` with `@AutoConfigureTestDatabase(replace = NONE)` and a Testcontainers database |
+| Full wiring, security and config | `@SpringBootTest` sparingly, with `@ServiceConnection` containers |
+
+- Assert status, body and problem details for error paths, not only the happy path.
+- Test security rules: an unauthenticated request gets 401, the wrong user gets 403 or 404.
+- Don't use H2 to stand in for PostgreSQL or MySQL in repository tests; dialect differences hide real bugs.
+
+## Never
+
+- Field injection, entities in API responses, or `@Transactional` on private or self-invoked methods.
+- `permitAll()` on everything "for now", or `exposure.include=*` in production.
+- `spring.jpa.hibernate.ddl-auto=update` or `create` outside local dev; use migrations.
+- Catching `Exception` in controllers and returning 200 with an error message.
+
+## Before you finish
+
+Run the full build (`./mvnw verify` or `./gradlew build`). Report: what changed (files), new config keys and their defaults, security rules touched, tests added, and the final test counts.

package/skills/spring-boot-patterns/evals/triggers.json

@@ -0,0 +1,18 @@
+{
+  "should_trigger": [
+    "Add a new REST endpoint to our Spring Boot order service with request validation and proper 404 responses",
+    "Bind the payments.* settings in application.yml to a typed config class in Spring Boot",
+    "My @Transactional method in the Spring service doesn't roll back when called from the same class, why?",
+    "Lock down our Spring Boot API with a SecurityFilterChain and JWT resource server, keeping actuator health public",
+    "Write a @WebMvcTest for the invoice controller using MockitoBean instead of MockBean",
+    "Which actuator endpoints should a Spring Boot app expose for Kubernetes liveness and readiness probes?"
+  ],
+  "should_not_trigger": [
+    "Our Hibernate entities trigger hundreds of selects when loading the order list, fix the N+1",
+    "Build a Quarkus REST endpoint backed by Panache and make it compile to a native image",
+    "Add JWT authentication and StatusPages error handling to my Ktor server",
+    "Review this Java pull request for null handling and resource leaks",
+    "Fix the Maven build: cannot find symbol after upgrading the JDK to 21",
+    "Write JUnit 5 parameterized tests for this plain Java date parsing utility"
+  ]
+}

package/skills/spring-boot-patterns/references/testing.md

@@ -0,0 +1,72 @@
+# Spring Boot testing reference
+
+## Slice annotations
+
+| Annotation | Loads | Typical collaborators |
+|---|---|---|
+| `@WebMvcTest(X.class)` | MVC infrastructure, controller `X`, advice, filters (not `@Configuration` or `@Component` beans) | `MockMvc` or `MockMvcTester`, `@MockitoBean` services |
+| `@WebFluxTest(X.class)` | WebFlux infrastructure for controller `X` | `WebTestClient` |
+| `@DataJpaTest` | JPA, repositories, `TestEntityManager`; each test rolls back | Testcontainers database |
+| `@JsonTest` | Jackson configuration | `JacksonTester` |
+| `@RestClientTest` | `RestClient` / `RestTemplate` builders | `MockRestServiceServer` |
+| `@SpringBootTest` | The whole application | `@AutoConfigureMockMvc`, real containers |
+
+`@DataJpaTest` replaces the datasource with an embedded one by default. To test against a container, add `@AutoConfigureTestDatabase(replace = Replace.NONE)` and import the container configuration below.
+
+`@WebMvcTest` does not pick up a `SecurityFilterChain` defined in your own `@Configuration` class, so the slice runs Boot's default security instead of your rules. `@Import(SecurityConfig.class)` into the test; with a JWT resource server, also add `@MockitoBean JwtDecoder` so the context starts without an issuer.
+
+## Mocks
+
+- `@MockitoBean` and `@MockitoSpyBean` (Spring Framework 6.2+) replace `@MockBean` and `@SpyBean`. `@MockBean` is deprecated in Boot 3.4 and removed in Boot 4.
+- `@MockitoBean` goes on test class fields, not in `@Configuration` classes.
+- Every distinct set of mocks creates a new application context. Keep mock sets consistent across test classes so the context cache is reused.
+
+## Example: controller slice
+
+```java
+@WebMvcTest(OrderController.class)
+@Import(SecurityConfig.class)
+class OrderControllerTest {
+    @Autowired MockMvc mvc;
+    @MockitoBean OrderService orders;
+    @MockitoBean JwtDecoder jwtDecoder;
+
+    @Test
+    void returns404ProblemWhenMissing() throws Exception {
+        when(orders.find(42L)).thenThrow(new OrderNotFoundException(42L));
+        mvc.perform(get("/orders/42").with(jwt()))
+           .andExpect(status().isNotFound())
+           .andExpect(jsonPath("$.status").value(404));
+    }
+
+    @Test
+    void rejectsAnonymous() throws Exception {
+        mvc.perform(get("/orders/42")).andExpect(status().isUnauthorized());
+    }
+}
+```
+
+`jwt()` comes from `spring-security-test` (`SecurityMockMvcRequestPostProcessors`).
+
+## Example: Testcontainers with service connections
+
+```java
+@TestConfiguration(proxyBeanMethods = false)
+class TestcontainersConfig {
+    @Bean @ServiceConnection
+    PostgreSQLContainer<?> postgres() { return new PostgreSQLContainer<>("postgres:16-alpine"); }
+}
+```
+
+Import it with `@Import(TestcontainersConfig.class)` in `@SpringBootTest` classes, or in `@DataJpaTest` classes together with `@AutoConfigureTestDatabase(replace = Replace.NONE)`. `@ServiceConnection` (Boot 3.1+) sets the datasource URL and credentials, so no `@DynamicPropertySource` is needed.
+
+## Boot 4 differences
+
+From the Spring Boot 4.0 migration guide:
+
+- Test support is split per technology. Add the matching test starter, for example `spring-boot-starter-webmvc-test` or `spring-boot-starter-data-jpa-test`; these bring in `spring-boot-starter-test`. Slice annotations move to the matching `spring-boot-<technology>-test` module, so imports change.
+- `@SpringBootTest` no longer configures MockMvc on its own. Add `@AutoConfigureMockMvc`.
+- `TestRestTemplate` needs `@AutoConfigureTestRestTemplate`; the newer `RestTestClient` uses `@AutoConfigureRestTestClient`.
+- Jackson 3 is the default (`tools.jackson` packages; `@JsonComponent` becomes `@JacksonComponent`). The auto-configured mapper is a `JsonMapper`; to replace it, define a `JsonMapper` bean, because a plain `ObjectMapper` bean no longer makes it back off.
+
+When upgrading, follow the official migration guide rather than this summary.

package/skills/stripe-integration/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: stripe-integration
+description: Builds and hardens Stripe payments and billing, from Checkout Sessions and Payment Intents with SCA and 3D Secure handling to Stripe-Signature webhook verification on the unparsed request body, Idempotency-Key headers on every POST, subscriptions driven by invoice events, the Billing customer portal, and test clocks for simulating renewals and trial ends. Use when adding Stripe Checkout or Elements, setting up Stripe subscriptions or the customer portal, fixing a Stripe webhook signature error or duplicate fulfilment, or testing billing cycles with the Stripe CLI.
+license: MIT
+compatibility: Any Agent Skills host. Live calls need network access to api.stripe.com; local webhook testing uses the Stripe CLI. Examples are TypeScript with the official stripe-node library; the rules apply to any Stripe SDK.
+metadata:
+  kete-loom/version: "0.1.0"
+  kete-loom/category: integrations
+  kete-loom/risk: network
+  kete-loom/requires: "stripe"
+  kete-loom/owner: "Kete-org"
+---
+
+# Stripe integration
+
+Build a Stripe flow where the price comes from the server, a webhook is trusted only after its signature checks out, retries never create a second charge, and subscription access follows what Stripe says, not what the browser says.
+
+## Ground rules
+
+1. **Secret key on the server only.** `STRIPE_SECRET_KEY` (`sk_...`, or a restricted `rk_...` key with only the permissions the service needs) and the webhook secret (`whsec_...`) come from the environment. Only the publishable key (`pk_...`) reaches the browser.
+2. **Prices come from Stripe or your database.** Pass a `price` ID or compute `amount` server-side. Never accept an amount, currency or price ID from the client without checking it against an allow-list.
+3. **Amounts are integers in the smallest unit** (cents for USD, pence for GBP; zero-decimal currencies such as JPY are whole units). No float maths.
+4. **Fulfil from webhooks.** `checkout.session.completed` (plus `checkout.session.async_payment_succeeded` for delayed methods) or `payment_intent.succeeded`. The success page only shows status; it may never load.
+5. **Verify every webhook** with the SDK on the **raw request bytes**, the `Stripe-Signature` header and that endpoint's `whsec_` secret. Keep the default 5-minute tolerance; never set it to 0.
+6. **Idempotent both ways.** Send an `Idempotency-Key` (a UUID v4 stored with your order) on every create/update POST so a network retry can't double-charge. Record processed `event.id`s and guard fulfilment with `UPDATE ... WHERE status = 'pending'`, because Stripe delivers events at least once and out of order.
+7. **Test mode or a sandbox first**, with the Stripe CLI forwarding events, before any live key is configured.
+
+## Choose the flow
+
+| Need | Use |
+|---|---|
+| One-off or subscription payment, least code, SCA handled for you | Checkout Session (`mode: 'payment'` or `'subscription'`), hosted or embedded |
+| Your own payment form | Payment Intent + Payment Element; confirm on the client with `stripe.confirmPayment` |
+| Save a card for later charges | `setup_future_usage: 'off_session'` on the Payment Intent, or a Setup Intent |
+| Let customers manage plans, cards and invoices | Billing customer portal session |
+
+## Implementation steps
+
+1. **Create a Checkout Session** on the server with `line_items: [{ price, quantity }]`, `mode`, `success_url` (include `{CHECKOUT_SESSION_ID}`), `cancel_url`, `client_reference_id` or `metadata.order_id`, and an idempotency key. Redirect to `session.url`. Shapes in `references/api.md`.
+2. **Or create a Payment Intent** with `amount`, `currency`, `automatic_payment_methods: { enabled: true }`, `metadata.order_id`; send only `client_secret` to the browser.
+3. **Webhook endpoint**: follow `references/webhooks.md`. Mount it before any JSON body parser, verify with `stripe.webhooks.constructEvent`, return `2xx` fast, process in a queue.
+4. **Handle SCA**: a Payment Intent in `requires_action` needs the customer to authenticate; the client SDK does this when confirming. For off-session charges (renewals, saved cards) handle `authentication_required` by emailing the customer a link back on-session. Never mark paid on `processing`.
+5. **Subscriptions**: create through Checkout with `mode: 'subscription'`, store `customer` and `subscription` IDs, and drive access from events: `invoice.paid` (extend access; from API `2025-03-31.basil` the period end is on `items.data[].current_period_end`), `invoice.payment_failed` (dunning, keep or restrict per policy), `customer.subscription.updated` / `.deleted` (plan changes, cancellation). Details in `references/billing.md`.
+6. **Customer portal**: configure it in the Dashboard, then create `billingPortal.sessions.create({ customer, return_url })` from an authenticated route and redirect. Never create a portal session for a customer ID taken from the request; look it up from the logged-in user.
+7. **Test clocks** for billing: create a clock, attach a new customer to it, subscribe, then advance time to see trials end, renewals and failed payments fire their webhooks (`references/billing.md`).
+8. **Persist**: order/payment row with expected amount and currency, Checkout Session or Payment Intent ID, idempotency key, status; a `stripe_events` table of processed event IDs; customer and subscription IDs per user.
+
+## Reviewing an existing integration
+
+Check each ground rule, then look for:
+
+- Webhook route behind `express.json()` / framework body parsing, so `constructEvent` fails or was "fixed" by skipping verification.
+- One `whsec_` reused across endpoints or between test and live (each endpoint and mode has its own).
+- Fulfilment in the success page handler, or on `payment_intent.created` / `processing`.
+- Event order assumed (`invoice.paid` before `customer.subscription.created`); missing objects not fetched from the API.
+- No idempotency key on PaymentIntent, refund or subscription creation; or a new key generated on each retry, which defeats it.
+- Subscription access granted from `checkout.session.completed` alone and never revoked on `customer.subscription.deleted`.
+- Prices or amounts sent from the client; `price` IDs hard-coded from test mode in live config.
+- Secret key in front-end code or a `NEXT_PUBLIC_`/`VITE_` variable.
+
+## Stop and ask the user
+
+- Before switching any configuration to live keys.
+- Whether to keep or cut access on a failed renewal (business decision), and what the dunning and retry settings should be.
+- Before building Connect (marketplaces, payouts to others); it is a different model with onboarding and liability decisions.
+
+## Before you finish
+
+Stripe's docs at docs.stripe.com and the API version pinned on your account are the final word on field names; this skill gives the rules and the shape. Test with `stripe listen --forward-to localhost:4242/webhook` and `stripe trigger`: card `4242 4242 4242 4242` succeeds, `4000 0025 0000 3155` requires 3D Secure, `4000 0000 0000 9995` declines for insufficient funds. Also test a replayed event (processed once), a bad signature (rejected with 400), a retried create call with the same idempotency key (one object), and a test-clock renewal that fails.

package/skills/stripe-integration/evals/triggers.json

@@ -0,0 +1,16 @@
+{
+  "should_trigger": [
+    "Integrate Stripe subscriptions into the billing page",
+    "Stripe webhook keeps failing with No signatures found matching the expected signature",
+    "Add a Stripe customer portal so users can cancel or change their plan",
+    "How do I use Stripe test clocks to check what happens when a trial ends?",
+    "Handle 3D Secure when charging a saved card off-session with Payment Intents"
+  ],
+  "should_not_trigger": [
+    "Add Flutterwave checkout to our Nigerian e-commerce site",
+    "Add Paystack checkout to our Next.js shop so Ghanaian customers can pay",
+    "Review the payment module for secret keys leaked into front-end code",
+    "Work out which parts of our card checkout fall inside PCI DSS scope",
+    "Design the REST API for our invoicing service"
+  ]
+}

package/skills/stripe-integration/references/api.md

@@ -0,0 +1,71 @@
+# Stripe API shapes used by this skill
+
+Use the official SDK for your language and pin the API version your account uses. Every create/update call takes an idempotency key in the request options (`Idempotency-Key` header over HTTP).
+
+Idempotency facts (API v1): keys up to 255 characters, UUID v4 recommended, don't put personal data in them. Stripe saves the first response for a key (including a `500`) and returns it on retries; reusing a key with different parameters is an error; keys can be pruned after 24 hours. Don't send keys on `GET` or `DELETE`.
+
+## Checkout Session (TypeScript, stripe-node)
+
+```ts
+import Stripe from 'stripe';
+const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
+
+export async function startCheckout(order: { id: string; priceId: string; quantity: number; idemKey: string }) {
+  const session = await stripe.checkout.sessions.create(
+    {
+      mode: 'payment',
+      line_items: [{ price: order.priceId, quantity: order.quantity }], // priceId from your DB, not the client
+      success_url: 'https://app.example.com/checkout/success?session_id={CHECKOUT_SESSION_ID}',
+      cancel_url: 'https://app.example.com/cart',
+      client_reference_id: order.id,
+      metadata: { order_id: order.id },
+    },
+    { idempotencyKey: order.idemKey }, // stored with the order, reused on retry
+  );
+  return session.url!;
+}
+```
+
+The success page may call `stripe.checkout.sessions.retrieve(session_id)` to show status, but fulfilment stays in the webhook. Check `session.payment_status === 'paid'` (or `'no_payment_required'`) before fulfilling; for delayed methods it is `'unpaid'` at completion and you wait for `checkout.session.async_payment_succeeded`.
+
+## Payment Intent
+
+```ts
+const pi = await stripe.paymentIntents.create(
+  { amount: 2550, currency: 'usd', automatic_payment_methods: { enabled: true }, metadata: { order_id: order.id } },
+  { idempotencyKey: order.idemKey },
+);
+// send pi.client_secret to the browser; confirm there with stripe.confirmPayment({ elements, confirmParams: { return_url } })
+```
+
+Statuses: `requires_payment_method` → `requires_confirmation` → `requires_action` (SCA / 3DS) → `processing` → `succeeded`, or `canceled`. Only `succeeded` (seen in `payment_intent.succeeded`) means paid. On `payment_intent.payment_failed`, read `last_payment_error` and let the customer try another method.
+
+## Off-session charge with a saved method
+
+```ts
+try {
+  await stripe.paymentIntents.create(
+    { amount, currency, customer, payment_method, off_session: true, confirm: true },
+    { idempotencyKey },
+  );
+} catch (err: any) {
+  if (err.code === 'authentication_required') {
+    // SCA needed: email the customer a link to an on-session page that confirms err.raw.payment_intent
+  } else throw err;
+}
+```
+
+## Refund
+
+```ts
+await stripe.refunds.create({ payment_intent: piId, amount: partialMinor }, { idempotencyKey: refundKey });
+```
+
+## Test cards
+
+| Number | Behaviour |
+|---|---|
+| 4242 4242 4242 4242 | Succeeds |
+| 4000 0025 0000 3155 | Requires 3D Secure authentication |
+| 4000 0000 0000 9995 | Declined, insufficient funds |
+| 4000 0000 0000 0002 | Declined, generic |