@insignia-education/api-sdk-js 0.15.71 → 0.15.74

package/.claude/skills/general/handoff/SKILL.md

@@ -1,15 +0,0 @@
----
-name: handoff
-description: Compact the current conversation into a handoff document for another agent to pick up.
-argument-hint: "What will the next session be used for?"
----
-
-Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS - not the current workspace.
-
-Include a "suggested skills" section in the document, which suggests skills that the agent should invoke.
-
-Do not duplicate content already captured in other artifacts (PRDs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.
-
-Redact any sensitive information, such as API keys, passwords, or personally identifiable information.
-
-If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.

package/.claude/skills/general/investigation/SKILL.md

@@ -1,53 +0,0 @@
----
-name: investigation
-description: General method for investigating why an SDK method is failing or behaving unexpectedly before changing code — pin the symptom, check the real `api` endpoint first, map every call site, and find the true cause (SDK bug vs. API drift vs. consumer version skew) before writing a fix. Use for failing integration tests, `front`-reported bugs, and suspected SDK/API drift. Triggers on "investigate", "root cause", "debug", "why is this failing", "drift", "test failing".
----
-
-# Investigation — Root-Cause Method
-
-A reusable method for getting from a symptom to the true cause before writing a fix, adapted for a
-thin SDK that has no runtime of its own — the vast majority of "bugs" here are actually **drift**
-between this SDK and `api`, not logic bugs.
-
-> **Verify against current `api` behavior before asserting — the backend moves.** Do not propose a
-> fix until you've confirmed what the real endpoint does right now, not what it did when the SDK
-> method was written.
-
-## Method
-1. **Pin the symptom.** From a failing integration test, get the exact test name, assertion, and
-   actual vs. expected values. From a `front`-reported bug, get the exact method call (args) and
-   observed vs. expected behavior.
-2. **Locate the code.** Start from the implicated resource file in `src/api/v1/{Resource}.js` →
-   the method in question → `src/api/v1/index.js` for how it's wired up. This repo's code is flat
-   and shallow — there's rarely more than one or two files to trace through.
-3. **Check `api` first, before assuming the SDK is wrong.** Since this SDK has no independent
-   business logic, the most common root cause is that `api`'s route, controller, or response shape
-   changed and the sync rule (`AGENTS.md`) was missed. Find the real endpoint in `api` and compare
-   its current behavior to what the SDK method assumes.
-4. **Map affected call sites.** Grep `front` for every call to the implicated method — a fix that
-   changes params or return shape without checking all callers reintroduces the bug for a
-   different caller. Also check sibling SDK methods for the same pattern (e.g. a shared
-   param-passing helper) in case the drift is systemic, not local to one method.
-5. **Classify the true cause:**
-   - **SDK bug** — the method never matched `api` correctly, and a test/report just caught it.
-   - **API drift** — `api` changed and the SDK sync rule (per `AGENTS.md`) wasn't followed.
-   - **Version skew** — the SDK is already correct, but `front` (or another consumer) is pinned to
-     an older published version. Check the consumer's `package.json` for the installed version
-     against the current one.
-6. **Plan the fix with downstream impact in mind.** State what changes, whether it's `v1`-safe or
-   needs `v2` (per the freeze rule), and how you'll verify — then update/add the integration test
-   that fails before the fix and passes after.
-
-## Evidence sources
-
-- **A failing integration test against a live `api` is the primary and strongest signal** — per
-  `AGENTS.md`, this is the artifact that proves the SDK and `api` agree. Reproduce or run the
-  relevant test in `tests/integration/api/v1/` before proposing a fix.
-- **`api`'s actual response shape** — this repo has no logs, no Telescope, no error tracker of its
-  own. If the SDK's assumption about a response looks wrong, check it via `api`'s own Telescope
-  (`/telescope`, local) or logs (`storage/logs/laravel.log`) in the `api` repo — don't guess from
-  the SDK side alone.
-- **`api`'s route/controller source** — the ground truth for path, params, and response shape.
-  Read it directly rather than inferring from the SDK's existing (possibly stale) assumption.
-- **No third-party error tracker or APM exists in this repo** — don't assume Datadog/Sentry/Bugsnag
-  are wired up here; they aren't.

package/.claude/skills/general/performance/SKILL.md

@@ -1,31 +0,0 @@
----
-name: performance
-description: Minimal performance checklist for this thin HTTP client SDK — there is very little performance surface here (no rendering, no queries, no server). Use when a consumer reports a resource method being called redundantly or a method doing unnecessary work per call. Triggers on "performance", "slow", "redundant calls", "optimize", "duplicate requests".
----
-
-# Performance — Minimal Checklist
-
-This is a thin, zero-dependency HTTP wrapper. It has no database, no rendering, no compute-heavy
-work, and no server process — most of the performance surface that a full application has simply
-doesn't exist here. Don't manufacture a heavier profiling process than the codebase warrants; this
-skill is intentionally short.
-
-The two things actually worth checking:
-
-1. **Redundant/duplicate calls from a consumer using a method in a loop.** A resource method is a
-   1:1 wrapper around one `api` call — if `front` (or another consumer) calls the same method
-   repeatedly inside a loop with the same or overlapping args, that's a consumer-side batching
-   problem, not something to fix inside the SDK method itself. Flag it to the consumer rather than
-   adding caching/batching logic into a resource class (that would violate thin-wrapper discipline
-   — see `AGENTS.md` and the `senior-software-developer`/`senior-code-reviewer` agents).
-2. **Unnecessary payload transformation or cloning per call.** A resource method should pass
-   params/body through to the client with the minimum work needed to shape the HTTP request — no
-   deep-cloning, no reshaping the response, no redundant `JSON.parse(JSON.stringify(...))`-style
-   copies. If a method is doing more than constructing the call and returning the client's
-   response, that's very likely a correctness/scope issue (see `general/investigation` and the
-   thin-wrapper rule), not just a performance one.
-
-If a real latency problem is reported, it is almost certainly in `api` (query performance, N+1,
-slow external integration) or in network conditions — not in this SDK. Point the investigation at
-`api`'s own performance tooling (see its `AGENTS.md`/performance skill) rather than profiling this
-repo.

package/.claude/skills/git/pull-request/SKILL.md

@@ -1,47 +0,0 @@
----
-name: create-pull-request-api-sdk-js
-description: Create a pull request following insignia-education conventions for this repo — no Jira link, no PR template, but a repo-specific pre-flight checklist (endpoint exists in api, integration test present, v1-freeze respected, publish-pipeline awareness). Use whenever creating a PR in `api-sdk-js`.
----
-
-# Create Pull Request — insignia-education/api-sdk-js
-
-No `.github/PULL_REQUEST_TEMPLATE.md` exists in this repo — write a plain body with `## Summary`
-and `## Test plan` sections (see the repo-level PR instructions for the exact mechanics of
-`gh pr create`). This skill adds the checks specific to this repo, on top of that.
-
-## Pre-flight checklist
-
-- **The `api` endpoint is real and already merged/available.** Never add a speculative SDK method
-  for an endpoint that doesn't exist yet in `api` — confirm the route/controller is merged (and,
-  ideally, deployed somewhere reachable) before opening this PR. Per `AGENTS.md`'s sync rule, this
-  SDK follows `api`; it never leads it.
-- **An integration test was added or updated.** Per `AGENTS.md`, a new/changed method isn't
-  verified until its test in `tests/integration/api/v1/` passes against a locally running `api`.
-  A PR that changes a resource method without a corresponding test change is incomplete — call it
-  out explicitly if deferring this is unavoidable.
-- **Test coverage includes missing/malformed params and permissions per role**, not just the happy
-  path — per `AGENTS.md`'s testing coverage requirements.
-- **`v1` freeze respected.** If the diff touches `src/api/v1/`, confirm it's additive (new
-  method/resource) and not a breaking change to an existing method's signature or return shape, and
-  that `InsigniaApiV1`'s constructor is unchanged. A breaking change belongs under a future
-  `src/api/v2/`, not a `v1` edit.
-- **No runtime dependency added**, no hardcoded base URL, no hardcoded human-readable string in
-  source (errors must expose `status`/`data` only — see `AGENTS.md`'s i18n rule).
-- **Merging this PR to `master` is a deploy action, not a routine merge.** Per `CLAUDE.md`'s
-  deployment section, a push to `master` (unless `[skip ci]`) auto-bumps this package's patch
-  version, publishes it to npm, pushes a direct commit to `front`'s `beta` branch, and opens a PR
-  against `front`'s `master` — all without further human action beyond the merge itself. Don't
-  merge here as though it's a no-op; know that it triggers all of the above.
-
-## Body format
-
-```
-## Summary
-<1-3 bullets>
-
-## Test plan
-<checklist of what was tested / how to verify>
-```
-
-Omit sections that would be empty. No ticket link, no deployment labels — this repo doesn't use
-them.

package/.claude/skills/how-to-create-skills/SKILL.md

@@ -1,82 +0,0 @@
----
-name: how-to-create-skills
-description: How to author and organize skills in this repo's `.claude/skills/` — the domain/general taxonomy, the composability principle (split knowledge from method), SKILL.md frontmatter, naming, and when to split vs combine a skill. Use whenever creating a new skill, editing an existing one, splitting a monolithic skill, or deciding where a skill belongs. Triggers on "create a skill", "new skill", "add a skill", "organize skills", "skill structure".
----
-
-# How to Create Skills
-
-This is the meta-skill. It defines the conventions every other skill in `.claude/skills/` follows. **This skill is intentionally exempt from those conventions** — it lives at the top level with no domain, because it describes the system rather than participating in it.
-
-## The one principle: split *knowledge* from *method*, then compose
-
-A skill is either:
-- **Domain knowledge** — *what exists and where it lives* (a map): resource/versioning structure, file paths, conventions, entry points. No domain-map skill exists here yet — the closest thing today is `AGENTS.md` plus `.ai/guidelines/research-order.md`.
-- **A general process** — *how to do something*, independent of domain (a method): investigating drift, documenting, opening a PR. Example: `investigation`, `general/documentation`.
-
-Never fuse the two. If a domain-map skill is added later (e.g. `v2` once the next API version gets its own resource modules), there should not be a `v2-investigation` skill — there should be `v2` (the map) and `investigation` (the method), composed together. The cross-product emerges from composition, not from a bespoke combined skill.
-
-**Why:** the method is reusable across every version/resource, and the map is reusable across every process. Fusing them forces you to re-teach the investigation method for each version and re-map the resources for each activity.
-
-### How composition works in practice
-- A general process skill says: *"pair me with the relevant domain skill for the map."*
-- A domain skill says: *"for investigating drift, also load `investigation`; for a new method, also load `general/documentation`."*
-- Cross-reference by skill `name` in prose so the reader knows what to load alongside.
-
-## Folder taxonomy: domain → sub-domain → process → skill-name
-
-Organize the path from most-specific domain down to the leaf. Cross-cutting process skills that belong to no single domain live under `general/`.
-
-```
-.claude/skills/
-├── how-to-create-skills/     ← this meta-skill (exempt from the pattern)
-├── <domain>/                 ← domain knowledge (git, v2, …)
-│   ├── SKILL.md              ← the domain map itself (optional)
-│   └── <sub-domain-or-process>/SKILL.md
-└── general/                  ← domain-agnostic process skills
-    └── <process>/SKILL.md    ← performance, investigation, documentation, handoff, …
-```
-
-Rules:
-- **Domain first.** If a skill is about *one* domain, nest it under that domain (`git/pull-request`).
-- **General bucket.** If a skill's method applies across domains, put it in `general/` (`general/performance`).
-- Any `SKILL.md` anywhere under `.claude/skills/**` is discovered — folders are for humans, the `name` field is the identifier.
-- Prefer the **most general** phrasing a skill can honestly carry. Keep repo-specific specifics (class names, endpoint paths) inside the skill, but frame the transferable method first.
-
-## Deciding: split or combine?
-
-| Signal | Action |
-|---|---|
-| The skill mixes "where the code is" with "how to profile/debug it" | **Split** into a domain skill + a `general/` process skill |
-| Two skills always get loaded together and neither stands alone | Consider **combining** — but first check whether one is really a sub-domain of the other |
-| A process skill keeps accreting domain-specific class/resource names | Move those facts into the **domain** skill; keep the method general |
-| A domain skill starts explaining testing/PR mechanics in depth | Move that into a **general** process skill and cross-reference |
-
-## SKILL.md format
-
-```markdown
----
-name: <kebab-case, unique across all skills>
-description: <what it does + WHEN to use it + trigger phrases. This is the ONLY thing the model sees when deciding to load the skill — make it match how people actually phrase the task. For composables, name the skills to load alongside.>
-argument-hint: "<optional, for slash-invoked skills>"
-disable-model-invocation: true   # optional — manual /invoke only
----
-
-# Title
-
-Body: tables and short imperative steps first, prose last. Cross-reference
-composable skills by name. Note file:line references but tell the reader to
-verify them against current code.
-```
-
-Frontmatter notes:
-- **`name`** must be unique and stable — it's the slash command and the invocation id. Renaming breaks existing references, so rename deliberately.
-- **`description`** is load-bearing: it's matched against the user's request to auto-activate the skill. Lead with capability, then "Use when…", then trigger phrases.
-- **`disable-model-invocation: true`** makes the skill manual-only (`/name …`). Use for router/workflow skills that shouldn't fire automatically.
-
-## Authoring checklist
-1. Is this **knowledge** or **method**? Put it in the right place; don't fuse.
-2. Does an existing skill already cover it? Extend that instead of duplicating.
-3. Can the wording be more general without losing accuracy? Generalize.
-4. Name the composable siblings to load alongside.
-5. Write the `description` the way a user would ask for it.
-6. Keep the body scannable: tables + steps first.

package/.github/hooks/pre-commit

@@ -1,22 +0,0 @@
-#!/bin/bash
-set -e
-
-PACKAGE=$(node -p "require('./package.json').name")
-VERSION=$(node -p "require('./package.json').version")
-
-echo "Running lint..."
-npm run lint
-
-echo "Running tests..."
-npm test
-
-echo "Checking if ${PACKAGE}@${VERSION} is already published..."
-STATUS=$(curl -s -o /dev/null -w "%{http_code}" "https://registry.npmjs.org/${PACKAGE}/${VERSION}")
-echo $STATUS
-if [ "$STATUS" = "200" ]; then
-    echo "Error: ${PACKAGE}@${VERSION} is already published on NPM."
-    echo "Bump the version in package.json before committing."
-    exit 1
-fi
-
-exit 0

package/.github/workflows/npm-publish-github-packages.yml

@@ -1,29 +0,0 @@
-name: Publish Package
-
-on:
-  push:
-    branches:
-      - master
-
-permissions:
-  id-token: write  # Required for OIDC
-
-jobs:
-  publish:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v6
-
-      - uses: actions/setup-node@v6
-        with:
-          node-version: '24'
-          registry-url: 'https://registry.npmjs.org'
-          package-manager-cache: false  # never use caching in release builds
-      - run: npm ci
-      - run: npm run build --if-present
-      # npm test disabled: integration suite needs a live api backend, no CI service for it yet
-
-      # The version in package.json is whatever was committed — this workflow never bumps it.
-      # The pre-commit hook (.github/hooks/pre-commit) already refuses a commit whose version is
-      # already published, so publishing here just fails loudly if someone forgot to bump it.
-      - run: npm publish  # Or: npm stage publish

package/.nvmrc

@@ -1 +0,0 @@
-25

package/AGENTS.md

@@ -1,140 +0,0 @@
-# Insignia Education — API SDK (JavaScript)
-
-## Requirements
-- Node 24 LTS (`nvm use 24`)
-
-## Quick start
-```bash
-nvm use 24
-npm install
-npm test       # runs Jest test suite
-npm run lint   # ESLint
-```
-
-## What this is
-A zero-dependency JavaScript SDK that wraps the Insignia Education API (`/api/v1`).
-Consumed by `insignia-education/front` via `@insignia-education/api-sdk-js`.
-
-## API versioning
-The SDK is versioned to match the API:
-
-- `src/index.js` — base client
-- `src/api/index.js` — appends `/api` to the base URL
-- `src/api/v1/index.js` — appends `/v1` → all requests land at `<host>/api/v1/...`
-- **v1 is being finalized. Once stable it is permanently frozen.**
-- A future v2 API will live in `src/api/v2/index.js` (new class, new resource modules).
-- Never modify the URL construction logic in `v1/` to point at a different version.
-- Tests for each version live in `tests/integration/api/v1/` — mirror this structure for v2+.
-- The `upload(path, formData)` method on `Client` sends multipart — use `api.files.upload(fd)` for any file upload, never raw `fetch()`.
-
-## Structure
-```
-src/
-├── index.js            ← main export
-├── api/v1/
-│   ├── index.js        ← InsigniaApiV1 class (root client)
-│   ├── Auth.js         ← /auth endpoints
-│   ├── Courses.js      ← /courses endpoints
-│   ├── Users.js        ← /users endpoints
-│   └── ...             ← one file per API resource
-```
-
-## Usage pattern
-```js
-import InsigniaApiV1 from '@insignia-education/api-sdk-js/api/v1';
-const api = new InsigniaApiV1('http://localhost:8000');
-
-api.auth.login({ email, password });
-api.courses.get(null, { page: 1 });
-api.users.cashReceivers();
-```
-
-## Conventions
-- One class per API resource
-- Methods match HTTP verbs: `get`, `post`, `put`, `patch`, `delete`
-- No external runtime dependencies — only Node built-ins
-- ESM modules (`"type": "module"`)
-
-## Adding a new resource
-1. Create `src/api/v1/ResourceName.js` with a class that receives the client
-2. Register it in `src/api/v1/index.js`
-3. Write integration tests in `tests/integration/api/v1/resource-name.test.js`
-
-Verify a new/changed method by running its integration test against a locally running `api`
-(`npm test`), not by scripting one-off `curl`/fetch calls in a shell. The integration test is the
-artifact that proves the SDK and the API agree, and it's what keeps both repos in sync going
-forward — a curl call proves nothing once the terminal closes.
-
-## Testing coverage requirements
-
-Same pattern as `api`'s endpoint tests (see its `AGENTS.md`), applied per SDK method:
-
-- **Missing/malformed params** — call each method with required params omitted and with wrong-format values; confirm the SDK surfaces the API's validation error correctly rather than swallowing it or throwing something unrelated.
-- **Permissions** — exercise each method as every relevant user role (including unauthenticated) against the API and confirm the SDK surfaces 401/403 correctly — not just the happy-path success response for the one role the method was built for.
-
-## Internationalisation (i18n)
-The SDK is language-neutral — it must never contain human-readable strings.
-
-- Do not include hardcoded error messages or labels in SDK source.
-- Error objects thrown by the SDK must expose a machine-readable `status` (HTTP code) and `data` (raw API body). The consuming app handles translation.
-- Do not add locale/language logic to the SDK — that belongs to the frontend.
-
-## API ↔ SDK sync rule
-
-**This SDK must stay in sync with [`insignia-education/api`](../api) at all times.** Any endpoint added, renamed, or removed in the API must be reflected here in the same task/commit.
-
-- New endpoint in `api` → new method in the correct `src/api/v1/*.js` class
-- Removed endpoint → remove or deprecate the corresponding SDK method
-- Never leave the SDK behind the API; the `front` repo relies solely on this SDK
-
-## Consumption — never symlink
-
-Consumers (`front`, `api`) must install this package the normal npm way — **never** via a symlink
-(`npm link`, a manual `ln -s` into a consumer's `node_modules`, etc.), even for local iteration.
-
-- A symlinked package looks like it works, but an `npm install`/`npm ci` in the consumer repo can
-  silently replace the link with a stale registry copy — the consumer keeps running old SDK code
-  with no error, and edits stop propagating until someone notices at runtime.
-- Instead: bump this package's version (`npm version patch|minor` — the pre-commit hook rejects a
-  commit whose version is already published, so this can't be skipped) and commit it. CI
-  (`.github/workflows/npm-publish-github-packages.yml`) publishes automatically on push to
-  master — it does **not** bump the version itself, and it does **not** touch any consumer repo,
-  so pin the exact new version (no `^`/`~`) in the consumer's `package.json` and run
-  `npm install` there yourself.
-- Never publish on your own initiative — pushing the version-bump commit to master is what
-  triggers it; don't run `npm publish` by hand.
-
-## Never do
-- Don't add runtime dependencies
-- Don't change the constructor signature of `InsigniaApiV1`
-- Don't hardcode API base URLs — always receive from constructor
-- Don't let the SDK lag behind `api` — update both in the same task
-- Don't symlink this package into a consumer's `node_modules` — publish it instead
-
-
----
-
-## Working Style
-
-- **Think before coding.** State your assumptions out loud. If the request is ambiguous, ask. If a simpler approach exists, push back. Stop when confused — name what is unclear; do not pick one interpretation and run.
-- **Simplicity first.** Write the minimum code that solves the problem. No speculative abstractions. No flexibility nobody asked for. The test: would a senior engineer call this overcomplicated?
-- **Surgical changes.** Touch only what the task requires. Do not improve neighboring code. Do not refactor what is not broken. Every changed line must trace back to the request.
-- **Goal-driven execution.** Turn vague instructions into verifiable targets before writing a line. "Add validation" becomes "write tests for invalid inputs, then make them pass."
-## Git
-
-- **NEVER commit in the agent's or Claude's name.** All commits must be authored solely by the human developer. Do not add `Co-Authored-By` trailers that name Claude or any AI agent — in shared/collaborative repositories this would falsely attribute work and obscure accountability.
-
-
-## Communication style
-- Respond as briefly as possible. Caveman mode: shortest answer that works. No fluff, no summaries, no "here is what I did".
-
----
-
-## Git safety (CRITICAL — read every session)
-
-**DO NOT MESS WITH GIT.** DO NOT run `git checkout`, `git stash`, `git reset`, `git restore`,
-`git clean`, or any command that discards or overwrites working-tree changes. These repos often
-carry large amounts of **uncommitted** work, and these commands will destroy it irreversibly.
-
-If you need to change the current branch: **commit the work first, or ask the user to commit.**
-Never revert, discard, or overwrite changes via git without explicit permission from the user.

package/CLAUDE.md

@@ -1,51 +0,0 @@
-# CLAUDE.md
-
-This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
-
-> **Status: Active — the sole client for `insignia-education/api`.**
-> A thin, zero-runtime-dependency JavaScript SDK wrapping the Laravel 12 backend
-> [`insignia-education/api`](../api). Its only consumer is
-> [`insignia-education/front`](../front) (React 19 + Vite 8 SPA) — `front` never calls `api`
-> directly. `v1` is being finalized and will be permanently frozen once stable; a future `v2`
-> is added alongside `v1`, never in place of it.
-
----
-
-> The canonical agent-readable version of these instructions is **`AGENTS.md`** (same directory). Both
-> files are kept in sync; CLAUDE.md adds Claude Code–specific detail where needed. Read `AGENTS.md` first
-> for versioning rules, structure, conventions, testing coverage requirements, the i18n rule, the
-> API↔SDK sync rule, and the "Never do" list — none of that is repeated here.
-
----
-
-## Related repos
-
-| Repo | Role |
-|---|---|
-| [`api`](../api) | Laravel backend this SDK wraps. Any endpoint added, renamed, or removed there must be mirrored here in the same task — see `AGENTS.md`'s sync rule. |
-| [`front`](../front) | The sole consumer. Talks to `api` exclusively through this package — a method missing here is a method `front` cannot use. |
-
-This SDK has no independent purpose — it only exists to mirror `api`. When in doubt about what a
-method should do, the answer is "whatever the matching `api` endpoint does," not a judgment call
-made here.
-
-## Deployment / publish (GitHub Actions — read this before touching `master`)
-
-`.github/workflows/npm-publish-github-packages.yml` runs on every push to `master`. It is **not**
-a manual `npm publish` a human runs by hand — merging a PR to `master` is the trigger, and that
-merge is a human action, so the "never publish on your own initiative" rule in `AGENTS.md` still
-applies to *merging to master*, not just to running `npm publish` directly.
-
-What the workflow actually does: installs, builds, then `npm publish`. That's it — it does **not**
-bump the version (the pre-commit hook already forces that before the commit even lands), and it
-does **not** touch `front` or any other consumer repo.
-
-**Practical implications:**
-- The version published is exactly whatever `package.json` says at the commit that landed on
-  `master`. If that version is already on npm (e.g. someone forgot to bump it), the publish step
-  fails loudly — there's no silent overwrite or skip.
-- Nothing else updates automatically: after a merge here, a human still has to pin the exact new
-  version (no `^`/`~`) in `front/package.json` and run `npm install` there — see this repo's
-  `AGENTS.md` and `front/AGENTS.md`'s API ↔ SDK sync rule.
-- Publishes via npm's OIDC trusted publishing (`permissions: id-token: write`) — no `NPM_TOKEN` or
-  other secret, and no cross-repo permissions, are needed anymore.

package/babel.config.cjs

@@ -1 +0,0 @@
-module.exports = {presets: [['@babel/preset-env', {targets: {node: 'current'}}]]}

package/eslint.config.mjs

@@ -1,29 +0,0 @@
-import js from "@eslint/js";
-import globals from "globals";
-
-export default [
-    js.configs.recommended,
-    {
-        files: ["src/**/*.js"],
-        languageOptions: {
-            globals: {
-                ...globals.node,
-                fetch: "readonly",
-            },
-        },
-        rules: {
-            "no-unused-vars": "warn",
-            "no-console": "warn",
-        },
-    },
-    {
-        files: ["tests/**/*.js"],
-        languageOptions: {
-            globals: {
-                ...globals.node,
-                ...globals.jest,
-                fetch: "readonly",
-            },
-        },
-    },
-];

package/jest.config.mjs

@@ -1,47 +0,0 @@
-/** @type {import('jest').Config} */
-const config = {
-    collectCoverage: true,
-    coverageDirectory: 'coverage',
-    coverageProvider: 'v8',
-
-    reporters: [
-        'default',
-        ['jest-html-reporter', {
-            outputPath: 'coverage/test-report.html',
-            pageTitle: 'API SDK Test Report',
-            includeFailureMsg: true,
-            includeConsoleLog: true,
-        }],
-    ],
-
-    // Run via `npm test`, which invokes unit and integration as two separate
-    // `jest --selectProjects` calls (integration also with --runInBand)
-    // rather than one combined parallel run: Jest has a multi-project quirk
-    // where a later project's tests can silently fall back to the global
-    // 5000ms default instead of this project's own testTimeout when both
-    // projects run together in one process, and integration tests hit a
-    // single-threaded `php artisan serve` backend that serializes requests
-    // anyway — parallel workers just queue up and time out against it.
-    projects: [
-        {
-            displayName: 'unit',
-            testMatch: [
-                '<rootDir>/tests/client.test.js',
-                '<rootDir>/tests/api/**/*.test.js',
-            ],
-            transform: { '^.+\\.(js|jsx)$': 'babel-jest' },
-        },
-        {
-            displayName: 'integration',
-            testMatch: ['<rootDir>/tests/integration/**/*.test.js'],
-            transform: { '^.+\\.(js|jsx)$': 'babel-jest' },
-            setupFiles: ['<rootDir>/tests/integration/loadEnv.js'],
-            // Generous — amd64 emulation (api-sdk-js's Docker test env on
-            // Apple Silicon) occasionally makes an individual request take
-            // 10-20s+ under CPU contention.
-            testTimeout: 60000,
-        },
-    ],
-};
-
-export default config;

package/scss/index.scss

@@ -1,2 +0,0 @@
-@import '../../node_modules/bootstrap/scss/bootstrap';
-@import 'buttons/buttons';