fix: currency blocker wave — deploy path, validate, scaffold deps, docs (audit items 1-7)#1
Merged
Merged
Conversation
The host's on-disk storage root is ~/Library/Application Support/AppOS/ (AppOS-Desktop AppStoragePaths.swift:20,27-32; PluginHostConfiguration.swift:65,70 appends 'plugins' to that root). The com.twopanez path was never the shipping install dir for the AppOS host, and the 'installer has not been renamed' note was false — deleted. Remaining com.twopanez mentions live only in compiled/ artifacts, which get the same substitution in the compiled-refresh commit.
…t M1) Ground truth from AppOS-Desktop project.yml:14 (MARKETING_VERSION 1.0.0) and project.yml:85 (PRODUCT_NAME AppOS -> /Applications/AppOS.app). The 1.7.0 / 2Panez.app values described a pre-rename dev build that never shipped. Also drops the '(legacy name, do not rename)' caveat in CLAUDE.md — the shipping bundle is AppOS.app. compiled/ artifacts get the same substitution in the compiled-refresh commit.
…n-v1.json (audit B2) Replaces the stale closed 33-item permission list with validation against the SDK's authoritative schemas/plugin-v1.json (which also covers required fields and shapes). Two documented mechanisms, both verified against the flagship appos-plugin-ytdlp manifest (origin/main 22d1c63): - Preferred: curl the schema from the public appos/plugin-sdk repo + 'npx -p ajv-cli -p ajv-formats ajv validate --spec=draft2020' -> exit 0, 'ytdlp-plugin.json valid' - Alternative: 'node scripts/validate-schema.mjs <manifest>' from a plugin-sdk clone (positional manifest paths) -> exit 0, '1 passed, 0 failed' The old list was wrong in both directions: it contained permissions that do not exist in the schema and omitted dozens that do (events.*, store.*, vault.*, clipboard.*.register, ...).
…ptions (audit B3) Scaffolded package.json now depends on the published npm packages (@appos.space/plugin-types ^2.4.0 devDep; plugin-utils + view-builders ^2.4.0 deps), matching the flagship appos-plugin-ytdlp @ origin/main 22d1c63. The file: variant survives as a collapsed 'SDK contributors only' note. Also removes the ~/Documents/GitHub/AppOS/... home-path assumptions from steps 1 and 5 — third-party devs pick any target directory. Verified in a scratch dir: the exact scaffold (package.json + tsconfig.json + build.mjs + minimal src/main.ts importing all three packages) npm-installs from the registry, 'npm run build' emits a dist/main.js IIFE with both globalThis entry points, and 'tsc --noEmit' passes.
…e host-wired (audit M2+M3)
M2: the flagship appos-plugin-ytdlp (origin/main 22d1c63) ships its WebView
assets under webview/ (src/panels/*.ts registers htmlPath
'webview/download/index.html'); the docs' panels/ bundle tree never matched.
src/panels/*.ts references stay — that IS the real TS source layout.
M3: ctx.lifecycle.getDependencyStatus() / recheckDependencies() are wired in
the host (AppOS-Desktop PluginContextBridge.swift:1795,1859 delegating to
PluginLifecycleManager.recheckDependencies(for:) at :3913) and ytdlp calls
both in production (src/main.ts:269,430; download-panel.ts:337;
library-panel.ts:208). Removed the 'types-only -- do NOT call' warnings and
documented the subscribe-first-then-read ordering instead.
reference/plugin-api.d.ts:1286 ('panels/output.html' @example) intentionally
untouched: it is a synced snapshot of the host's own plugin-api.d.ts
(AppOS-Desktop :2454); fixing it belongs upstream.
… drop vestigial root plugin.json (audit M5)
- CLAUDE.md repository-layout block now shows the real tree: the plugin lives
at plugins/appos-dev/ (with the viewdescriptor agent/skill and compiled/
artifacts that the old block omitted); root .claude-plugin/ carries only
marketplace.json
- Local-dev instructions point --plugin-dir at plugins/appos-dev (the repo
root is a marketplace, not a plugin) and no longer assume a maintainer
home path
- README install command is the in-session '/plugin marketplace add
appos/appos-dev-plugin' + '/plugin install appos-dev' flow ('claude
/plugin ...' is not a shell command)
- Root .claude-plugin/plugin.json deleted: the marketplace entry in
marketplace.json (source: ./plugins/appos-dev) is what installs; the root
manifest belonged to the pre-marketplace layout
…RLs (audit M4) ~/Documents/GitHub/AppOS/... 'source of truth' pointers only resolved on the maintainer's machine. Third-party devs now get: - https://docs.appos.space (live) as the canonical developer docs - https://github.com/appos/appos-plugin-ytdlp for the flagship reference - https://github.com/appos/plugin-sdk for SDK source (npm: @appos.space/*) compiled/ artifacts get the same substitution in the compiled-refresh commit.
…; 13->17 ViewDescriptor types; onWebPanelMessage cleanup contradiction compiled/plugin-factory-context.md claims to be generated by scripts/compile-factory-context.sh, but that script does not exist in this repo — so the items 1/2/5/7 + M3 substitutions were applied to the artifact directly (28 asserted-count replacement groups): AppOS install path, host 1.0.0 / AppOS.app, panels/ -> webview/ bundle tree, public docs/repo URLs, and lifecycle query APIs host-wired. Absent generator noted in the PR body as a follow-up. Also fixes in passing: - viewdescriptor-builder agent + plugin-architect agent claimed 13 ViewDescriptor types; the SDK defines 17 (adds grid, remoteImage, textField, progress — matching extension-api.md and the viewdescriptor-authoring skill) - new-plugin.md pushed onWebPanelMessage's return value into disposables[] while stating it returns void two lines later; scaffold now uses the documented disposed-flag pattern
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bbcc9861de
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
- validate: thread $PLUGIN_ROOT through discovery + schema commands; document why main is the correct schema anchor (shipped host accepts full enum; v2.4.0 tag false-fails the flagship) - README: /plugin install appos-dev@appos-dev (marketplace-qualified) - marketplace.json: bump both version fields to 2.0.1; CLAUDE.md version prose de-hardcoded
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: be58d5d449
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
- WebFetch + ordered fetchable sources (raw URLs, docs.appos.space) for both remote-reading agents - Flagship-repo references degrade gracefully: local clone -> GitHub (public at launch) -> docs.appos.space always-on anchor - Settings type bool (not boolean) at scaffold/agent source, verified vs schema + host parser; validate clone-recipe switched to direct ajv
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 433b969275
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
validate.md: make the clone-available schema-validation path genuinely offline — use the SDK's own validate-schema.mjs with a positional manifest path (supported on current plugin-sdk main) instead of an npx ajv-cli invocation that requires npm package resolution. Remove the stale claim that the script takes no positional arguments; state the one-time 'npm install' precondition and redirect to the structural fallback when deps are absent offline.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements the BLOCKER WAVE (items 1–7 of the currency-audit remediation, plus the compiled/ refresh) from the 2026-07-23 currency audit. Audit verdict: the plugin's mechanical instructions had drifted from shipping reality — a scaffolded plugin could not
npm install(file: deps into a maintainer-only path), deployed to a directory the host never reads, and validated permissions against a list that is wrong in both directions. All S-sized blockers are fixed here, verified against the live host source (AppOS-Desktop, read-only), the SDK (appos/plugin-sdk@ main), and the flagship (appos/appos-plugin-ytdlp@ origin/main 22d1c63). Per the audit's recommendation this wave targets published npm 2.4.0 — it does NOT wait for the 3.0.0 publish and does NOT touch API-inventory knowledge (that is wave 2).Per-item fixes
com.twopanez→AppOSeverywhere (~/Library/Application Support/AppOS/plugins/<id>/per AppStoragePaths.swift:20,27-32 + PluginHostConfiguration.swift:65,70); deleted the false "installer has not been renamed" note1.7.0→1.0.0,2Panez.app→AppOS.app(project.yml:14,85); dropped "(legacy name, do not rename)"validatepermission check is now schema-driven against the SDK'sschemas/plugin-v1.json(preferred: curl schema from public repo +npx -p ajv-cli -p ajv-formats ajv validate --spec=draft2020; alternative:node scripts/validate-schema.mjs <manifest>from a plugin-sdk clone). Removed the closed 33-item list (wrong in both directions)@appos.space/plugin-types^2.4.0(devDep) +plugin-utils/view-builders^2.4.0(deps);file:survives only as a collapsed "SDK contributors only" note; maintainer home-path assumptions removedpanels/→webview/(matches ytdlp's real tree;src/panels/*.tsTS sources stay). LifecyclegetDependencyStatus()/recheckDependencies()"types-only — do NOT call" warnings removed: both are host-wired (PluginContextBridge.swift:1795,1859 → PluginLifecycleManager:3913) and ytdlp calls them in production (main.ts:269,430; both panels)plugins/appos-dev/);--plugin-dirpoints atplugins/appos-dev; vestigial root.claude-plugin/plugin.jsondeleted (marketplace.json stays); README install is the in-session/plugin marketplace add appos/appos-dev-pluginflow~/Documents/GitHub/AppOS/...source-of-truth pointers → https://docs.appos.space (live) +https://github.com/appos/appos-plugin-ytdlp/https://github.com/appos/plugin-sdkcompiled/plugin-factory-context.md(28 asserted-count replacement groups); "13 ViewDescriptor types" → 17 in both agents; fixed theonWebPanelMessagedisposables/void self-contradiction in new-plugin.mdVerification
Full-tree greps (excluding
.git/):com.twopanez→ 01\.7\.0/1\.7\.x/2Panez→ 0~/Documents,Documents/GitHub,/Users/d/) → 0panels/survivors — all justified:src/panels/*.ts+./panels/*-panel.jsimports (ytdlp's real TypeScript source layout; itssrc/panels/download-panel.tsregistershtmlPath: 'webview/download/index.html'), and one"panels/output.html"@example inreference/plugin-api.d.ts:1286, which is a faithful synced snapshot of the host's own d.ts (AppOS-Desktop plugin-api.d.ts:2454) — fix belongs upstreamytdlp validate proof (item 3): both documented mechanisms pass on the flagship manifest @ origin/main 22d1c63 — ajv path: exit 0,
ytdlp-plugin.json valid; SDK-script path: exit 0,1 passed, 0 failed.Scaffold install proof (item 4): in a scratch dir, the exact scaffold (package.json + tsconfig + build.mjs + minimal main.ts importing all three packages)
npm installs from the registry (6 packages),npm run buildemits an IIFEdist/main.jswith bothglobalThisentry points (grep -c globalThis= 2, nomodule.exports), andtsc --noEmitpasses.Follow-ups (not this PR)
compiled/plugin-factory-context.mdclaims to be generated byscripts/compile-factory-context.sh, but that script is not in the repo. This wave patched the artifact directly; the generator should be restored/committed so compiled/ can be regenerated instead of hand-edited.panels/output.htmlexample) against SDK 3.0.0 once published, plus any new-in-3.0 surfaces. Deliberately untouched here per the audit:window.twopanezbridge,plugin-panel://scheme,--twopanez-*CSS tokens, entrypoint/globalThis contract, fileOps naming, listItemtrailing:, button options, 17 ViewDescriptor types.