You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -25,6 +26,7 @@ This guide explains how to write, configure, and run ACASL plugins that operate
25
26
Highlights (what changed)
26
27
- Orchestrated output opening: the host resolves and opens the engine output directory after ACASL; plugins must not open folders themselves.
27
28
- Artifacts are filtered to the engine-defined output directory.
29
+
- SDK-level enforcement: ACASL plugins are confined to the engine output directory. The SDK context restricts all file helpers (safe_path, write_text_atomic, replace_in_file, batch_replace, iter_files, iter_project_files) to this directory.
28
30
- Global enable/disable switch in the ACASL loader; when disabled, ACASL is skipped but the output folder can still be opened by the orchestrator.
29
31
- Soft timeout prompt (non-blocking) when plugins are unlimited; robust worker threading.
30
32
- Extended plugin metadata supported in the UI: ACASL_NAME, ACASL_VERSION, ACASL_AUTHOR, ACASL_CREATED, ACASL_LICENSE, ACASL_COMPATIBILITY, ACASL_TAGS.
@@ -40,21 +42,34 @@ ACASL is the post‑compilation counterpart to BCASL. It runs automatically afte
40
42
- Discovery is strict: only packages under `API/<plugin_id>/` that declare `ACASL_PLUGIN = True` and expose `acasl_run(ctx)` are considered. The runtime validates `ACASL_ID`/`ACASL_DESCRIPTION`; extended metadata are optional but recommended.
41
43
- ACASL runs asynchronously (non‑blocking UI). Each plugin run is measured (duration in ms). A soft timeout prompt may appear when the configured timeout is unlimited.
42
44
- The host computes the engine output directory and filters artifacts to files under that directory before passing them to plugins.
45
+
- Scans and file operations in plugins are rooted in the output directory (SDK-enforced, see below).
To guarantee safety and consistency, the SDK enforces a strict scope for ACASL plugins:
55
+
- The SDK context (sctx) carries an internal `allowed_dir` equal to the engine output directory.
56
+
- All file helpers respect this scope:
57
+
-`sctx.safe_path(...)` raises if the resolved path is outside `allowed_dir` (and workspace).
58
+
-`sctx.iter_files(...)` and `sctx.iter_project_files(...)` are rooted at `allowed_dir`.
59
+
-`sctx.write_text_atomic`, `sctx.replace_in_file`, `sctx.batch_replace` refuse to touch files outside `allowed_dir`.
60
+
-`wrap_post_context(ctx)` sets this scope automatically and filters `sctx.artifacts` to items under `allowed_dir`.
61
+
- Practical advice:
62
+
- Prefer using the `sctx.artifacts` list and derive any additional paths relative to the output directory.
63
+
- Passing absolute paths under the output directory to `sctx.safe_path(...)` is supported and recommended when in doubt.
64
+
50
65
## Where to place your plugins (package layout) {#where-to-place-your-plugins-package-layout}
51
66
Create Python packages under API/ (not loose .py files). Do not place ACASL plugins under acasl/ or bcasl/:
52
67
```
53
68
API/
54
69
├── hash_report/
55
70
│ └── __init__.py
56
71
├── compress_zip/
57
-
│ └��─ __init__.py
72
+
│ └── __init__.py
58
73
├── signer_windows/
59
74
│ └── __init__.py
60
75
├── codesign_macos/
@@ -132,14 +147,16 @@ def acasl_run(ctx):
132
147
133
148
## ACASL SDK facade and Context (available API) {#acasl-sdk-facade-and-context-available-api}
134
149
Always import from `API_SDK.ACASL_SDK`. Core items:
135
-
-`wrap_post_context(post_ctx) -> SDKContext` — converts host ACASLContext into SDKContext, loading workspace config and copying the artifacts list.
150
+
-`wrap_post_context(post_ctx) -> SDKContext` — converts host ACASLContext into SDKContext, loading workspace config and copying the artifacts list. It also:
151
+
- resolves the engine output directory and sets `sctx.allowed_dir` to this path,
152
+
- filters `sctx.artifacts` to entries under `allowed_dir`.
136
153
- SDKContext (sctx) provides:
137
-
- Attributes: `workspace_root`, `artifacts`, `engine_id` (None in ACASL), `config_view`
## Best practices (security, UX, logs) {#best-practices-security-ux-logs}
263
280
- Do not open folders or file explorers; the orchestrator opens the engine output directory.
281
+
- Operate strictly within the engine output directory: rely on `sctx.artifacts`, `sctx.iter_files(...)`, `sctx.write_text_atomic(...)`, etc. The SDK ensures operations outside this directory are rejected.
264
282
- Security: secrets only via environment or separate secure files; never commit secrets.
265
283
- UX: reduce modal prompts; prefer logs and one final summary dialog; respect non‑interactive mode.
266
284
- Logs: always log the output file paths you create.
- Use the “🔌 ACASL API Loader” to enable and order plugins; the config is saved to `acasl.json` (with `options.plugin_timeout_s` and `options.enabled`).
372
390
- ACASL runs automatically after builds; plugins operate on `sctx.artifacts` (filtered to engine output dir).
373
391
- Do not open output folders from plugins; the orchestrator opens the engine output directory.
392
+
- Operate only within the output directory; the SDK enforces this scope for all file helpers.
374
393
- Check cancellation, use timeouts, keep plugins idempotent, and leverage i18n via `load_plugin_translations` + `sctx.tr` fallback.
0 commit comments