DEV Community: Moclaw | AI Personal Computer

A task feed should distinguish a reference from a result

Moclaw | AI Personal Computer — Tue, 13 Oct 2026 03:45:06 +0000

When a task library exposes an API, downstream readers can lose qualifications that were obvious on the original page. A title such as “Prepare a school supply cart” can become a capability claim if the consuming application drops the source and evidence label.

I maintain Muse Task Hub, an independent, unofficial guide. Its public feed is at the /api/tasks path on the guide’s domain. The records include taskId, title, summary, category, evidenceType, url, sources, version, contentVersion, publishedAt, modifiedAt and withdrawn. The response envelope includes the snapshot identifier and pagination cursor.

Those fields do different jobs. The task ID identifies a record. The page URL points to the fuller explanation. The source URLs identify the material behind it. The evidence type distinguishes a community report from a product-maker example. Version and modification metadata help a consumer recognize updates. The withdrawn flag should not be discarded merely because an old title remains recognizable.

A reader interface should keep the title, source class and qualification together. It should link to the guide page for context and to the original source for verification. It should never relabel an official example as an independently verified outcome.

The October 10 snapshot contains 279 unique records collected across 14 paginated responses. Four records are labeled official and 275 are user reports. This distribution says something about the collection's provenance. It says nothing about how often an assistant succeeds or which task category is most popular among all users.

For a local consumer, a useful starting point is to filter withdrawn records, show the source class, and make the task-page link available:

import json
from pathlib import Path

snapshot = json.loads(Path("tasks.json").read_text())
for task in snapshot["items"]:
    if task.get("withdrawn"):
        continue
    print(task["title"])
    print("Evidence:", task["evidenceType"])
    print("Context:", task["url"])
    print("Sources:", task["sources"])

The dated export is available at https://github.com/1021ju/muse-task-hub. It is reference metadata, not a benchmark dataset. The guide has not independently reproduced the examples and is not affiliated with Meta. Third-party source rights remain with their owners; the repository does not assert a blanket license over them.

Exporting a paginated task feed without losing provenance

Moclaw | AI Personal Computer — Tue, 13 Oct 2026 03:44:06 +0000

A JSON endpoint is easy to download. A complete, attributable snapshot takes a little more care.

I maintain Instinct Tasks, an independent, unofficial guide. Its public /api/tasks endpoint returns an envelope containing protocolVersion, snapshot, items, nextCursor and checkpoint. In the October 10 export, the first response contained 20 items. Treating that response as the whole library would have missed most of the 128 records.

The export therefore follows nextCursor until it is empty. Every response must have the same snapshot identifier. If that identifier changes, the export should stop and be investigated or restarted rather than silently mixing versions.

There are three useful integrity checks after pagination:

Task IDs are unique across the collected responses.
Each task URL belongs to the expected guide domain.
Each record retains its source URLs and evidence type.

The first check catches duplicate pages. The second catches a wrong-domain export. The third preserves the distinction between a community report and an example published by the product maker. None of these checks proves that the underlying task works; they verify the structure and provenance of the export.

Here is a small local inspection of the completed snapshot:

import json
from collections import Counter
from pathlib import Path

snapshot = json.loads(Path("tasks.json").read_text())
tasks = snapshot["items"]
assert len(tasks) == len({task["taskId"] for task in tasks})
print(Counter(task["evidenceType"] for task in tasks))
for task in tasks:
    print(task["title"], task["url"], task["sources"])

For this export, the evidence labels were 124 user reports and four official examples. They are counts of published records, not trial results or adoption statistics.

The snapshot also records its retrieval time, original endpoint and snapshot ID. A checksum in the README identifies the exact file. That makes it possible to discuss a fixed version even as the website changes.

The resulting reference repository is https://github.com/1021ju/instinct-tasks. It contains published metadata, not private tasks or execution logs. Source links are retained, and no blanket open-source license is asserted for third-party materials. The guide is not affiliated with Instinct and has not independently reproduced the source examples.

What Should an AI Personal Computer Actually Do?

Moclaw | AI Personal Computer — Tue, 30 Jun 2026 08:11:48 +0000

AI agents are often described as tools that can browse the web, use apps, and complete tasks on behalf of users. But in practice, many agent products still feel like chatbots with extra steps.

A useful AI personal computer should do more than answer questions. It should help users move across websites, understand context, complete repetitive workflows, and turn open-ended goals into concrete actions.

For example, instead of only asking an AI model to summarize information, a user may want an agent to research a topic, compare sources, organize findings, and prepare the next step. Instead of manually switching between tabs and tools, the user should be able to describe the task and let the agent handle the workflow.

At Moclaw, we are exploring this direction: a general AI agent and AI personal computer for browsing, research, automation, and daily web tasks.

The bigger question is not whether AI agents can click buttons or fill forms. The real question is whether they can become a reliable interface for everyday computer work.

That is the part we are most interested in building.