soia-cwork-processon-diagrams

ProcessOn diagram browsing and export

Read team spaces, folders, diagram titles, and visible content through the skill's own ProcessOn browser profile; export diagrams within the scope specified by the user, safely archive downloads to the delivery directory, and generate a verifiable manifest for local POS, image, SVG, PDF, and XMind files. Read-only by default; do not modify, share, move, or delete remote files; formal batch tasks must not take over the customer's Chrome in use.

Customer-readable description

What this skill can do

Customer wants	Skill will do	Customer can see
Inventory team spaces	Recurse from the specified node to every subdirectory and leaf file, save in small batches and audit recovery status	Markdown/JSON tree, progress snapshot, missing difference set, permission gaps, and completion receipt
See what is in a diagram	Enter the "Browse" view to read accessible text, and use screenshots to verify the visual layout	Content summary, key text, and screenshots
Export diagrams	Choose VSDX, POS, PNG, SVG, PDF, XMind, or Office format according to customer authorization	Downloaded files, format/size/SHA-256 acceptance
Archive browser downloads	Parse paths from CLI, environment variables, and private YAML, and copy/move verified downloaded files to the delivery directory	Final path, collision policy, SHA-256, and audit manifest
Batch resumable archiving	Initialize the download queue from the archive plan, claim items one by one, record success/failure/blockage, and replay the audit	download-progress.json, next batch list, and mechanical acceptance results
Control the browser without interference	Invoke the local Playwright runner from any AI/terminal, executing headless in the skill-dedicated profile	Independent login state, page close count, download receipt; the customer's main Chrome is not taken over
Parse existing exports	Read local POS/XMind/SVG/images; VSDX can be handed to the optional draw.io/Visio skill	Title, diagram type, node text, dimensions, and checksum

How the customer uses it

The customer provides the minimum necessary part of the following information:

1. ProcessOn team, folder, or diagram URL; a space name and file name may also be given.
2. Target action: initialize inventory, incremental inventory, download archiving, or parse/convert existing export files.
3. When exporting, specify the file scope, format, and delivery directory; if no format is specified, flowcharts default to the Visio .vsdxcurrently available in the menu, and mind maps default to .xmind. For both types, it is recommended to also keep POS as a native ProcessOn structure backup. When the type cannot be confirmed from the icon, browse view, or menu, only write it to the "manual confirmation required" list; do not guess the format or download automatically. For visual reuse, prefer SVG/high-resolution PNG; for review delivery, prefer PDF.
4. On first use, the customer only needs to log in theindependent ProcessOn windowManually enter the username, password, SMS code, or verification code; the window closes automatically after success, and subsequent batches default to headless. The skill does not read, record, or output Cookies, Local Storage, password files, or credentials.
5. Optionally copy path configuration template to a private configuration directory to fix temporary downloads, final deliverables, audit manifests, and retention days.

Example:

初始化盘点这个 ProcessOn 团队空间，只读，不下载：<team-url>
对上次盘点和今天重新审计后的快照做增量盘点，不猜测删除项
按已审计计划下载已确认流程图为 VSDX、思维导图为 XMind，归档到 <output-dir>
解析 <export-dir> 里的 POS，或把 VSDX 转成 draw.io 真源后升级

Dependencies and Installation

Dependency	Type	Installation / Configuration	What to do when missing
ProcessOn account and target resource permissions	Hard dependency	The customer logs in on the official ProcessOn page and ensures the target space is visible to them	Stop remote reading and list the missing permissions
Playwright + Chrome/Chromium	Hard dependency for remote operations	pip install playwright && python -m playwright install chromium	Switch to the customer manually exporting and then parsing the local file
Agent built-in browser/computer-use	Optional diagnostic capability	Only allow one-time troubleshooting explicitly agreed to by the customer; forbidden as the formal batch main route	Directly use the host-agnostic runner, with no impact on functionality
Python 3.10+	Local parsing and archiving dependency	System Python is sufficient	Only complete browser-side inventory/export
PyYAML	Optional dependency for private configuration	When using config.yml , install:python3 -m pip install pyyaml	Switch to CLI parameters, environment variables, or secure defaults
soia-dev-drawio-visio-diagrams	Optional dependency for VSDX understanding/upgrade	Install from the same SOIA skills repository	VSDX can still be downloaded and archived, but draw.io conversion and element-level upgrades are not performed
ProcessOn API service	Optional commercial capability	Enterprises apply for JS-SDK/format conversion credentials according to the official process	Does not affect the browser workflow for regular accounts

Default location for private configuration:

~/.config/soia-skills/soia-open-skills/cwork/soia-cwork-processon-diagrams/config.yml
SOIA_CWORK_PROCESSON_DIAGRAMS_CONFIG_FILE=<custom-config-path>

Configuration priority is CLI parameters → process environment variables → private config.yml → cross-platform secure defaults. For configuration keys, default paths, and commands, see Download and Archive Workflow. Private configuration only stores paths and retention policies, not usernames, passwords, Cookies, Tokens, or browser profiles.

Formal remote operations first execute the host-agnostic runner; any Claude Code, Codex, Gemini CLI, OpenCode, or ordinary terminal can call it:

python3 scripts/processon_browser_runner.py login --url '<team-url>'
python3 scripts/processon_browser_runner.py status --url '<team-url>'
python3 scripts/processon_browser_runner.py snapshot --url '<folder-url>'
python3 scripts/processon_browser_runner.py run \
  --actions <actions.json> --download-dir <managed-temp-dir>

The runner's action file only allows navigation, named semantic clicks/hovers, scrolling, waiting, controlled popups, and downloads; it does not accept arbitrary CSS/unnamed controls, and mechanically rejects remote change entry points such as delete, edit, move, share, and publish; it does not provide form filling, script execution, reading Cookies/Storage, or injecting credentials. For the action format and tag lifecycle, see Download and Archive Workflow。

Logs and Completion Receipt

Each run reports at least:

• The scope of spaces/folders read, and the number of folders, diagrams, and restricted items found.
• Whether what is actually seen during preview is DOM text, thumbnails, browsing view, or exported POS; do not treat thumbnail OCR as structured original text.
• During export, report by category the requested format, actual format, success/failure counts, file size, and verification results.
• When archiving, report the browser's actual download path, final delivery path, copy/move mode, same-name handling, manifest path, and SHA-256.
• When cleaning up, first report the number of dry-run candidates; actual cleanup only processes temporary directories with skill markers and generates a deletion audit manifest.
• Security verification, membership format restrictions, insufficient permissions, or page structure changes must be listed separately and must not be disguised as success.
• Each batch report must include the browser mode, dedicated profile,pages_seen_at_start、stale_pages_closed、scoped_pages_opened/closed and pages_closed_at_exit; if the close count is abnormal, the batch must not claim completion.
• A full inventory must report the "set of subdirectories declared by the parent directory − set actually visited"; if the difference set is non-empty, only "partially complete" may be written.
• The completion receipt must come from the mechanical result of audit replaying all immutable batches; completion must not be claimed based solely on checkpoint statistics or browser pages.
• Directory inventory and source file archiving must be reported in phases:inventory_completed_asset_archive_pending is not "knowledge base archiving complete".
• Before asset archiving, an archiving plan must be generated from the final checkpoint;ready_for_known_artifacts controls downloads of confirmed types,ready_for_archive only after unknown types are also cleared is it true。
• Formal downloads must first initialize download-progress.json, and immediately after each artifact completes or is blocked, record/mark; the sole progress record must not be maintained only in the conversation, browser download list, or knowledge base Markdown.
• Incremental inventory must report the SHA-256 of two complete snapshots, added, changed, and removed candidates; it is not a ProcessOn event/API increment. Without a stable remote_id/id , files must not be claimed to have "moved"; only added/removed candidates may be reported.
• The final reply gives the delivery directory, verification method, and incomplete items; do not output accounts, Cookies, Tokens, or browser internal state.

Operating boundaries

• Read-only by default. Browsing, searching, screenshots, and downloads are permitted actions; editing, renaming, copying, moving, deleting, locking, inviting collaboration, and public sharing must be explicitly authorized by the customer in the current request.
• Formal batches may only use the skill-dedicated profile; attaching to the customer's default Chrome profile is prohibited, and using Codex/Claude's browser, computer-use, or extensions to repeatedly open and close tabs in the customer's main Chrome is prohibited. The dedicated runner is headless by default; headed mode is used only for first login, a real visible CAPTCHA, or when the customer explicitly requests observation.
• When the dedicated context starts, only one parent page is kept; at most one temporary popup is allowed and it must be closed within the nested action finally ; on success, failure, timeout, Ctrl-C, and SIGTERM, all dedicated pages and the context must be closed. After a soft interrupt, verify the close receipt before resuming.
• Before downloading, confirm the target file, format, and delivery location. If the customer has already explicitly requested an export in the current request, there is no need to reconfirm the same scope.
• Only process files the customer has the right to access. Do not expand the visible scope by guessing URLs, internal interfaces, Cookies, or undisclosed endpoints.
• Prefer ProcessOn's official UI and official documentation. When ordinary accounts do not have a public team file REST API, reverse-engineered interfaces must not be packaged as a stable API.
• Stop automated interaction only when a CAPTCHA/slider control actually appears in the current viewport and blocks or obstructs the target operation, leaving the page for the customer to take over; if it exists in the DOM display:none、Zero-size or preloaded iframes moved outside the viewport are not a "CAPTCHA has popped up". Do not simulate dragging, call CAPTCHA APIs, or bypass verification.
• Do not require customers to send passwords into the conversation; do not write usernames, passwords, Cookies, Tokens, login state, or browser profiles into configuration, command parameters, logs, or manifests.
• Download archives are copied by default and automatically renamed when the same name exists.--move Only temporary directories with a skill marker are allowed to be processed; overwriting must simultaneously use --collision overwrite --allow-overwrite, and the customer must explicitly authorize it in the current request.
• Temporary cleanup must explicitly execute cleanup; if there is no skill marker, the delivery directory is inside the temporary directory, or the file is a symbolic link, it must be rejected in all cases.

Private information and intermediate data

• ProcessOn diagrams, directory names, authors, and exported files may all contain internal enterprise information; inventory appears by default only in stdout/customer-specified reports and is not written to public skill repositories.
• Usernames, passwords, SMS codes, Cookies, Tokens, Local Storage, and browser profiles are left to the browser/provider itself to store; this skill does not read, copy, or record them.
• The skill-specific profile is by default located under the user's private config root; it is the local login state held by ProcessOn/browser and does not enter public repositories, runtime packages, or knowledge bases. The runner rejects the default Chrome/Chromium profile and non-empty directories without a skill marker.
• Temporary downloads use a skill-managed subdirectory under the operating system temporary directory; deliverables are placed in the customer-specified directory, and the audit manifest is placed in the user state directory. For retention period and path resolution, see Download archive workflow。
• Long browser tasks are batched by system/first-level directory, by default establishing the runtime package in ${XDG_STATE_HOME:-~/.local/state}/soia-cwork-processon-diagrams/runs/<run-id>/ ; each batch immediately persists the raw batch and checkpoint. After a session interruption, resume from pending_paths without relying on volatile memory to store the sole inventory result.
• Asset archive progress is always written to the runtime package's artifacts/download-progress.json; the state script uses an exclusive lock to guarantee a single writer, records completed, failed, blocked, and pending-confirmation queues, and restores from the same plan fingerprint.
• The runtime package is an intermediate control plane, not the body of the knowledge base; the knowledge base only receives the frozen inventory, the final artifact manifest, and verified delivery files.

Failure gates solidified in this execution

Before executing a complex team space, first read Failure mode reference. The following rules are hard gates:

1. "Full" must recurse to leaf directories; first-level pages, old browsing sessions, or model memory cannot replace checkpoints.
2. Multiple Agents only perform read-only page analysis in parallel; the same runtime package's record、audit and state files can only be executed serially by one writer.
3. Only CAPTCHAs that are truly visible in the current viewport and block operations are paused; hidden/zero-size/out-of-viewport iframes do not count as pop-ups, and verification must not be bypassed.
4. The user logs in manually; the Agent does not receive passwords, does not read Cookies/Tokens/profiles, and does not inject credentials through CDP or extensions.
5. If the diagram type cannot be proven by cards, browsing views, or menus, retain unknown, and enter the manual confirmation queue.
6. Passing the directory audit only means the inventory stage is complete; download, format validation, SHA-256, manifest, draw.io conversion, and preview belong to the independent artifact_archive stage.
7. The host browser capability is not the primary executor; batch tasks must be started from a dedicated runner. Every popup and the entire context must have a close receipt; a missing receipt is treated as an interruption pending recovery.

Workflow (strictly in three phases)

1. inventory: initialization inventory or incremental inventory

1.1 Access and initialization inventory (inventory.init）

1. First look for an official ProcessOn connector, public API, or CLI; when there is no dedicated capability that satisfies the current task, use processon_browser_runner.py and a skill-specific profile. The first login is completed manually by the client only in a separate runner window; do not read input values, Cookies, Tokens, or profiles, and no Chrome extension is needed. The host browser/computer-use may only perform one-off diagnostics after explicit client authorization and cannot take on the main batch workflow.
2. Use runner status/snapshot to open the client URL (if not provided, enter from "My Files/Team Space") and confirm that the target space is visible. If login or a security verification genuinely visible in the current viewport blocks progress, use a separate headed session to wait for the client to take over; a hidden iframe does not count as a popup. Read ProcessOn capabilities and formats before operating.
3. init A new run package must first be created; use BFS/DFS to recurse from the specified root to the leaves. Every 3–6 directories visited, commitcomplete directory snapshotas an immutable batch and then record; do not keep the only manifest solely in the browser session. For formats, recovery, and auditing, see Recursive inventory intermediate state。
4. At each level record the logical full path, subdirectories, diagram titles, types, authors, update times, and visible thumbnails/access restrictions. Single-click a folder to enter it; when the breadcrumb is collapsed at deep levels, still use the logical path as authoritative. Stop only when scrolling a virtual list twice in a row yields no new entries.
5. Run audit to replay the batch. Only when discovered_paths - visited_paths - blocked_paths = 0 and blocked=0 do you get a usable complete snapshot and receipt.md; otherwise you can only report a partial inventory.

python3 scripts/processon_inventory_state.py init \
  --run-id '<run-id>' --root-path '<logical-root>' --source-url '<team-url>'
python3 scripts/processon_inventory_state.py audit --run-dir <run-dir>

1.2 Incremental inventory (inventory.incremental）

1. ProcessOn regular team spaces have no public file event API that can be relied on; "incremental" isa local diff of two complete, audited snapshots, not scanning only the first-level directory, and certainly not guessing remote changes.
2. First rerun a inventory.init complete inventory with the same scope and pass audit, then compare the before and after checkpoints:

python3 scripts/diff_processon_inventory.py \
  --previous <previous-run>/inventory/checkpoint.json \
  --current <current-run>/inventory/checkpoint.json \
  --output <current-run>/analysis/inventory-delta.json

1. The diff script rejects pending or blocked snapshots, cross-root/cross-URL comparisons, symlinks, and duplicate stable IDs; output added、changed、removed_candidates and the SHA-256 of both checkpoints. Only entries with a stable remote_id/id may be reported as moved/renamed; entries without an ID will not have move relationships fabricated. Duplicate ID-less identities are quarantined into ambiguous_entriesand do not participate in any change conclusion.removed_candidates are candidates pending review and will not automatically delete the local archive.

2. archive: download and archive confirmed source files

Only after phase 1 producesthe latest, complete, and audit-passedcheckpoint does it begin. First generate and verify a recoverable asset plan:

python3 scripts/build_processon_archive_plan.py build \
  --checkpoint <run-dir>/inventory/checkpoint.json \
  --output <run-dir>/artifacts/archive-plan.json

The script generates for each entry a stable artifact_id, full logical directory, type evidence, default format, fallback format, name collision risk, and status; flowcharts default to vsdx, mind maps default to xmind，unknown only enter pending_confirmation。ready_for_known_artifacts=true and archive_status=known_ready_pending_confirmation may download confirmed types, but must not claim that full asset archiving is complete;ready_for_archive=true Only then do all entries qualify for archiving. If the inventory continues to change or is restored, regenerate the plan first; reusing the old plan is prohibited.

During download, use the following command to check that the plan still corresponds to the current checkpoint:

python3 scripts/build_processon_archive_plan.py verify \
  --plan <run-dir>/artifacts/archive-plan.json \
  --checkpoint <run-dir>/inventory/checkpoint.json

When verification fails, stop the download and regenerate the plan first; do not merge the success counts from a stale plan into a new round of reporting. Then execute item by item according to the plan:

First initialize or restore the formal download queue, and claim the next small batch in plan order:

python3 scripts/processon_archive_state.py init \
  --plan <run-dir>/artifacts/archive-plan.json \
  --progress <run-dir>/artifacts/download-progress.json
python3 scripts/processon_archive_state.py next \
  --plan <run-dir>/artifacts/archive-plan.json \
  --progress <run-dir>/artifacts/download-progress.json \
  --limit 10

init When the progress file already exists, only accept the same plan SHA-256, retain the existing success/failure/blocked evidence and mechanically refresh the counts; fail closed when the plan changes.next By default skip completed, failed, and blocked items; use only on explicit retry --include-failed or --include-blocked。

1. First use runner snapshot to obtain the currently visible text and semantic controls in the directory, then generate a small-batch action JSON; locate the target's "Download/Export" based on the snapshot, without relying on fixed coordinates or private CSS. The ProcessOn file list may be virtualized; if the target entry is not in the current viewport, first use scroll and take a new snapshot; do not record a location timeout as the file not existing. Select according to the confirmed type:
   • For flowcharts, by default select from the current account menu VISIO文件/.vsdx; for multiple canvases, prefer 导出全部画布 (.vsdx)；
   • For mind maps, by default select Xmind文件/.xmind；
   • Files whose type cannot be confirmed are added to the "Pending Manual Confirmation" list, and the download menu is not opened automatically. When the default format is unavailable, blocked by membership/permissions, or download fails, fall back to POS, and explicitly record "requested format, actual format, reason for downgrade"; silent replacement is not allowed. If no file is available when clicking on the list page, enter the official editor and retry XMind/POS/POSM; if none of these native formats has a file but Markdown can be downloaded, only use Markdown as diagnostic evidence and mark the artifact as blocked, and do not pass off Markdown as XMind/POS completion. For format selection, see ProcessOn Capabilities and Formats。
2. Run this the first time a managed temporary directory is needed paths --ensure; use runner download actions to capture the real download event and save it to the managed directory; do not judge success based on a Toast. ProcessOn export is an asynchronous task: initiate only one artifact at a time, and you must wait until the file has actually landed, its size is stable, and structural/semantic verification is complete before switching the selected item or initiating the next one; fixed sleep, click success, and short-lived download event timeouts cannot substitute for a disk-write signal. The temporary source page must be closed within finally after the download completes/fails. Dry-run first, then archive. The managed temporary directory can be explicitly --move; otherwise, by default copy and retain the browser's original file:

python3 scripts/finalize_processon_download.py paths --ensure
python3 scripts/finalize_processon_download.py finalize <browser-downloaded-file> --dry-run
python3 scripts/finalize_processon_download.py finalize <browser-downloaded-file>

1. Verify that the file is non-empty and that the extension matches the content type; VSDX must be a valid ZIP/OOXML and contain visio/document.xml, images must have their dimensions checked, POS/XMind must have their titles and extractable text checked, and all files must have SHA-256 recorded. Filenames can only be used as candidate evidence: if the asynchronous queue produces a (1) suffix, title drift, or the same name with different SHAs, call soia-dev-drawio-visio-diagrams to extract VSDX page text to counter-verify the source; if it cannot be uniquely matched to an artifact, keep it pending and do not move, rename, or call record. Batch downloads can only be executed one by one; do not claim that a batch API exists when the official site does not explicitly support it. Cleaning up the temporary directory must first cleanup --dry-run, and then be confirmed by the customer.

2. finalize On success, immediately bind the artifact, the actual delivered file, and the finalizer manifest to the progress; if the download event was not observed by the browser but the real file has been verified, use not_observed_verified_file, must not be mistakenly written as a successful browser event:

python3 scripts/processon_archive_state.py record \
  --plan <run-dir>/artifacts/archive-plan.json \
  --progress <run-dir>/artifacts/download-progress.json \
  --artifact-id <artifact-id> \
  --download-source <browser-downloaded-file> \
  --destination <archived-file> \
  --manifest <finalizer-manifest.json> \
  --actual-format vsdx \
  --download-event not_observed_verified_file

Use for membership restrictions, genuinely visible CAPTCHAs, permission or format failures mark --outcome blocked|failed --reason <reason> persisted to disk; must not mix in items that have not started. When diagnostic files already exist, use a repeatable --evidence-file archived into the run package; the status script will copy, hash, and at audit replay, avoiding Downloads evidence disappearing after cleanup:

python3 scripts/processon_archive_state.py mark \
  --plan <run-dir>/artifacts/archive-plan.json \
  --progress <run-dir>/artifacts/download-progress.json \
  --artifact-id <artifact-id> \
  --outcome blocked \
  --reason "XMind/POS/POSM 无文件落盘；Markdown 仅用于证明下载通道可用" \
  --evidence-file <diagnostic-export.md>

When same-directory same-name entries have no stable remote ID, the delivery directory must append a stable artifact_id(first 8 characters recommended), e.g. 未命名文件--8ba9f60f/; must not rely solely on browser auto-generated (1) filenames. At the end of each batch, run audit, and recheck the plan fingerprint, counts, delivery files, blocking evidence, SHA-256, and finalizer manifest:

python3 scripts/processon_archive_state.py audit \
  --plan <run-dir>/artifacts/archive-plan.json \
  --progress <run-dir>/artifacts/download-progress.json

3. analyze: parse, convert, or upgrade only after asking

After stage 2 completes an artifact, first ask the user whether to "archive only, extract structure, convert, or upgrade diagram". Do not automatically parse, modify the diagram, or open an editor without instructions.

User goal / file	Invocation route	Output and boundaries
Content inventory for POS, XMind, SVG, images, PDF	This skill's inspect_processon_export.py	only reads titles, node text, dimensions, checksums; thumbnail-level evidence cannot masquerade as structured original text
VSDX reading, conversion to draw.io, editable upgrade	soia-dev-drawio-visio-diagrams	first forward-validate VSDX, then convert to .drawio true source; any diagram upgrade must have a specific user goal
Only need to view the image	ProcessOn "Browse" view or export preview	Record DOM text, visual screenshots, or thumbnail evidence, and distinguish explicit text from layout inference

When the browser is unavailable, the account is not logged in, or a genuinely visible security verification is not completed, have the client manually export VSDX/POS/PNG/PDF/XMind, then continue from the local archive entry point in stage 2.

Local check script

scripts/inspect_processon_export.py：

• Supports a single file or directory (recursive).
• Parse POS metadata, flowchart elements, or mind map node text.
• Parse XMind's content.json / content.xml topic text.
• Read PNG/JPEG/GIF/WebP dimensions, SVG text, and viewBox。
• For PDF and other files, at least record size, extension, and SHA-256.
• Read-only by default; does not modify source files.

scripts/finalize_processon_download.py：

• Parse CLI, environment variables, private YAML, and cross-platform default paths.
• Initialize a temporary directory with a safety marker; refuse to claim a non-empty shared directory.
• Check first, then atomically copy; by default rename on same name; overwriting requires two explicit switches.
• Only allow --move and cleanup for managed temporary directories; generate a JSON manifest on success.
• The delivery directory and audit directory must not be placed inside the temporary directory.

scripts/processon_inventory_state.py：

• Initialize a separate JSON checkpoint, atomically save discovered_paths、visited_paths、blocked_paths and a per-directory file list.
• Each small browser batch is merged idempotently via record ; repeated recording of the same complete directory snapshot will not double-count files.
• record automatically refreshes handoff/progress.md; raw batches record both the semantic hash and the persisted file hash.
• status directly computes a recoverable pending = discovered - visited - blocked; after a session interruption, continue from pending_paths continue.
• audit validates SHA-256 batch by batch, reconstructs the checkpoint, and verifies run.json; a completion receipt is generated only when both the difference set and the blocked items are 0.
• Reject relative path traversal, symbolic link state files, and invalid schemas; state file permissions are 0600。

scripts/build_processon_archive_plan.py：

• Generate an asset archive plan from a persisted checkpoint, without accessing ProcessOn, reading credentials, or downloading files.
• Output a stable artifact_id, default export format, POS fallback policy, unknown confirmation queue, and same-name risk for each entry, and distinguish ready_for_known_artifacts from full ready_for_archive。
• Before archiving, verify the checkpoint SHA-256, entry contents, and stage flags to prevent continued use of an old plan after directory inventory updates or plan rewriting.

scripts/processon_archive_state.py：

• Initialize or resume the single-writer download queue from a verified archive plan, and refuse to merge old progress when the plan SHA-256 does not match.
• next provide the next batch of executable artifacts;record bind the actual file, finalizer manifest, size, and SHA-256 to a stable artifact_id;mark list failures and blockages separately.
• audit Replay completed evidence and recalculate counts; the progress file is written atomically with permissions 0600, and unknown types only enter the manual confirmation queue.

scripts/processon_browser_runner.py：

• Start the skill-specific Playwright profile from any AI host/ordinary terminal, without relying on Codex/Claude browser tools, and without attaching to the client's main Chrome.
• login is only responsible for manual login in an independent window;status、snapshot、run headless by default.
• The action contract only allows ProcessOn HTTPS navigation, named semantic click/hover, scroll, wait, controlled popup, and download; it rejects arbitrary CSS, unnamed controls, and remotely changed tags, and has no form filling, script execution, Cookie/Storage, or credential interfaces.
• On startup, close stale and extra pages of the dedicated profile; each popup is closed during finally , and the entire context is closed on all normal/abnormal exit paths and outputs a count receipt.

scripts/diff_processon_inventory.py：

• Perform a fail-closed local snapshot diff on two complete checkpoints, without accessing ProcessOn, reading credentials, or claiming event/API increments.
• Only when a stable remote_id/id exists, mark moves or renames; files without IDs are compared by safe fallback identity, and when a move cannot be confirmed, keep add/remove candidates.
• Reject incomplete, blocked, out-of-scope, and duplicate stable IDs; isolate duplicate ID-less identities as ambiguous_entries, removals only keep removed_candidates, and never drive remote or local deletion.

Verification

• Static:python3 -m py_compile scripts/inspect_processon_export.py scripts/finalize_processon_download.py scripts/processon_inventory_state.py scripts/build_processon_archive_plan.py scripts/processon_archive_state.py scripts/diff_processon_inventory.py scripts/processon_browser_runner.py
• Unit tests:python3 -m unittest tests.test_processon_downloads tests.test_processon_inventory_state tests.test_processon_archive_plan tests.test_processon_archive_state tests.test_processon_inventory_delta tests.test_processon_browser_runner -v, covering configuration priority, safe default paths, atomic copy, same-name rename, managed moves, directory and asset intermediate states, plan drift rejection, failure/blocked resume, full snapshot increment gating, as well as main Chrome profile rejection, sensitive action rejection, and normal/abnormal page closing.
• POS: run --format jsonwith one flowchart and one mind map POS, and confirm the title, category, node text, and element count.
• Images: run the script with PNG/JPEG, and confirm the width, height, and SHA-256.
• Archiving: run finalize --dry-run and finalizein sequence with real export files, and verify the delivered file SHA-256 and manifest; do not write fixture paths into public documents.
• Remote: verify at least once "open team space → read file list → right-click to see browse/download"; if security verification blocks export, the conclusion must be written as "remote read verified, full export pending manual verification before continuing".
• Non-interfering browser: use a temporary dedicated profile to run status/snapshot smoke; verify that the client's default Chrome is not in the process arguments, that stale pages started are cleaned up, and that after an abnormal action the context is fully closed. Real-account E2E must have the client complete one login first in an independent window; the main Chrome profile must not be copied.
• Recursive: use at least three levels of directories to verify the discovered/visited difference set is 0; after simulating a session interruption, resume from the persisted recovery point.
• Plan: run with a real checkpoint build and verify; after artificially modifying the checkpoint or a plan entry,verify must fail; when it contains unknown the plan must be marked pending confirmation, allowing phased download of confirmed types but must not claim full archive readiness.
• Download queue: for a real plan run init and next; after recording one real archive file run record and audit, confirming that after restart it will not claim repeatedly, counts can be recalculated, and auditing fails after modifying a file or plan.
• Incremental: run the diff using two complete audit checkpoints; modifying, moving, renaming, adding and removing candidates must be reproducible. After turning one of them into pending/blocked or injecting a duplicate stable ID, the command must fail; duplicate identityless entries must be isolated and must not produce spurious changes.
• VSDX: a real download or public sample passes ZIP/OOXML checks; when the optional draw.io skill is installed, run VSDX → .drawio → PNG forward verification once more.
• Structure: run the repository scripts/audit_skills.py --strict, the skill validator supporting this repository's version field, and git diff --check。