Skip to content
Agentmart
Submit a tool

ChiefLab

Open execution contract for agents doing business work.

Connector by bdentech · GitHub account verified by the MCP Registry

IndexedLicense unknownLocal (stdio)Remote (HTTP)
Write a review

Install

Works with Claude Code, VS Code, Codex, Cursor, Windsurf, Claude Desktop. Read the repository before you give any tool access to your data.

npx agentmarket install connector/bdentech-chieflab

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Remote endpoint

  • https://api.chieflab.io/api/mcp Remote (HTTP)

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

Open execution contract for agents doing business work. 6 operators, one MIT-licensed spec.

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this server can do and what it asks for, from its tool list and install config. Checked Oct 25, 2026.

Tools
15 read · 16 write · 0 delete · 14 not yet classified
Secrets
2 (API keys, tokens or passwords)
Install scripts
Not scanned yet
Runs as
Node.js package

Tools by what they do 45

From the running server's own tool list (tools/list) on Oct 25, 2026.

Read 15 · Look things up without changing anything.

  • chieflab_check_measurement_due
  • chieflab_connector_status
  • chieflab_get_capability
  • chieflab_get_company_profile
  • chieflab_get_publishing_targets
  • chieflab_get_users_after_build
  • chieflab_list_specialists
  • chieflab_measure_hacker_news
  • chieflab_measure_reddit
  • chieflab_persistence_health
  • chieflab_query_proof_ledger
  • chieflab_review_visual_asset
Show 3 more tools
  • chieflab_search_capabilities
  • chieflab_status
  • chieflab_suggest_next_move

Write 16 · Create, change, send or run things.

  • chieflab_approve_action
  • chieflab_create_next_move_action
  • chieflab_create_work_request
  • chieflab_execute_approved_action
  • chieflab_mark_action_done
  • chieflab_post_launch_review
  • chieflab_prepare_next_move
  • chieflab_publish_approved_post
  • chieflab_record_manual_metrics
  • chieflab_record_manual_publish
  • chieflab_retry_blocked_action
  • chieflab_send_approved_email
Show 4 more tools
  • chieflab_set_company_profile
  • chieflab_set_provider_key
  • chieflab_set_publishing_targets
  • chieflab_skip_next_move

Not yet classified 14 · We could not tell from the name and description.

  • chieflab_boot
  • chieflab_brain_summary
  • chieflab_connect_provider
  • chieflab_continue_launch_loop
  • chieflab_force_measurement_due
  • chieflab_help
  • chieflab_inbox
  • chieflab_launch_product
  • chieflab_redraft
  • chieflab_regenerate_visual_asset
  • chieflab_request_specialist
  • chieflab_signup_workspace
Show 2 more tools
  • chieflab_use_manual_fallback
  • chieflab_verify_install

Secrets and settings it asks for

Secrets: values you paste in that let it act as you.

  • Authorization
  • CHIEFLAB_API_KEY

Network hosts it talks to 1

  • api.chieflab.io · found in remote endpoint, install command

Files it touches

  • Any path the agent passes to its tools

Tools (45)

As the server listed them on Oct 25, 2026. Descriptions are the server’s own words; hidden characters are shown as [U+…].

  • chieflab_approve_action

    [chieflab_* alias of chiefmo_approve_action] Approve one ChiefMO publish/send action so its executor can fire. USE WHEN the user — in IDE chat — said 'approve <channel>' (e.g. 'approve linkedin', 'approve hn'), 'approve all', 'ship it', 'go ahead', or otherwise greenlit a specific draft you rendered. Match the user's words to the channel, look up agentGuide.renderInChat[channel].actionId from the launch response, and call this tool with that actionId. This is the IDE-native approval path — no need to push the user to the reviewUrl. Pass `actionId` (preferred) or `id` (legacy alias). P74: pass …

  • chieflab_boot

    Alias of chieflab_status. Use as the FIRST tool when an agent session starts on a workspace that already has activity — recovers all open business loops with literal user commands. Same response shape as chieflab_status, same handler. If the user asked to launch the current repo and a recovered open loop looks unrelated, do not blindly resume it; start a fresh launch for the current repo.

  • chieflab_brain_summary

    USE WHEN the user asks 'what do you remember about my brand?' / 'show me my brain' / 'what have you learned?'. Returns a plain-English paragraph summarizing what the per-workspace brain has accumulated: launch count, top-performing channels, brand voice patterns from approved drafts, what's been rejected and why, channel-specific performance, recent proof points. The moat made visible. Pair with chieflab_brain_read for the raw structured data.

  • chieflab_check_measurement_due

    P71 — measurement queue inspector. USE WHEN the agent wants to know which executed actions are ready for their 24h readback (regardless of how they were executed — native connector OR manual paste). Lists actions where metadata.proof.measurementDueAt <= now AND metadata.proof.measuredAt is unset. Returns: [{actionId, runId, channel, executedAt, measurementDueAt, artifactUrl, executionStatus, recommendedNextTool}]. Pairs with chiefmo_post_launch_review which the cron also calls automatically; this tool surfaces the same queue to a foreground agent so it can opportunistically pull metrics during…

  • chieflab_connect_provider

    Connect a third-party provider (Zernio, Resend, GA4, Search Console, HubSpot, Stripe, Linear, Notion, Slack) to this workspace. USE WHEN the user wants to wire up publishing, email sending, or analytics readback. For OAuth providers (ga4 / search_console / hubspot) returns an authorizeUrl the agent surfaces to the user. For API-key providers (zernio / resend) returns instructions for the set-key tool. Without this, publish/send/measure tools return 'configure first' errors.

  • chieflab_connector_status

    USE WHEN the user just completed a connector OAuth flow and you want to confirm it succeeded — 'did my connection work?', 'is my Zernio/HubSpot/Stripe connected?'. Returns status: pending | connected | failed for the given connectionId.

  • chieflab_continue_launch_loop

    [chieflab_* alias of chiefmo_continue_launch_loop] Resume a ChiefLab launch loop from runId. USE WHEN an agent has already called chieflab_get_users_after_build / chiefmo_launch_product and needs the exact next action: surface reviewUrl, execute an approved action, wait for measurement, measure results, or prepare the next move. Default response is summary-sized: reviewUrl + action ids, not full draft bodies. Pass responseShape:"full" only for debug/export.

  • chieflab_create_next_move_action

    P75 — turn a Next Move suggestion into an approval-gated draft action. USE WHEN you've called chieflab_suggest_next_move and the suggestion's kind is not 'wait' or 'noop'. Creates an actionStore entry with status='awaiting_approval', the suggested draft body inline, and an executionMatrix that points at the right next-execution path. The reviewer sees the new card in the Launch Room / IDE chat like any other approval card — same approve / revise / reject flow. Closes the loop: launch → measure → next move → approve → execute → repeat.

  • chieflab_create_work_request

    USE WHEN your operator hits a gap it can't fulfill itself and wants to route the work to another operator — 'I need a demo video for this launch', 'request design help for the hero image'. Creates an open work request that other operators can offer against. Once an offer is submitted, the requester (or their human) reviews + accepts via chieflab_accept_offer (which then creates an approval-gated action for the spend).

  • chieflab_execute_approved_action

    P71 — closed-loop executor wrapper. USE WHEN chiefmo_approve_action just succeeded on an action whose executionMatrix.mode is oauth_connector or api_key_connector AND connectorReady is true. Routes to the right native executor (chiefmo_publish_approved_post for social / chiefmo_send_approved_email for email), runs the execute-time sanity gate (re-classifies the action's stored body to catch DEGRADED MODE / clarification / refusal text that slipped through draft-time classification), captures the executor's result, writes a standardized metadata.proof shape ({executedAt, artifactUrl, artifactId…

  • chieflab_force_measurement_due

    P93 — admin escape hatch. Forces a proof_ledger row's measurement_due_at into the past so the cron's next tick picks it up. USE WHEN smoke testing the launch → measure → next-move chain without waiting 24h, OR an ops user needs to retry a stuck measurement. Gated by CHIEFLAB_ADMIN_TOKEN header (same gate as /api-keys/issue). Refuses if the row is already measured. Pass `dueAt` (ISO string) to set a specific time; defaults to now - 60s.

  • chieflab_get_capability

    USE WHEN you have a specific operatorId + capability and want the full machine-readable profile (inputs, outputs, pricing, approval-required flag, endpoint). Pre-flight check before chieflab_create_work_request.

  • chieflab_get_company_profile

    P88 — read the workspace's stored company profile. Returns { profile, source, confidence, updated_at }. Use before launch to confirm what ChiefLab will ground in.

  • chieflab_get_publishing_targets

    P79 — read the workspace's stored publishing target defaults. Returns { channelTargets, store }. Useful before launch so the agent can surface 'You haven't connected an Instagram account yet — set it via chieflab_set_publishing_targets' instead of blocking on first auto-execute.

  • chieflab_get_users_after_build

    Outcome-named alias for chiefmo_launch_product. USE WHEN a coding agent just built, shipped, or deployed something and the user asks 'get users', 'find customers', 'make money from this', 'get paying users', 'get eyes on this', 'what now?', or 'how do I launch this?' This is the agent-dependency tool: after build, call this to turn the product into a repo-grounded money/distribution loop with launchPack, signed reviewUrl, approval-gated publish/send actions, 24h measurement, memory, next move, moneyLoop, and agentDependency. Gather repoContext first. Route exactly like chiefmo_launch_product; …

Show 30 more tools
  • chieflab_help

    FIRST TOOL — call before anything else when you don't know what ChiefLab does or where to start. Returns the operator menu + workspace state (connectors wired, last run, signup status) + the single next action for this workspace. Cheap, no side effects. After this, call chieflab_launch_product for a full launch or chieflab_post for a single channel.

  • chieflab_inbox

    USE WHEN the user asks 'what came in from my launches?' / 'show me my replies' / 'what's in my inbox?' / 'who responded to the LinkedIn post?'. Returns engagement events for THIS workspace, ordered by recency. Filter by status (new / drafted / approved / sent / dismissed) — default new. Pair with chieflab_draft_reply to handle them.

  • chieflab_launch_product

    Operator: chieflab-launch (primary). Spec v0.1 reference implementation of the orchestrator. End-to-end launch loop: repo-grounded positioning + per-channel drafts (linkedin, x, hn, reddit, email, landing_hero, product_hunt) + image briefs + approval-gated publishActions + signed reviewUrl + 24h measurement queue. Internally composes chieflab-post + chieflab-email under one runId. Spec-renamed alias of chiefmo_launch_product (backwards-compat retained).

  • chieflab_list_specialists

    P87 — list the specialist agents ChiefLab can delegate to (design / video / research / outreach / seo / analytics). USE WHEN the user asks 'what can ChiefLab do beyond launch posts?' or before calling chieflab_request_specialist. Returns the kind + label for each so the caller can pick the right one.

  • chieflab_mark_action_done

    P135 — mark a next-move action as completed when the founder has done the move BUT there's no URL to record (e.g. reply_to_commenters, dm_engagers, mark replies done). Flips the action to executed with metadata.markedManuallyAt + metadata.executedManually=true. The next-move card disappears from /command/'s Today's Loop. For moves that DO have a URL (cross-post, new post), use chieflab_record_manual_publish instead — it both records the URL and marks executed.

  • chieflab_measure_hacker_news

    P109 — pull a Hacker News post's score + comments + top replies via the public HN API and write them to the action's metadata.proof. USE WHEN a published Hacker News action is ripe for 24h measurement (checks the publishedUrl on the action, parses the item id, calls the Firebase API). Auto-creates a next-move action based on the outcome (trending → reply + cross-post; engaged → reply; stalled → rewrite angle). Idempotent — second call returns the existing measurement. No API key required; HN is public-read.

  • chieflab_measure_reddit

    P115 — pull a Reddit post's score + comments + upvote ratio + top replies via the public Reddit JSON API and write them to the action's metadata.proof. USE WHEN a published Reddit action is ripe for 24h measurement. Parses subreddit + post id from the publishedUrl, calls https://www.reddit.com/r/<sub>/comments/<id>.json (no auth), auto-creates next-move actions based on the outcome (trending → reply + cross-post; engaged → reply; downvoted → rewrite angle). Idempotent — second call returns existing measurement unless force:true.

  • chieflab_persistence_health

    P91 — verify the persistent stores. Probes proof_ledger / publishing_targets / company_profiles tables (Supabase) OR confirms the in-memory fallback. USE WHEN the user just ran the SQL migrations and wants to confirm the API is now using durable storage; OR before a real founder launch to make sure data won't evaporate on cold start; OR when debugging why a previously-stored target / profile disappeared. Returns per-store: { kind: 'supabase'|'in_memory', durable: bool, tableExists?: bool, sampleQueryOk: bool, rowCount?: number, error?, warning? }. The 'tableExists: false' case means the SQL mi…

  • chieflab_post_launch_review

    [chieflab_* alias of chiefmo_post_launch_review] USE WHEN ≥24h has passed since chiefmo_publish_approved_post fired and the user asks 'how did the launch perform?', 'what worked?', 'metrics from my launch'. Closes the loop: pulls 24h+ engagement (likes / comments / views / shares / follower delta) for posts in the launch run + recommends next iteration (rewrite, refresh creative, double down, pause). Returns per-account analytics + top posts + best-time-to-post + a structured next-move recommendation brief.

  • chieflab_prepare_next_move

    [chieflab_* alias of chiefmo_prepare_next_move] USE WHEN the user has just published a launch (or ≥24h post-launch) and asks 'what's next?', 'follow-up post?', 'iterate on this', 'plan day 2'. P13 — turns one launch into a 7-day launch mode: drafts a queue of follow-up actions (day 2 reply post, day 3 case study, day 5 metrics share, day 7 retrospective) grounded in the prior launch's runId, the per-tenant brand voice + repo facts + channel performance from the P9 company brain, and the prior recommendation (so the next move doesn't repeat the last one). Returns a draft queue + signed reviewUr…

  • chieflab_publish_approved_post

    [chieflab_* alias of chiefmo_publish_approved_post] Publish an approved social post (LinkedIn / X / Threads / Instagram / Facebook / Bluesky / TikTok) through the social publishing rail (current adapter: zernio). USE WHEN the user has approved a publishAction from chiefmo_launch_product on the reviewUrl and you need to fire the post. Strict approval gate: returns { reason: 'requires_approval', reviewUrl } if the action isn't approved yet. Once executed, returns the live platform post URL. Money/external-system action — never call this without an approved actionId.

  • chieflab_query_proof_ledger

    P80 — query the persistent proof ledger. USE WHEN the user (or a dashboard) asks 'what has ChiefLab actually shipped for this workspace?' or 'show me the launch history.' Returns the proof rows for executed publishes / sends / manual-posts with the artifact URLs, channels, execution modes, and measurement state. Persistent across cold starts when deps.proofLedgerStore is wired to Supabase; falls back to in-memory (warm function lifetime) otherwise.

  • chieflab_record_manual_metrics

    P116 — paste-what-you-see metric fallback for channels without public-API measurement (X, LinkedIn, Email, landing pages, Product Hunt). USE WHEN a published action's channel doesn't have a public-JSON metrics endpoint (anything except hacker_news / reddit) AND the founder is ready to paste the visible numbers. Reads metadata.proof.artifactUrl to confirm the post is recorded, writes the provided metrics into metadata.proof.metrics + measuredAt, auto-classifies the outcome (channel-specific thresholds: X needs likes/replies, LinkedIn needs reactions/comments, Email needs opens/clicks/replies, e…

  • chieflab_record_manual_publish

    USE WHEN the user has manually posted to a channel returned by chieflab_use_manual_fallback (Product Hunt / HN / Reddit / Discord / etc.) and wants to feed the live URL back to ChiefLab so the closed loop continues. Records the URL on the original publishAction (status flips from 'approved' to 'executed' with metadata.executedManually=true + metadata.publishedUrl), persists a proof_asset to the P9 company brain, and queues 24-hour metrics readback via chiefmo_post_launch_review. Without this tool, manually-posted channels are lost to ChiefLab's measurement loop.

  • chieflab_redraft

    USE WHEN the user says 'make this more casual' / 'shorter' / 'less salesy' / 'add a specific number' / 'redraft this' about a published draft. Pulls the existing brief for the actionId, merges the instruction, returns an updated brief your LLM should render. After rendering call chieflab_record_rendered_copy({ assetId, body }) to commit. Multi-turn flow stays coherent: each redraft increments action.metadata.revision; original brief preserved in metadata.history.

  • chieflab_regenerate_visual_asset

    P72 — regenerate a single visual asset (LinkedIn graphic, X graphic, landing hero, etc.) with a different style / fidelity / headline / model. USE WHEN a reviewer hits 'Regenerate' on a launch image in the Launch Room. Reads the original launch's brief from the run metadata, calls produceVisualAsset with the new parameters, and returns the updated asset shape (assetId, dataUrl, dimensions, prompt, mode). Does NOT auto-persist back to the run — caller decides whether to swap the asset in place (via runStore) or treat the regen as a parallel candidate.

  • chieflab_request_specialist

    P87 — delegate to a specialist agent. USE WHEN the launch needs more than copy: a graphic brief (kind='design'), a demo video shot list (kind='video'), a prospective-customer research plan (kind='research'), personalized outreach drafts (kind='outreach'), landing-page SEO recommendations (kind='seo'), or a verdict + recommended next move from measurement data (kind='analytics'). Specialists are deterministic stubs today — they return structured briefs / plans / drafts the founder can act on immediately. Future LLM-backed implementations swap in transparently. Each request creates an approval-g…

  • chieflab_retry_blocked_action

    P13 — re-check a blocked publishAction's connector readiness. Returns whether the channel is now ready (so the agent can re-fire chiefmo_publish_approved_post / chiefmo_send_approved_email) or still blocked with the up-to-date connect path. USE WHEN the user has just connected a missing provider and the agent needs to know if the action can fire.

  • chieflab_review_visual_asset

    P104 — approve or reject a single visual asset (LinkedIn graphic / X image / landing hero / Product Hunt gallery / carousel slide). USE WHEN a reviewer hits 'Approve' or 'Reject' on a launch image in the Launch Room. Reads the run's stored visualAssets list, updates the matching asset's status (approved | rejected | pending_approval), persists the change to run metadata so future loads + the channel-media render reflect the decision. Companion to chieflab_regenerate_visual_asset (which produces an updated asset shape without persisting).

  • chieflab_search_capabilities

    USE WHEN your operator needs a capability outside its own scope and wants to find another operator that can fulfill it — 'find me a demo-video capability', 'who can do SEO audits', 'search for design help'. Returns active capability records ranked by recency. Pair with chieflab_create_work_request to actually request bounded work from the chosen operator. The discovery embryo for an agent-native marketplace.

  • chieflab_send_approved_email

    [chieflab_* alias of chiefmo_send_approved_email] Send an approved launch email through the email sending rail (current adapter: resend). USE WHEN the user has approved an email publishAction from chiefmo_launch_product and you need to fire the send. Strict approval gate (same shape as chiefmo_publish_approved_post). `from` MUST be on a domain verified at the adapter (resend.com) — check chieflab_list_email_senders first. Single recipient or short list (≤50). Money/external-system action — once sent cannot be unsent.

  • chieflab_set_company_profile

    P88 — set the workspace's persistent company profile. ChiefLab's pre-P88 brief pipeline was repo-first; without a repo, launches landed thin. P88 lets the founder (or an agent) store the company / product facts ONCE and every subsequent launch grounds in them, even URL-only / paste-description launches. Pass partial maps to update specific fields; pass null for a field to remove it. Profile fields the brief consumes: companyName, productName, offer, audience, market, positioning, services[], productType, brandColors {primary, accent, bg, text}, websiteUrl, contactEmail, socialLinks[], keyClaim…

  • chieflab_set_provider_key

    Store a provider API key for THIS workspace. Once stored, ChiefLab uses your key (BYOK — you pay the provider directly, no markup). Without it, ChiefLab uses its own key and bills through with a margin. Providers: gemini (image gen), resend (email), zernio (social publish), anthropic (LLM, future), openai (LLM, future). Stored encrypted at rest. Use chieflab_revoke_provider_key to remove. The key never leaves this workspace.

  • chieflab_set_publishing_targets

    P79 — set per-workspace publishing target defaults so chiefmo_approve_action({ autoExecute: true }) doesn't need the agent to pass platform / recipient ids on every call. One-time setup per workspace. channelTargets is a map { linkedin: { accountId }, x: { accountId }, email: { fromEmail, recipientListId } }. Pass partial maps to update specific channels; pass `null` for a channel value to remove it. Persisted via deps.publishingTargetsStore when wired, otherwise in-process Map (Vercel function lifetime). Returns the merged channelTargets + storage location ('persistent' or 'in_memory').

  • chieflab_signup_workspace

    USE WHEN the user has no ChiefLab API key yet and you've gotten a 401 / 'authentication required' error from any other tool. Agent-first signup: creates a new workspace and returns the API key inline as `apiKey`. PREFERRED flow: use your filesystem tools to write the apiKey into the user's MCP config (see mcpConfigSnippet for the patch shape), then ask the user to restart their runtime once. After restart, re-call the original tool. FALLBACK: if you can't write to the config file, surface the included deliveryUrl to the user — they click, see the key, paste it manually. URL expires in 1 hour, …

  • chieflab_skip_next_move

    P142 — founder rejects a next-move recommendation without doing it. Captures a reason so the brain learns which kinds of moves don't fit this workspace (e.g. 'we don't cross-post to Reddit on principle' / 'we tried DMs already'). Flips action to rejected with metadata.skipReason. The next-move generator reads recent skip reasons before suggesting moves of the same kind on this workspace.

  • chieflab_status

    SESSION-RECOVERY · FIRST CALL when a session starts and the user mentions launch / users / growth / customers / metrics / revenue / marketing / what next / shipping. Returns a command-center bootCard with `headline`, `priority`, `cards[]` (each carries kind + label + literal user command + runHandle), and `next` (the one-line prompt). Aggregates: pending approvals + ripe measurements + new engagement + queued prospects + recent launches + manual-publish-pending actions. ChiefLab is stateful and re-summonable — even if the conversation was lost, the IDE was switched, or the runId was forgotten,…

  • chieflab_suggest_next_move

    P75 — Next Move Engine. USE WHEN measurement just came in (chiefmo_post_launch_review fired automatically at 24h, OR the user manually called it) and you want to know what the operator should do next. Reads metrics + the original launch's brief and emits a deterministic suggestion: {kind: 'follow_up_email' | 'founder_dm' | 'thread_reframe' | 'landing_iteration' | 'lessons_learned_post' | 'seo_title_test' | 'wait' | 'noop', priority, reasoning, draftBrief: {channel, headline, body, cta?, recipients?}, measurementGroundingFacts}. Pure-function; same input → same output, no LLM. Pair with chiefla…

  • chieflab_use_manual_fallback

    USE WHEN any launch action carries a manualFallback brief — either because the channel has no automated provider at all (Product Hunt, Hacker News, Reddit, Discord, Slack, Indie Hackers, dev.to, YC Bookface, blog) OR because the channel HAS an automated provider but its connector isn't wired yet for this workspace (LinkedIn / X without a Zernio key; email without a Resend key + verified sender domain). Pattern: use the inline fallback NOW to ship the launch manually; connect the provider LATER (each fallback returns an upgradePath with the exact connector wiring) so the same action publishes a…

  • chieflab_verify_install

    POST-INSTALL HEALTH CHECK. Call this exactly once after the agent has wired ChiefLab into the runtime (per the bootstrap protocol at https://chieflab.io/bootstrap.txt). Returns { ok, mcpReachable, toolsDiscovered, visibleFrontDoorTools, callableInternalTools, workspaceReady, hasOpenLoops, blockedConnectors, summary }. `toolsDiscovered` means the visible front-door catalog, not every internal/back-compat callable handler. The `summary` is one sentence the agent should paste verbatim to the user — e.g. 'ChiefLab installed and ready. Workspace fresh, no open loops, all channels need connectors be…

Signals

Weekly downloads
9
Last release
May 12, 2026 (5 months ago)
Last package publish
May 11, 2026 (5 months ago)
Repository
Not found on GitHub (deleted or private)

From the package registry.

Details

Registry name
io.github.bdentech/chieflab
Version
0.3.0
Auth
Bearer token, API key
License
License unknown
First seen
Oct 24, 2026
Last checked
Oct 25, 2026
Cite this page

ChiefLab MCP server. Agent Mart. https://agentmart.dev/connectors/bdentech-chieflab (last updated 2026-10-25)