#Dungeon Ranker: Web Agent Workflow

Updated 13 October 2026 · Hong Kong time

Dungeon Ranker connects the owner's objectives, agent execution, and durable project knowledge. Commander coordinates work, project sessions carry it out, and tasks and documents make progress inspectable. The system supports long-running objectives without requiring every turn to repeat the entire project history.

#How work moves through the workspace

flowchart TD
    O["Owner: objective and constraints"] --> C["Commander: coordinate tasks"]
    C --> S["Project session: Claude or Codex"]
    P["Project profile and relevant skills"] --> S
    K["Shared state, knowledge and documents"] <--> S
    S <--> R["Local runner: code, tools and artifacts"]
    R --> V["Inspect results and verify evidence"]
    V -->|Revise when needed| S
    V --> D["Update the canonical deliverable"]
    D --> K
    D --> H["Handoff, publish or deploy within authorization"]

The retrieve–execute–verify cycle repeats as the objective requires. Owner review is available throughout; it is not a mandatory permission gate for every tool call.

A project groups related sessions, tasks, documents and knowledge. Its brief should identify the intended outcome, constraints and authoritative working locations. The runner's default project folder is not necessarily the actual repository checkout; agents establish the correct location before editing.

Commander can turn a substantial request into a task with observable completion criteria and coordinate focused project sessions. A simple event need not acquire an artificial execution plan. Sessions pursuing one continuing objective can remain long-lived. Where sessions work concurrently, they should identify ownership of overlapping files and reconcile changes before release. Cross-project collaboration follows the workspace's access and request controls.

#Three project profiles

These names describe the project's agent behavior; they do not create three permanently running agents. Only the selected profile guides a session. Profiles are adaptable guidance, not compulsory pipelines for every request, and the owner's current instructions take precedence. A Research project can still include coding or slides. Software made primarily for learning can belong to Study.

#Execution, continuity and context

The deployed website stores and presents workspace state. The local runner executes sessions and accesses permitted files, so it must be available for queued work to run. Agents use authenticated workspace tools rather than needing direct database credentials.

Claude and Codex can work against the same project records. Shared tasks, documents and explicit handoffs support continuity when changing provider; provider-specific runtime state is not interchangeable. A handoff records the objective, material decisions, changed artifacts, validation and next action. Different devices should open the same named session to view its shared execution and history.

Context has distinct roles: the conversation carries active work; compact project state summarizes current progress; knowledge preserves durable findings and decisions; skills supply procedures on demand; source artifacts hold the detailed evidence. Agents search before reading broadly, inspect full relevant evidence before making claims, and recover missing state after compaction. Bounded outputs reduce repeated context, but they must preserve the conditions needed for correct reasoning. Live token and cost savings should not be claimed without measurement.

#Deliverables and review

Task status and plan checkboxes reflect verified progress. Software work needs checks appropriate to the changed behavior, including relevant desktop/mobile interactions and a focused production check after deployment. Research work preserves provenance, distinguishes hypotheses from observations, and checks claims against compatible evidence.

For manuscript work, Dungeon Researcher provides an autonomous author–independent reviewer–author loop. The workspace creates or reuses a separate reviewer session and returns its findings to the author through the existing queue. Review is tied to the manuscript and supporting artifact versions. The detailed research document explains review states, figure tooling, evidence gaps and limits; a review receipt is not proof of scientific truth or conference acceptance.

#Documents and publication

Maintain one canonical document for each purpose and update it on demand. The automatic document-keeper is deactivated. Supporting figures, exports and review records belong with their parent deliverable rather than becoming a growing list of competing drafts.

Document purpose determines structure. A manuscript uses the venue's paper conventions; a reference, report or working note uses the structure that best explains its content. Academic tone does not require every document to resemble a paper. Write coherent paragraphs, begin with intuition, define unfamiliar terms and avoid repetition.

The workspace supports Markdown and PowerPoint uploads, mathematical notation, Mermaid previews and editable slide decks. Media-containing exports need validation in the intended presentation application. An Overleaf-ready source ZIP is an import artifact, not evidence of a configured account connection.

Published documents automatically follow later workspace edits. This overview is already published, so its saved revisions also affect the public version. Other documents and tasks retain their own visibility controls.

#Scheduling and notifications

Calendar tasks can have a duration or a deadline, with weekly and monthly views linked to the underlying task. Scheduling uses Hong Kong time. Browser announcements concern calendar deadlines/events, with configurable lead times and defaults of three hours and thirty minutes. Session status remains an in-app concern.

Notifications require browser and operating-system permission. The existing tab-based mechanism is not a guarantee of delivery after the browser is closed, the tab is suspended or the device sleeps.

#Operating principles

Preserve source evidence and unrelated work, keep secrets out of shared notes, and distinguish completed work from attempts and limitations. Retire obsolete knowledge deliberately while retaining useful lessons; do not treat age alone as grounds for deletion. Publishing, deployment, expensive experiments and destructive changes follow the owner's authorization.

The specialist documents describe implemented behavior and its current limits. Improvements should remain incremental and testable, with clear distinctions between a working tool, a verified workflow and the quality of the resulting scientific or product judgment.