@enfocussw/switch-scripting-context 25.11.0-beta.13 → 25.11.0-beta.14

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -5,6 +5,24 @@ All notable changes to this package are documented here. Format follows
5
5
 
6
6
  ## [Unreleased]
7
7
 
8
+ ## [25.11.0-beta.14] - 2026-09-09
9
+
10
+ ### Added
11
+ - `switch-scripting.md` now tells agents to grep `docs/switch-api/` for `known issue`, `gotcha`,
12
+ `quirk`, `caveat` to find documented pitfalls before writing code in an area.
13
+ - `api-entry-points.md` documents that a flow restart replays every queued job through `jobArrived`
14
+ again, even one whose processing was deferred to `timerFired`. A script relying on that pattern
15
+ must recognize an already-registered job and return quickly, or a large backlog is slow to clear.
16
+ - `api-project-planning.md`, a pre-scaffolding checklist for new scripts and apps: Script vs App,
17
+ job-processing approach, target OS, Switch version baseline, concurrency, native/binary npm
18
+ dependency feasibility, and Appstore competition risk. Loaded before any files are scaffolded.
19
+
20
+ ### Changed
21
+ - `README.md` no longer uses dashes as punctuation. Wording is unchanged otherwise.
22
+ - The published README now links to the changelog on jsdelivr, pinned to the version being
23
+ installed. Relative links were rewritten by npm to the private repo, so they were dead for
24
+ consumers. `prepack` swaps them in and `postpack` swaps them back.
25
+
8
26
  ## [25.11.0-beta.13] - 2026-09-09
9
27
 
10
28
  ### Fixed
package/README.md CHANGED
@@ -4,7 +4,7 @@ AI coding assistant context for [Enfocus Switch](https://www.enfocus.com/en/swit
4
4
 
5
5
  Installs curated API reference docs and generates config files for 8 AI coding agents (Claude Code, GitHub Copilot, Cursor, Codex CLI/OpenCode, Gemini CLI, Windsurf, Zed, and Cline) so AI assistants understand the Switch scripting API out of the box.
6
6
 
7
- See [CHANGELOG.md](CHANGELOG.md) (also included in this package) for what's changed between versions.
7
+ See [CHANGELOG.md](https://cdn.jsdelivr.net/npm/@enfocussw/switch-scripting-context@25.11.0-beta.14/CHANGELOG.md) (also included in this package) for what's changed between versions.
8
8
 
9
9
  ## Usage
10
10
 
@@ -34,13 +34,13 @@ The package version tracks the Switch release its docs describe:
34
34
  └────── Switch version (25.11)
35
35
  ```
36
36
 
37
- - `25.11.x` every release of this package documenting **Switch 25.11**. Patch increments are doc updates, fixes, and new features of the CLI itself.
37
+ - `25.11.x`: every release of this package documenting **Switch 25.11**. Patch increments are doc updates, fixes, and new features of the CLI itself.
38
38
  - The next Switch release moves the first two numbers (e.g. Switch 27.07 → `27.7.0`). Note that semver forbids leading zeros, so `27.07` is published as `27.7`.
39
39
  - **Pin with `~`, not `^`.** `~25.11.0` stays on Switch 25.11; `^25.11.0` would happily install `25.12.0`, which targets a different Switch release.
40
40
 
41
41
  ### Prereleases
42
42
 
43
- Beta builds append a prerelease suffix `25.11.0-beta.1`. These sort *below* `25.11.0`,
43
+ Beta builds append a prerelease suffix, for example `25.11.0-beta.1`. These sort *below* `25.11.0`,
44
44
  so the beta line precedes GA and leaves `25.11.0` free for the first published release.
45
45
 
46
46
  ## What it does
@@ -53,9 +53,9 @@ so the beta line precedes GA and leaves `25.11.0` free for the first published r
53
53
 
54
54
  | Tool | File | How context is loaded |
55
55
  |---|---|---|
56
- | Claude Code / ClawCode | `CLAUDE.md` | `@switch-docs/switch-scripting.md` import hub file routes to specific API docs on demand |
56
+ | Claude Code / ClawCode | `CLAUDE.md` | `@switch-docs/switch-scripting.md` import; hub file routes to specific API docs on demand |
57
57
  | GitHub Copilot | `.github/copilot-instructions.md` | `#file:` reference to hub |
58
- | GitHub Copilot (scoped) | `.github/instructions/switch-scripting.instructions.md` | `applyTo: "**/*.ts"` auto-attaches to every TypeScript file edit |
58
+ | GitHub Copilot (scoped) | `.github/instructions/switch-scripting.instructions.md` | `applyTo: "**/*.ts"`; auto-attaches to every TypeScript file edit |
59
59
  | Cursor | `.cursor/rules/switch-scripting.mdc` | Inline key rules + full API file path list |
60
60
  | Codex CLI / OpenCode | `AGENTS.md` | Inline key rules + full API file path list |
61
61
  | Gemini CLI | `GEMINI.md` | `@switch-docs/switch-scripting.md` import |
@@ -63,28 +63,28 @@ so the beta line precedes GA and leaves `25.11.0` free for the first published r
63
63
  | Zed | `.rules` | Inline key rules + full API file path list |
64
64
  | Cline | `.clinerules` | Inline key rules + full API file path list |
65
65
 
66
- All files use `<!-- switch-scripting-context begin -->` / `<!-- switch-scripting-context end -->` markers. Re-running `init` replaces only the Switch section in existing files — project-specific rules outside the markers are untouched.
66
+ All files use `<!-- switch-scripting-context begin -->` / `<!-- switch-scripting-context end -->` markers. Re-running `init` replaces only the Switch section in existing files. Project-specific rules outside the markers are untouched.
67
67
 
68
68
  ## Using this with your coding agent
69
69
 
70
- Once `init` has run, just work normally describe what you want in plain terms and prompt as you
70
+ Once `init` has run, just work normally. Describe what you want in plain terms and prompt as you
71
71
  usually would. Your agent picks up the Switch context automatically (via `@import` for Claude
72
72
  Code/Gemini, or the inlined rules + file list for the others) whenever it's working in the project,
73
73
  and pulls in the specific API doc it needs for the task at hand on its own. You don't need to know
74
74
  the doc file names or tell it which one to read.
75
75
 
76
76
  A few things this gets you without asking for them by name:
77
- - Scaffolding a new entry point, handling a webhook, or reading/creating datasets and jobs — the
77
+ - Scaffolding a new entry point, handling a webhook, or reading/creating datasets and jobs. The
78
78
  agent consults the matching API reference before writing the code.
79
- - Diagnosing why a script isn't behaving as expected the agent knows it can locate and query
79
+ - Diagnosing why a script isn't behaving as expected. The agent knows it can locate and query
80
80
  Switch's own log database (`ServerLogs.db3`) rather than only re-reasoning about the code.
81
- - Creating, packing, or deploying a script the agent uses `SwitchScriptTool` with the documented
82
- flags and behavior, rather than hand-rolling the steps.
83
- - Editing the script's XML declaration the agent follows the documented rules and knows which
84
- properties (app path/license) are off-limits and left to SwitchScripter's GUI instead.
81
+ - Creating, packing, or deploying a script. The agent uses `SwitchScriptTool` with the documented
82
+ flags and behaviour, rather than hand-rolling the steps.
83
+ - Editing the script's XML declaration. The agent follows the documented rules and knows which
84
+ properties (app path/licence) are off-limits and left to SwitchScripter's GUI instead.
85
85
 
86
- Re-run `init` after upgrading this package so the copied docs and generated config files catch up
87
- see [CHANGELOG.md](CHANGELOG.md) for what changed.
86
+ Re-run `init` after upgrading this package so the copied docs and generated config files catch up.
87
+ See [CHANGELOG.md](https://cdn.jsdelivr.net/npm/@enfocussw/switch-scripting-context@25.11.0-beta.14/CHANGELOG.md) for what changed.
88
88
 
89
89
  ## Options
90
90
 
@@ -130,23 +130,24 @@ npm install --save-dev "https://github.com/enfocus-switch/types-switch-scripting
130
130
 
131
131
  The `switch-docs/` folder contains:
132
132
 
133
- - `switch-scripting.md` master index with execution environment rules and "load when" routing table
134
- - `switch-api/api-entry-points.md` all entry point signatures and when each is called
135
- - `switch-api/api-job.md` `Job` class signatures: routing, file access, child jobs, private data, datasets
136
- - `switch-api/api-flow-element.md` `FlowElement`: properties, connections, job creation, logging
137
- - `switch-api/api-switch.md` `Switch` global: global data, webhooks, abort, server utilities
138
- - `switch-api/api-connection.md` `Connection`: type, properties, file count
139
- - `switch-api/api-http.md` `HttpRequest` / `HttpResponse` and webhook pattern
140
- - `switch-api/api-enums.md` all enums with string values (`LogLevel`, `AccessLevel`, `Scope`, etc.)
141
- - `switch-api/api-document-classes.md` `PdfDocument`, `ImageDocument`, `XmlDocument`, `XmpDocument`
142
- - `switch-api/api-script-declaration.md` XML declaration reference
143
- - `switch-api/api-script-structure.md` script folder contents, manifest format, Node.js version per Switch release, Script vs App
144
- - `switch-api/api-tooling.md` SwitchScriptTool commands, script folder vs package, build and deployment
145
- - `switch-api/api-debugging.md` enabling debug mode, debuggable entry points, VS Code attach
146
- - `switch-api/api-logging.md` log levels, when/what to log, `console.log` limitation, common gotchas
147
- - `switch-api/api-logs-and-dataroot.md` locating the application data root, querying `ServerLogs.db3` directly to diagnose a script
148
- - `switch-api/api-vscode.md` type declarations, tsconfig for TypeScript 6, ESLint rules
149
- - `switch-api/api-property-editors.md` property editor types and string return values
150
- - `switch-api/api-job-patterns.md` `Job` rules and gotchas: file access semantics, temp cleanup, routing rules, child jobs, executor limits
151
- - `switch-api/api-execution-environment.md` execution modes, process model, state persistence across jobs, error handling, npm/native module constraints
152
- - `switch-api/api-app-guidelines.md` pre-publish checklist for Appstore apps: property naming/tooltips/editors, entry point and sendTo consistency, logging quality, packaging, app-only submission rules
133
+ - `switch-scripting.md`: master index with execution environment rules and "load when" routing table
134
+ - `switch-api/api-project-planning.md`: pre-scaffolding checklist covering Script vs App, job-processing approach, target OS, Switch version baseline, concurrency, native/binary npm dependencies, Appstore competition risk
135
+ - `switch-api/api-entry-points.md`: all entry point signatures and when each is called
136
+ - `switch-api/api-job.md`: `Job` class signatures for routing, file access, child jobs, private data, datasets
137
+ - `switch-api/api-flow-element.md`: `FlowElement`: properties, connections, job creation, logging
138
+ - `switch-api/api-switch.md`: `Switch` global: global data, webhooks, abort, server utilities
139
+ - `switch-api/api-connection.md`: `Connection`: type, properties, file count
140
+ - `switch-api/api-http.md`: `HttpRequest` / `HttpResponse` and webhook pattern
141
+ - `switch-api/api-enums.md`: all enums with string values (`LogLevel`, `AccessLevel`, `Scope`, etc.)
142
+ - `switch-api/api-document-classes.md`: `PdfDocument`, `ImageDocument`, `XmlDocument`, `XmpDocument`
143
+ - `switch-api/api-script-declaration.md`: XML declaration reference
144
+ - `switch-api/api-script-structure.md`: script folder contents, manifest format, Node.js version per Switch release, Script vs App
145
+ - `switch-api/api-tooling.md`: SwitchScriptTool commands, script folder vs package, build and deployment
146
+ - `switch-api/api-debugging.md`: enabling debug mode, debuggable entry points, VS Code attach
147
+ - `switch-api/api-logging.md`: log levels, when/what to log, `console.log` limitation, common gotchas
148
+ - `switch-api/api-logs-and-dataroot.md`: locating the application data root, querying `ServerLogs.db3` directly to diagnose a script
149
+ - `switch-api/api-vscode.md`: type declarations, tsconfig for TypeScript 6, ESLint rules
150
+ - `switch-api/api-property-editors.md`: property editor types and string return values
151
+ - `switch-api/api-job-patterns.md`: `Job` rules and gotchas covering file access semantics, temp cleanup, routing rules, child jobs, executor limits
152
+ - `switch-api/api-execution-environment.md`: execution modes, process model, state persistence across jobs, error handling, npm/native module constraints
153
+ - `switch-api/api-app-guidelines.md`: pre-publish checklist for Appstore apps covering property naming/tooltips/editors, entry point and sendTo consistency, logging quality, packaging, app-only submission rules
@@ -86,6 +86,16 @@ Called when a job arrives. Must eventually call a `job.sendTo*()` or `job.fail()
86
86
  [api-script-declaration.md](api-script-declaration.md#built-in-elementfields). Never leave an empty
87
87
  `jobArrived` or `timerFired` in the script — remove the function entirely if it does nothing.
88
88
 
89
+ **Gotcha: a flow restart replays every queued job through `jobArrived` again.** This includes a job
90
+ whose real processing was deferred elsewhere, such as a job registered in global data and actually
91
+ handled later in `timerFired`. `jobArrived` does not skip a job just because it was already
92
+ registered on a previous run; if the element still has a large backlog queued when the flow
93
+ restarts, every one of those jobs fires `jobArrived` again, and working through a long backlog this
94
+ way can take a long time even when each invocation only needs to recognize the job as already
95
+ registered and return. A script that defers processing this way must check global data at the top
96
+ of `jobArrived` and return immediately for a job already registered there, rather than assuming
97
+ `jobArrived` fires exactly once per job.
98
+
89
99
  ```ts
90
100
  async function abort(s: Switch, flowElement: FlowElement, job: Job, abortData: any): Promise<void>
91
101
  ```
@@ -0,0 +1,100 @@
1
+ # Project Planning
2
+
3
+ A pre-scaffolding checklist for a new script or app. Work through this with the user before
4
+ creating any files. The goal is to make a few decisions deliberately up front, because retrofitting
5
+ them after code exists is expensive: password protection and localization for an app, path handling
6
+ for a second target OS, synchronizing shared-resource access for concurrency, or restructuring entry
7
+ points around a job-processing approach chosen too casually.
8
+
9
+ Two items below are direct questions for the user. The rest are not questions to ask upfront; they
10
+ are checks the agent runs against what's actually being built, raised only when they become
11
+ relevant.
12
+
13
+ ## Ask the user directly
14
+
15
+ ### 1. Script or App?
16
+
17
+ Ask whether this is for private or internal use (a plain `Script`, distributed freely) or intended
18
+ for the Enfocus Appstore (an `App`). See
19
+ [api-script-structure.md § Script vs App](api-script-structure.md#script-vs-app) for what differs.
20
+
21
+ This answer gates several items below:
22
+
23
+ - **App**: localization, password protection, `Name`-never-changes discipline, `Concurrent`-by-default
24
+ expectation, icon/keywords, and the version-baseline and Appstore-competition checks further down
25
+ all apply. See [api-app-guidelines.md](api-app-guidelines.md) for the full pre-publish checklist,
26
+ most of which is worth designing toward from the start rather than retrofitting later.
27
+ - **Script**: none of the app-only items apply. Keep it simple and don't raise app concerns for a
28
+ plain script.
29
+
30
+ If App, also ask which languages it must support. English is required; more than one language is
31
+ preferable, see [api-app-guidelines.md § Localization](api-app-guidelines.md#localization).
32
+
33
+ ### 2. What should job processing look like in their flow?
34
+
35
+ Ask about job handling at a functional level: what should happen when a job arrives, does anything
36
+ need to wait on an external process or resource, could more than one job at a time contend for a
37
+ shared resource. Don't ask the user to pick entry points or connection types directly. Translate the
38
+ answer into a concrete proposal (which entry points, which `sendTo*()` methods, whether `jobArrived`
39
+ alone is enough or work must be deferred to `timerFired`) using
40
+ [api-entry-points.md](api-entry-points.md) and
41
+ [api-job-patterns.md § Sending jobs](api-job-patterns.md#sending-jobs), and be upfront about
42
+ limitations and tradeoffs so the user can make an informed choice, rather than silently picking an
43
+ approach.
44
+
45
+ If the design defers job processing to `timerFired` via global data, say explicitly that a flow
46
+ restart replays every queued job through `jobArrived` again, and the script must recognize and skip
47
+ an already-registered job quickly, or a large backlog is slow to clear, see
48
+ [api-entry-points.md § Job processing](api-entry-points.md#job-processing).
49
+
50
+ ## Evaluate and flag, don't ask upfront
51
+
52
+ ### Target OS
53
+
54
+ Switch Server runs on Windows and macOS. Default to writing platform-independent code (the `path`
55
+ module, no hardcoded separators, see
56
+ [api-job-patterns.md § Platform-independent paths](api-job-patterns.md#platform-independent-paths))
57
+ without asking. Only raise target OS as an explicit question once the script needs OS-specific code,
58
+ bundles a native binary, or ships a platform-specific package build, since only then does the answer
59
+ change anything.
60
+
61
+ ### Switch version baseline (apps only)
62
+
63
+ Once Script vs App is answered as App, ask or infer the oldest Switch version the app must support.
64
+ This sets the Node.js baseline (see
65
+ [api-script-structure.md § Node.js version per Switch version](api-script-structure.md#nodejs-version-per-switch-version))
66
+ and which SwitchScripter build is needed to produce a compatible `.enfpack`. Don't ask this for a
67
+ plain script.
68
+
69
+ ### Concurrency
70
+
71
+ Default to `Concurrent` execution; it's the preferred choice for apps per
72
+ [api-app-guidelines.md § Top-level declaration properties](api-app-guidelines.md#top-level-declaration-properties).
73
+ Don't ask the user to choose upfront. Only raise `Serialized`, and explain why, when the design has
74
+ an actual reason to need it: a third-party application or shared resource that can't tolerate
75
+ concurrent access, or an API the script drives that isn't safe to call in parallel. See
76
+ [api-execution-environment.md § Execution modes](api-execution-environment.md#execution-modes).
77
+
78
+ ### Native or binary npm dependencies
79
+
80
+ A file-based script or app that ends up on the ESM bundling path cannot use native (binary) Node
81
+ addons at all, see
82
+ [api-execution-environment.md § Native (binary) addons are not supported](api-execution-environment.md#native-binary-addons-are-not-supported).
83
+ If a planned dependency needs one, for example `sharp` or native `sqlite3` bindings, say so before
84
+ the user commits to that library, and suggest a pure JavaScript alternative or a workaround, such as
85
+ shelling out to an external binary, see
86
+ [api-job-patterns.md § Driving a third-party CLI application](api-job-patterns.md#driving-a-third-party-cli-application),
87
+ where one exists.
88
+
89
+ ### Appstore competition risk (apps only)
90
+
91
+ An app whose core functionality duplicates an existing Switch module without requiring that module
92
+ risks Appstore rejection. For example, an app that performs database CRUD operations without
93
+ requiring the Database Module competes directly with it. If the planned app looks like it falls into
94
+ this category, say so before significant effort is spent, and suggest either gating the app behind
95
+ the relevant module license or contacting Enfocus to check before proceeding.
96
+
97
+ ---
98
+
99
+ This checklist stops at planning. Once these are answered, move to
100
+ [api-script-structure.md](api-script-structure.md) to scaffold the project.
@@ -11,6 +11,7 @@ Detailed API docs are in `docs/switch-api/`:
11
11
 
12
12
  | File | Contents | Load when |
13
13
  |---|---|---|
14
+ | `switch-api/api-project-planning.md` | Pre-scaffolding checklist: Script vs App, job-processing approach, target OS, Switch version baseline, concurrency, native/binary npm dependencies, Appstore competition risk | Starting a new script or app, before scaffolding any files |
14
15
  | `switch-api/api-entry-points.md` | All entry point signatures, constraints, and when each is called | Scaffolding a script, adding/editing an entry point, or making any edit to main.ts/main.js |
15
16
  | `switch-api/api-switch.md` | `Switch` (`s`) — global data, webhooks, abort, server utilities | Using global data, webhooks, abort, or server settings |
16
17
  | `switch-api/api-flow-element.md` | `FlowElement` — properties, connections, job creation, logging | Reading properties, creating jobs, logging, connections |
@@ -32,7 +33,11 @@ Detailed API docs are in `docs/switch-api/`:
32
33
  | `switch-api/api-app-guidelines.md` | Pre-publish checklist for Appstore apps: property naming/tooltips/editors, entry point and sendTo consistency, logging quality, packaging, and the app-only submission rules (localization, signed universal macOS binaries) | Preparing a script for publication as an app, or reviewing one against Appstore submission criteria |
33
34
 
34
35
  ## Key rules
36
+ - Before scaffolding a new script or app, work through `switch-api/api-project-planning.md` with the user.
35
37
  - Always consult the API reference files above before writing or modifying script code.
38
+ - To find documented behavioural pitfalls before writing code in an area, grep `docs/switch-api/`
39
+ for `known issue`, `gotcha`, `quirk`, `caveat` (case-insensitive) — every documented pitfall uses
40
+ one of these four terms.
36
41
  - Do not `export` entry point functions. Declare them with the literal `function` keyword at top
37
42
  level — arrow functions, `exports.name = ...`, and class methods are invisible to Switch.
38
43
  - Switch discovers entry points with a regex, not a parser. Never write a string literal whose
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@enfocussw/switch-scripting-context",
3
- "version": "25.11.0-beta.13",
3
+ "version": "25.11.0-beta.14",
4
4
  "description": "AI coding assistant context for Enfocus Switch scripting (Node.js/TypeScript)",
5
5
  "keywords": [
6
6
  "switch",
@@ -27,14 +27,17 @@
27
27
  "docs/",
28
28
  "!docs/superpowers",
29
29
  "!docs/temp",
30
+ "!docs/adr",
30
31
  "CHANGELOG.md"
31
32
  ],
32
33
  "scripts": {
33
34
  "build": "tsc -p tsconfig.json",
34
35
  "build:test": "tsc src/init.test.ts --outDir dist --target ES2020 --module commonjs --lib ES2020 --types node --strict --esModuleInterop --skipLibCheck",
35
- "test": "npm run build && npm run build:test && node dist/init.test.js",
36
- "prepack": "npm run build",
37
- "postpack": "node -e \"const fs=require('fs');const version=process.env.npm_package_version;const scoped=process.env.npm_package_name.replace(/^@/,'').replace('/','-')+'-'+version+'.tgz';const unscoped=process.env.npm_package_name.replace(/^@[^/]+\\//,'')+'-'+version+'.tgz';if(scoped!==unscoped&&fs.existsSync(scoped))fs.renameSync(scoped,unscoped);\""
36
+ "test": "npm run build && npm run build:test && node dist/init.test.js && node scripts/check-prose.js && node scripts/check-gotcha-tags.js",
37
+ "prepack": "npm run build && node scripts/readme-links.js --publish",
38
+ "postpack": "node scripts/readme-links.js --restore && node -e \"const fs=require('fs');const version=process.env.npm_package_version;const scoped=process.env.npm_package_name.replace(/^@/,'').replace('/','-')+'-'+version+'.tgz';const unscoped=process.env.npm_package_name.replace(/^@[^/]+\\//,'')+'-'+version+'.tgz';if(scoped!==unscoped&&fs.existsSync(scoped))fs.renameSync(scoped,unscoped);\"",
39
+ "lint:prose": "node scripts/check-prose.js",
40
+ "lint:gotchas": "node scripts/check-gotcha-tags.js"
38
41
  },
39
42
  "author": "Sam Wallace",
40
43
  "license": "ISC",