Repository discovery#

The checkout is resolved before the viewer asks for anything: a saved path, then WELES_REPOSITORY_PATH, then WISENT_WORKSPACE_ROOT, the working directory, the conventional ~/Documents/CodingProjects/Wisent workspace, and the app bundle's own ancestors, each candidate and its weles/ child. A folder picker costs a macOS consent prompt to read a directory the app can already name, so it is the fallback rather than the first run.

A directory qualifies only when it contains a readable package.json with "name": "weles" and a real src/ directory. This prevents accidental selection of arbitrary folders but does not establish repository provenance or trust; verify the checkout remote and revision through normal source-control procedures.

Existing-data import#

The first launch opens Setup until the operator either completes an accepted import or chooses Skip for now; Setup remains in the sidebar for reuse. Choose the exact Weles trajectory API JSON export and the execution host in the sidebar, then select Import existing data. The app sends the document to the deployment's authenticated POST /api/v1/imports endpoint; it does not parse a second trajectory format or invoke a shell command.

The endpoint accepts the list envelope returned by GET /api/v1/trajectories or one bare trajectory returned by its detail route. It preserves destination rows, rejects credential-shaped data and unsupported fields, and returns per-item imported, unchanged or refused state. Accepted rows are drafts. A session_label is only a reference to state already owned by the selected host; no browser profile or cookies cross the API. The data import guide covers the same contract from the API side.

Managed run admission#

In Runs, choose Start run, enter an allowed Weles action and a JSON object of parameters, then submit. The app sends an authenticated worker POST /run request and shows the admitted run identifier, or the worker's HTTP refusal and body; malformed parameters are refused locally with the JSON parser's cause. Refresh Runs to inspect the terminal result and recordings. The Runs page gives each action's request shape, refusals and real journey.

Meta Marketing API actions are meta_ads_api_campaign, meta_ads_api_catalog, meta_ads_api_audience, meta_ads_api_creative and meta_ads_api_lead_form. State action and, where applicable, resource in the parameters; a missing choice never creates an object. A write also needs submit: true; an ad campaign's initial status, objective and special-ad categories are the advertiser's choices.

A Google Ads campaign is google_ads_campaign with customer_id, campaign_name, campaign_objective and campaign_type, and the exact Google account ID chosen in the launch sheet. An App type also requires app_campaign_subtype; app_platform is optional and never inferred from the Google provider. The worker refuses missing choices before starting a browser. Without submit: true it reaches the provider form without publishing; a staged message is not proof of a saved draft.

A Play Console release is google_play_submit with bundle_path (accessible on the worker), package_name or play_release_url, and an explicit track (internal, closed, open or production). Without submit: true, Weles advances the upload but does not press a rollout or review button. The run result distinguishes a staged control sequence from a provider-observed rollout status. A missing or unsupported track is refused before the browser opens.

GitHub publishing is github_create_repo with repo_name and repo_desc, or github_commit with repo_url, file_path, commit_message and file_append. The repository name and public description are not generated, and the appended text is sent as given; include its newline in the parameter when needed. The worker refuses missing inputs before opening a browser, and the commit refuses an absent or mismatched message field before confirmation.

An Overleaf project linked to GitHub is overleaf_push_github with project, repo_slug and the exact commit_message the repository should record. The worker refuses an absent message before opening a browser and refuses a commit dialog that does not hold it. A settled Overleaf dialog is not independent proof that GitHub received a commit.

A reviewed registration action such as producthunt_register or threads_register uses the same worker admission and terminal run result as the CLI trajectory on the dedicated host. Product Hunt requires the authenticated page's own handle; both linked registrations require the source Skarbiec row's email, credential-field password and session. An incomplete source refuses before provider account creation. A failed account write or link is a failed run, not PASS. If session capture fails after account creation, the credential remains saved with session_unreadable and its cause, but no reusable cookie minting claim. This Mac does not read the worker's vault or launch its browser.

A Pingproxies purchase is pingproxies_topup with topup_usd set to the chosen numeric USD amount and topup_confirm set to true. The managed worker supplies the dedicated purchase-card secret; do not put card data in the parameters. Runs shows the trajectory's named amount, card-selection and Stripe-response refusals with its nonzero terminal status and recording. PASS-CHARGED means one Stripe payment intent reported success for the requested USD amount; it does not prove wallet credit. Reconcile an unconfirmed outcome before another charge, and read the provider balance separately.

A character profile edit is linkedin_edit_profile, twitter_edit_profile, instagram_edit_profile, reddit_edit_profile or tiktok_edit_profile, with the exact isolated Skarbiec account ID in the account field and an empty parameters object. Runs sends account_id to the worker, which binds the trajectory to that account; another inherited account binding is refused with both identities. A stated name, bio, headline or avatar whose provider control is missing or whose input and readback differ is a failed run, not a profile update. An unstated name leaves the provider and Skarbiec display name unchanged.

An Apple Ads report is apple_ads_report_harvest with the exact Apple Skarbiec account ID and JSON parameters apple_ads_app_id, apple_ads_date_presets and apple_ads_exact_ranges (comma-separated label=YYYY-MM-DD..YYYY-MM-DD). The managed worker runs the same read-only harvest as the dedicated-host CLI and closes its browser on completion. The inspector shows the action's recorded output as written in the run result, its scalar members as fields and its nested members as outlines you expand. HTTP or GraphQL refusal, unreadable JSON, missing campaign rows or a missing request template fail with the range and observed cause; no absent spend or installs becomes zero, and currency is only Apple's stated currency.

Every managed run's inspector reads its terminal result the same way: a read that failed, the run's refusal, a result that does not state whether the run succeeded, each action's recorded output under the action's name, and the worker's output. No action's output is decoded by a type of its own, so a new action's outputs appear without a Desktop change. tests/worker/RunAdmission.swift admits a real read on the managed worker, checks its terminal result against an independently named campaign and retains the exact worker and Desktop revisions in .build/worker-run-admission/.

Service observations#

The agent label is discovered rather than assumed, and registration alone is not reported as healthy: an agent that respawns and exits keeps its registration while doing no work, so a non-zero last exit code is surfaced with the run count that produced it.

An absent ~/Library/LaunchAgents folder, or one where no agent names the worker, reads as No launchd agent on this Mac runs this checkout's worker. When the folder exists but cannot be listed, or an agent file in it cannot be read or parsed and no readable agent names the worker, the status is attention with The launchd agents cannot be read: followed by the folder's error or each unreadable file and its cause; the worker's agent may be one of them, so it is not reported as missing.

The recording store is read where WELES_RECORDINGS_ROOT points; no folder of the checkout stands in for it. When nothing states it, or the folder cannot be listed, the Recording store observation is unavailable with Cannot be read: and that cause, never a count of zero runs. Every run folder and every file in it is read, with no limit on how many. A run folder, action folder or file that cannot be read is listed on that run in the Runs inspector as Not read with its path and the operating system's answer, and the Recording store observation counts the runs that could not be read in full. Artifacts are named by their path inside the run.

Repository contracts: package.json, the local package is readable.
Worker build: dist/worker/poll.js, the compiled entrypoint file is present.
Worker LaunchAgent: the ~/Library/LaunchAgents entry whose ProgramArguments name this checkout's worker, read through launchctl print, with its registration, run state, run count and last exit code.
Recording store: WELES_RECORDINGS_ROOT, as the worker's LaunchAgent states it or else this app's environment; every run folder under it, each listed whole.
Managed run activity: stado host weles-activity <host> --json, with identifiers, verdicts, timestamps, artifact counts and sizes.
Keeper sessions: ~/.weles/keeper/, local session and socket metadata.

Artifact inventory#

The local loader recognizes session metadata, network captures, diagnostics, fingerprint, ban and captcha reports, screenshots, videos, page captures, logs and instrumentation by known names and extensions. For managed hosts, Stado supplies aggregate classes and byte totals without exposing individual files or bodies.

Three reads name an unreadable file instead of showing it as absent: a ban_signal.json that cannot be read or is not a JSON object gives the run an attention result Result cannot be read: <cause>; a placement-policy.json that exists but cannot be read is shown as an invalid policy Weles placement policy <path> cannot be read: <cause>, and only a missing file reads as unavailable; an ~/.weles/onboarding directory, events.json or progress receipt that cannot be read turns the Receipt evidence row to attention with Cannot be read: <path>: <cause>, and only a missing directory reads as no verified receipt.