donna 0.2.0__py3-none-any.whl → 0.2.2__py3-none-any.whl

donna/artifacts/work/do_it.md

@@ -1,142 +0,0 @@
-# Meta Work Loop
-
-```toml donna
-kind = "donna.lib.workflow"
-start_operation_id = "start"
-```
-
-General purpose work planning and execution workflow. Use it when you need to do complex work and there is no more specific workflow available.
-
-## Start Work
-
-```toml donna
-id = "start"
-kind = "donna.lib.request_action"
-fsm_mode = "start"
-```
-
-1. Read the specification `{{ donna.lib.view("donna:work:planning") }}` if you haven't done it yet.
-2. Read the specification `{{ donna.lib.view("donna:usage:artifacts") }}` if you haven't done it yet.
-3. If the developer hasn't provided you a description of the work for this session, ask them to provide it.
-4. Create new session-level specification `session:work_scope` with developer-provided description of the work to be done.
-5. `{{ donna.lib.goto("create_work_description") }}`
-
-## Create Work Description
-
-```toml donna
-id = "create_work_description"
-kind = "donna.lib.request_action"
-```
-
-1. Read the specification `{{ donna.lib.view("donna:work:planning") }}` if you haven't done it yet.
-2. Read the specification `{{ donna.lib.view("donna:usage:artifacts") }}` if you haven't done it yet.
-3. Formulate a concise high-level description of the work to be done, based on the developer-provided description.
-4. Add this description to the `session:work_scope`.
-5. `{{ donna.lib.goto("list_primary_goals") }}`
-
-## List Primary Goals
-
-```toml donna
-id = "list_primary_goals"
-kind = "donna.lib.request_action"
-```
-
-1. Read the specification `{{ donna.lib.view("donna:work:planning") }}` if you haven't done it yet.
-2. Read the specification `{{ donna.lib.view("donna:usage:artifacts") }}` if you haven't done it yet.
-3. If you can add more goals based on existing `{{ donna.lib.view("session:work_scope") }}` add them to the specification.
-4. If you can polish the existing goals according to the quality criteria in the `{{ donna.lib.view("donna:work:planning") }}` do it.
-5. `{{ donna.lib.goto("list_objectives") }}`
-
-## List Objectives
-
-```toml donna
-id = "list_objectives"
-kind = "donna.lib.request_action"
-```
-
-You MUST list objectives that need to be achieved to complete each goal.
-
-1. Read the specification `{{ donna.lib.view("donna:work:planning") }}` if you haven't done it yet.
-2. Read the specification `{{ donna.lib.view("donna:usage:artifacts") }}` if you haven't done it yet.
-3. If you can add more objectives based on existing `{{ donna.lib.view("session:work_scope") }}` add them to the specification.
-4. If you can polish the existing objectives according to the quality criteria in the `{{ donna.lib.view("donna:work:planning") }}` do it.
-5. `{{ donna.lib.goto("list_constraints") }}`
-
-## List Constraints
-
-```toml donna
-id = "list_constraints"
-kind = "donna.lib.request_action"
-```
-
-1. Read the specification `{{ donna.lib.view("donna:work:planning") }}` if you haven't done it yet.
-2. Read the specification `{{ donna.lib.view("donna:usage:artifacts") }}` if you haven't done it yet.
-3. If you can add more constraints based on existing `{{ donna.lib.view("session:work_scope") }}` add them to the specification.
-4. If you can polish the existing constraints according to the quality criteria in the `{{ donna.lib.view("donna:work:planning") }}` do it.
-5. `{{ donna.lib.goto("list_acceptance_criteria") }}`
-
-## List Acceptance Criteria
-
-```toml donna
-id = "list_acceptance_criteria"
-kind = "donna.lib.request_action"
-```
-
-1. Read the specification `{{ donna.lib.view("donna:work:planning") }}` if you haven't done it yet.
-2. Read the specification `{{ donna.lib.view("donna:usage:artifacts") }}` if you haven't done it yet.
-3. If you can add more acceptance criteria based on existing `{{ donna.lib.view("session:work_scope") }}` add them to the specification.
-4. If you can polish the existing acceptance criteria according to the quality criteria in the `{{ donna.lib.view("donna:work:planning") }}` do it.
-5. `{{ donna.lib.goto("list_deliverables") }}`
-
-## List Deliverables
-
-```toml donna
-id = "list_deliverables"
-kind = "donna.lib.request_action"
-```
-
-1. Read the specification `{{ donna.lib.view("donna:work:planning") }}` if you haven't done it yet.
-2. Read the specification `{{ donna.lib.view("donna:usage:artifacts") }}` if you haven't done it yet.
-3. If you can list more deliverables based on existing `{{ donna.lib.view("session:work_scope") }}` add them to the specification.
-4. If you can polish the existing deliverables according to the quality criteria in the `{{ donna.lib.view("donna:work:planning") }}` do it.
-5. `{{ donna.lib.goto("prepare_plan") }}`
-
-## Prepare Work Plan
-
-```toml donna
-id = "prepare_plan"
-kind = "donna.lib.request_action"
-```
-
-1. Read the specification `{{ donna.lib.view("donna:work:planning") }}` if you haven't done it yet.
-2. Read the specification `{{ donna.lib.view("donna:usage:artifacts") }}` if you haven't done it yet.
-3. Read the specification `{{ donna.lib.view("session:work_scope") }}` if you haven't done it yet.
-4. Create new session-level workflow `session:work_execution` according to the scope of work you have defined.
-5. `{{ donna.lib.goto("execute_plan") }}`
-
-## Execute Plan
-
-```toml donna
-id = "execute_plan"
-kind = "donna.lib.request_action"
-```
-
-1. Run workflow `session:work_execution` to execute the work according to the plan.
-2. `{{ donna.lib.goto("groom_work") }}`
-
-## Groom Work
-
-```toml donna
-id = "groom_work"
-kind = "donna.lib.request_action"
-```
-
-1. Run the grooming workflow to ensure that the result is polished, clean, and ready for review.
-2. `{{ donna.lib.goto("finish") }}`
-
-## Finish
-
-```toml donna
-id = "finish"
-kind = "donna.lib.finish"
-```

donna/artifacts/work/do_it_fast.md

@@ -1,98 +0,0 @@
-# Show Workflow Spec + Schema
-
-```toml donna
-kind = "donna.lib.workflow"
-start_operation_id = "read_workflow_source"
-```
-
-<!-- This is a temporary worflow, later Donna should have a specialized command to display the spec -->
-
-This workflow guides an agent through loading a workflow artifact source, choosing the correct FSM graph DSL, and producing a concise schema summary with a graph and per-operation descriptions.
-
-## Read workflow source
-
-```toml donna
-id = "read_workflow_source"
-kind = "donna.lib.request_action"
-fsm_mode = "start"
-```
-
-1. Identify the full workflow artifact id to summarize from the developer request (for example: `project:work:grooming`).
-2. If the workflow id is missing or ambiguous, ask the developer to provide the exact id, then repeat this operation.
-3. Fetch the workflow artifact source with:
-   - `./bin/donna.sh artifacts fetch '<workflow-id>'`
-4. Read the fetched source from the path printed by the command to capture:
-   - Workflow name (H1 title) and short description.
-   - The start operation (from `start_operation_id` in the workflow head config, which must be marked with `fsm_mode = "start"`).
-   - Each operation `id`, `kind`, and any {% raw %}`{{ donna.lib.goto(...) }}`{% endraw %} transitions in its body.
-5. Continue to {{ donna.lib.goto("select_fsm_dsl") }}.
-
-## Select FSM graph DSL
-
-```toml donna
-id = "select_fsm_dsl"
-kind = "donna.lib.request_action"
-```
-
-1. Determine whether the developer requested a specific FSM graph DSL (from the original request or provided inputs).
-2. If a DSL is specified, record it verbatim for rendering.
-3. If no DSL is specified, select Mermaid DSL.
-4. Continue to {{ donna.lib.goto("render_schema") }}.
-
-## Render short schema
-
-```toml donna
-id = "render_schema"
-kind = "donna.lib.request_action"
-```
-
-1. Produce the schema output in the exact meta format below, using the selected DSL for the FSM graph:
-
-```
-# <workflow name>
-
-<very short one sentence description of what it does>
-
-<FSM graph description in some DSL>
-
-<list of operations: `<id>` — <short one sentence description of what it does>
-```
-
-2. Ensure the FSM graph includes all operations and transitions, and clearly marks the start and finish operations.
-3. For Mermaid, use a `stateDiagram-v2` or `flowchart` representation and keep node ids aligned with operation ids.
-4. For each operation list entry, write a single concise sentence that is clean, complete, and faithful to the operation body.
-5. Continue to {{ donna.lib.goto("refine_schema") }}.
-
-## Refine schema output
-
-```toml donna
-id = "refine_schema"
-kind = "donna.lib.request_action"
-```
-
-1. Re-read the produced schema and improve clarity and correctness without changing the required format.
-2. Tighten wording to keep each description to a single clean sentence while still being thorough and accurate.
-3. Ensure the DSL selection rule is reflected in the graph and described output.
-4. Continue to {{ donna.lib.goto("validate_schema") }}.
-
-## Validate schema output
-
-```toml donna
-id = "validate_schema"
-kind = "donna.lib.request_action"
-```
-
-1. Verify the output contains the title, one-sentence description, FSM graph, and operation list in the required order.
-2. Confirm the chosen DSL is correct (developer-specified or Mermaid by default).
-3. Confirm each operation description is a single sentence and matches the operation purpose.
-4. If any check fails, return to {{ donna.lib.goto("refine_schema") }}.
-5. If all checks pass, proceed to {{ donna.lib.goto("finish") }}.
-
-## Finish
-
-```toml donna
-id = "finish"
-kind = "donna.lib.finish"
-```
-
-Workflow complete.

donna/artifacts/work/planning.md

@@ -1,245 +0,0 @@
-# Session Planning Guidelines
-
-```toml donna
-kind = "donna.lib.specification"
-```
-
-This document describes how Donna MUST plan work on a session with the help of workflows. The
-document describes the process of planning, kinds of involved entities and requirements for them.
-
-**This requirements MUST be applied to all planning workflows that Donna uses.**
-
-## Overview
-
-Donna's workflows create a plan of work on a session by iteratively polishing the set of session-level artifacts.
-
-Artifacts are:
-
-- `session:work_scope` — a specification that describes the scope of work to be done on the session.
-- `session:work_execution` — a workflow that describes the step-by-step plan of work to be done on the session.
-
-The agent MUST create and iteratively polish these artifacts until they meet all quality criteria described in this document. After the plan is ready, the agent MUST run it as a workflow.
-
-## Work Scope Specification
-
-The work scope specification has a standard name `session:work_scope` and describes the work to be done in the context of the current session.
-
-The specification MUST contain the following sections:
-
-1. `Developer request` — a copy of the original description of the work from the developer.
-2. `Work description` — a high-level description of the work to be done, created by Donna
-   based on the developer request.
-3. `Goals` — a list of goals that work strives to achieve.
-4. `Objectives` — a list of specific objectives that need to be completed to achieve the goals.
-5. `Known constraints` — a list of constraints for the session.
-6. `Acceptance criteria` — a list of acceptance criteria for the resulted work.
-7. `Deliverables / Artifacts` — a list of concrete deliverables / artifacts that MUST be produced.
-
-Sections `Developer request` and `Detailed work description` are free-form text sections.
-Sections `Goals`, `Objectives` should contain lists of items.
-
-### "Developer Request" section requirements
-
-- This section MUST contain the original request from the developer. The request MUST NOT be modified by Donna.
-
-### "Work Description" section requirements
-
-- The section MUST contain a clear professional high-level description of the work to be done based
-  on the developer's request.
-- The section MUST be limited to a single paragraph with a few sentences.
-- The sectino MUST explain what someone gains after these changes and how they can see it working.
-  State the user-visible behavior the task will enable.
-
-### "Goals" section requirements
-
-- The section MUST contain a list of high-level goals that the work strives to achieve.
-
-The goal quality criteria:
-
-- A goal describes a desired end state, outcome or result.
-- A goal defines what should ultimately be true, not how to achieve it.
-- A goal must not be defined via listing cases, states, outcomes, etc. Instead, use one of the next
-  approaches:
-  a) summarize top-layer items into a single goal;
-  b) split the goal into multiple more specific goals;
-  c) reformulate to a list of second-layer items as required properties of the top-level goal.
-- Each goal must has clear scope and boundaries.
-
-### "Objectives" section requirements
-
-- The section MUST contain a list of specific objectives that need to be completed to achieve the goals.
-
-Objective quality criteria:
-
-- An objective MUST describe an achieved state or capability not the act of describing it.
-- An objective MUST be phrased as "X exists / is implemented / is defined / is executable /
-  is enforced / …"
-- An objective MUST be atomic: it MUST result in exactly one concrete deliverable: one artifact,
-  one executable, one schema, one test suite, etc.
-- An objective is a single clear, externally observable condition of the system (not a description,
-  explanation, or analysis) that, when met, moves you closer to achieving a specific goal.
-- An objective is a top-level unit of work whose completion results in a concrete artifact,
-  behavior, or state change that can be independently verified without reading prose.
-- Each goal MUST have a set of objectives that, when all achieved, ensure the goal is met.
-- Each goal MUST have 2–6 objectives, unless the goal is demonstrably trivial (≤1 artifact, no dependencies).
-
-### "Known Constraints" section requirements
-
-- The section MUST contain a list of known constraints that the work MUST respect.
-
-Constraint quality criteria:
-
-- A known constraint describes a non-negotiable limitation or requirement that the work MUST
-  respect (technical, organizational, legal, temporal, compatibility, security, operational).
-- Each constraint MUST be derived from explicitly available inputs (the developer request, existed
-  specifications, existed code, information provided by workflows). Donna MUST NOT invent
-  constraints.
-- Each constraint MUST be phrased as a verifiable rule using normative language: "MUST / MUST NOT /
-  SHOULD / SHOULD NOT".
-- Each constraint MUST be atomic: one rule per record (no "and/or" bundles). If multiple rules
-  exist, split into multiple constraint records.
-- Each constraint MUST be externally binding (something the plan must accommodate), not an
-  internal preference.
-- Constraints MUST NOT restate goals/objectives in different words. They are bounds, not outcomes.
-- Constraints MUST NOT contain implementation steps, designs, or proposed solutions.
-- Constraints MUST NOT include risks, unknowns, or speculative issues.
-- Constraints MUST be written so a reviewer can answer true/false for compliance by inspecting
-  artifacts, behavior, or configuration (not by reading explanatory prose).
-- The section MAY be empty only if no constraints are explicitly known.
-
-Examples:
-
-- Good: `MUST remain compatible with Python 3.10`
-- Good: `MUST not change public CLI flags`
-- Good: `MUST avoid network access`
-- Good: `MUST run on Windows + Linux`
-- Bad: `We should do it cleanly`
-- Bad: `Prefer elegant code`
-- Bad: `Try to keep it simple`
-
-### "Acceptance criteria" section requirements
-
-- The section MUST contain a list of acceptance criteria that define how to evaluate the session's results.
-
-Acceptance criteria quality criteria:
-
-- An acceptance criterion describes a pass/fail condition that determines whether the session's
-  results are acceptable to a reviewer, user, or automated gate.
-- Each criterion MUST be derived from explicitly available inputs (developer request, previous
-  sections of the plan). Donna MUST NOT invent new scope, features, constraints, or assumptions.
-- Each criterion MUST be phrased as an externally observable, verifiable rule, using normative
-  language ("MUST / MUST NOT / SHOULD / SHOULD NOT") or an equivalent test form such as
-  Given/When/Then (Gherkin-style).
-- Each criterion MUST be independently checkable by inspecting artifacts, running a command,
-  executing tests, or observing runtime behavior/output — not by reading explanatory prose.
-- Each criterion MUST be atomic: one condition per record (no "and/or" bundles). If multiple
-  conditions exist, split into multiple criteria records.
-- Criteria MUST NOT describe implementation steps, internal design decisions, or "how" to achieve the result.
-- Criteria MUST NOT restate goals/objectives verbatim. Instead, they must state how success is
-  demonstrated (e.g., observable behavior, produced files, enforced rules, test outcomes).
-
-Coverage rules:
-
-- Each objective MUST have ≥1 acceptance criterion that validates it.
-- Each acceptance criterion MUST map to at least one objective (directly or via a goal that the objective serves).
-- Where relevant, criteria SHOULD specify concrete evaluation conditions, such as:
-  - exact CLI output/exit codes, produced artifacts and their locations;
-  - supported platforms/versions, configuration prerequisites;
-  - measurable thresholds (latency, memory, size limits), if such requirements are explicitly implied or stated.
-  - etc.
-
-Regression rules:
-
-- If the developer request or known constraints imply preserving existing behavior, acceptance
-  criteria SHOULD include explicit non-regression checks (what must remain unchanged).
-- The section MUST NOT be empty.
-
-### "Deliverables / Artifacts" section requirements
-
-- The section MUST contain a list of concrete deliverables/artifacts that MUST be produced by the work.
-
-Deliverable/artifact quality criteria:
-
-- A deliverable/artifact record MUST name a concrete output that will exist after the work is
-  complete (a file, module, package, binary, schema, configuration, test suite, generated report,
-  published document, metric in the metrics storage, dashbord, etc.).
-- Each deliverable/artifact MUST be derived from explicitly available inputs (developer request,
-  prior sections of this plan). Donna MUST NOT invent new deliverables that introduce new scope.
-- Each deliverable/artifact MUST be externally verifiable by inspecting the repository/workspace,
-  produced files, or runtime outputs — not by reading explanatory prose.
-- Each deliverable/artifact record MUST be phrased as an existence statement using normative
-  language, e.g. "MUST include …", "MUST produce …", "MUST add …".
-- Each deliverable/artifact record MUST be atomic: exactly one deliverable per record (no
-  "and/or", no bundles). If multiple outputs are required, split into multiple records.
-- Each deliverable/artifact MUST specify at least one of:
-  - an exact path/location (preferred), or
-  - an exact artifact identifier (module/package name, command name, schema name, etc.).
-- If the deliverable is generated by running a command, the record SHOULD specify the command
-  entrypoint (e.g., via a CLI (Command-Line Interface) command name) and the expected output
-  location, without describing internal implementation steps.
-- Deliverables MUST NOT be vague (e.g., "updated code", "better docs"). They MUST be concrete
-  enough that a reviewer can confirm presence/absence.
-- Deliverables MUST NOT restate goals, objectives, constraints, or acceptance criteria. They must
-  list *outputs*, not outcomes or pass/fail checks.
-- The section MUST NOT be empty.
-
-Source files as artifacts:
-
-- Explicitly add source files (paths) as deliverables/artifacts only if the task is specifically
-  about creating or modifying those files (e.g., "MUST add docs/cli.md …").
-- Do not add source files as deliverables/artifacts if they are unknown at planning time (i.e. we
-  do not know which files will be changed/added). In such cases, focus on higher-level deliverables
-  (e.g., "MUST add CLI documentation" instead of listing specific files).
-
-## Work Execution Workflow
-
-The work execution workflow has a standard name `session:work_execution` and describes the step-by-step plan of work to be done in the context of the current session.
-
-The workflow MUST be an artifact of kind `workflow`, see details `{{ donna.lib.view("donna:usage:artifacts") }}`. I.e. the final workflow must be a valid FSM that agent will execute with the help of `donna` tool.
-
-Primary requirement:
-
-1. **You MUST prefer non-linear or cyclic workflows for complex tasks instead of long linear sequences.** I.e. use loops, conditionals, parallel branches, etc. where appropriate. That should help you to apply changes iteratively, validate them early and often and to polish the results step by step. I.e. prefere an incremental/evolutionary approach over a big-bang one.
-2. However, prefere multiple short loops over a single long loop. The approach `do everything then repeat from scratch` is a bad practice. Instead, break down the work into smaller steps that can be done, verified and polished independently.
-3. The resulted workflow MUST ensure that there is at least 1 refine iteration will always be applied (for each loop).
-4. Describe each operation with effort: add details, examples, behavior for edge cases, etc. Formulate each term and action precisely.
-
-General requirements:
-
-- Each workflow step should describe an operation dedicated to one semantically atomic task.
-- Each operation of the workflow MUST be derived from explicitly available inputs (developer request +
-  prior plan sections). It MUST NOT introduce new scope, features, constraints, or deliverables.
-- Each workflow operation item MUST map to ≥1 objective.
-- Each objective MUST be covered by ≥1 workflow operation that produces the required change/artifact,
-  and where relevant by additional item(s) that validate it (tests, checks, demo run).
-- Each workflow operation MUST be atomic: one primary action per item (no "and/or" bundles). If
-  multiple actions are needed, split into multiple items.
-- Each workflow operation MUST be actionable and specific enough that a agent can execute it
-  without needing additional prose:
-  - It SHOULD name the component/module/subsystem affected, if known.
-  - It SHOULD name the concrete artifact(s) it will create/modify when those artifacts are already
-    known from the "Deliverables / Artifacts" section (do not invent file paths).
-- If a command is required (e.g., a CLI (Command-Line Interface) invocation, test runner command),
-  operation SHOULD include the exact command.
-- Workflow operation MUST NOT be vague (e.g., "Improve code quality", "Handle edge cases", "Do the thing").
-- Workflow operations MUST respect all "Known constraints".
-- If workflow operation includes research/design work, there results MUST be represented as concrete artifacts or changes in the `session:work_scope` and `session:work_execution` artifacts.
-
-Verification steps:
-
-- The workflow SHOULD include explicit verification operations that demonstrate acceptance
-  criteria, such as:
-  - adding or updating automated tests;
-  - running tests/lint/static checks (if such gates exist in the project inputs);
-  - running a minimal end-to-end command or scenario that shows the user-visible behavior.
-- Verification MUST be phrased as executable checks (commands, test suites, observable outputs), not
-  as "Review the code" or "Make sure it works".
-
-Examples:
-
-- Good: "Implement the `foo` subcommand behavior to emit the required summary line for each generation."
-- Good: "Add automated tests that assert the `foo` subcommand exit code and exact stdout lines for the sample fixture."
-- Good: "Run `pytest -q` and confirm the new tests pass."
-- Bad: "Implement feature and update tests and docs."
-- Bad: "Consider performance implications."
-- Bad: "Document the approach in detail."

donna/cli/commands/projects.py

@@ -1,49 +0,0 @@
-import pathlib
-from collections.abc import Iterable
-
-import typer
-
-from donna.cli.application import app
-from donna.cli.types import WorkdirOption
-from donna.cli.utils import cells_cli, try_initialize_donna
-from donna.domain.ids import WorldId
-from donna.protocol.cell_shortcuts import operation_succeeded
-from donna.protocol.cells import Cell
-from donna.world.config import config
-
-projects_cli = typer.Typer()
-
-
-@projects_cli.callback(invoke_without_command=True)
-def initialize_callback(ctx: typer.Context) -> None:
-    cmd = ctx.invoked_subcommand
-
-    if cmd is None:
-        return
-
-    if cmd in ["initialize"]:
-        return
-
-    try_initialize_donna()
-
-
-@projects_cli.command(help="Initialize Donna project.")
-@cells_cli
-def initialize(workdir: WorkdirOption = pathlib.Path.cwd()) -> Iterable[Cell]:
-    # TODO: use workdir attribute
-    project = config().get_world(WorldId("project")).unwrap()
-
-    project.initialize()
-
-    session = config().get_world(WorldId("session")).unwrap()
-
-    session.initialize()
-
-    return [operation_succeeded("Project initialized successfully")]
-
-
-app.add_typer(
-    projects_cli,
-    name="projects",
-    help="Initialize and manage Donna project.",
-)

donna/world/artifacts.py

@@ -1,122 +0,0 @@
-import pathlib
-
-from donna.core.entities import BaseEntity
-from donna.core.errors import ErrorsList
-from donna.core.result import Err, Ok, Result, unwrap_to_error
-from donna.domain.ids import FullArtifactId, FullArtifactIdPattern, WorldId
-from donna.machine.artifacts import Artifact
-from donna.machine.tasks import Task, WorkUnit
-from donna.world import errors
-from donna.world.config import config
-from donna.world.templates import RenderMode
-
-
-class ArtifactRenderContext(BaseEntity):
-    primary_mode: RenderMode
-    current_task: Task | None = None
-    current_work_unit: WorkUnit | None = None
-
-
-class ArtifactUpdateError(errors.WorldError):
-    cell_kind: str = "artifact_update_error"
-    artifact_id: FullArtifactId
-    path: pathlib.Path
-
-    def content_intro(self) -> str:
-        return f"Error updating artifact '{self.artifact_id}' from the path '{self.path}'"
-
-
-class CanNotUpdateReadonlyWorld(ArtifactUpdateError):
-    code: str = "donna.world.cannot_update_readonly_world"
-    message: str = "Cannot upload artifact to the read-only world `{error.world_id}`"
-    world_id: WorldId
-
-
-class InputPathHasNoExtension(ArtifactUpdateError):
-    code: str = "donna.world.input_path_has_no_extension"
-    message: str = "Input path has no extension to determine artifact source type"
-
-
-class NoSourceForArtifactExtension(ArtifactUpdateError):
-    code: str = "donna.world.no_source_for_artifact_extension"
-    message: str = "No source found for artifact extension of input path"
-
-
-@unwrap_to_error
-def artifact_file_extension(full_id: FullArtifactId) -> Result[str, ErrorsList]:
-    world = config().get_world(full_id.world_id).unwrap()
-    return Ok(world.file_extension_for(full_id.artifact_id).unwrap().lstrip("."))
-
-
-@unwrap_to_error
-def fetch_artifact(full_id: FullArtifactId, output: pathlib.Path) -> Result[None, ErrorsList]:
-    world = config().get_world(full_id.world_id).unwrap()
-    content = world.fetch_source(full_id.artifact_id).unwrap()
-
-    with output.open("wb") as f:
-        f.write(content)
-
-    return Ok(None)
-
-
-@unwrap_to_error
-def update_artifact(full_id: FullArtifactId, input: pathlib.Path) -> Result[None, ErrorsList]:
-    world = config().get_world(full_id.world_id).unwrap()
-
-    if world.readonly:
-        return Err([CanNotUpdateReadonlyWorld(artifact_id=full_id, path=input, world_id=world.id)])
-
-    source_suffix = input.suffix.lower()
-    content_bytes = input.read_bytes()
-
-    if not source_suffix:
-        return Err([InputPathHasNoExtension(artifact_id=full_id, path=input)])
-
-    source_config = config().find_source_for_extension(source_suffix)
-    if source_config is None:
-        return Err([NoSourceForArtifactExtension(artifact_id=full_id, path=input)])
-
-    render_context = ArtifactRenderContext(primary_mode=RenderMode.view)
-    test_artifact = source_config.construct_artifact_from_bytes(full_id, content_bytes, render_context).unwrap()
-    validation_result = test_artifact.validate_artifact()
-
-    validation_result.unwrap()
-    world.update(full_id.artifact_id, content_bytes, source_suffix).unwrap()
-
-    return Ok(None)
-
-
-@unwrap_to_error
-def load_artifact(
-    full_id: FullArtifactId, render_context: ArtifactRenderContext | None = None
-) -> Result[Artifact, ErrorsList]:
-    if render_context is None:
-        render_context = ArtifactRenderContext(primary_mode=RenderMode.view)
-
-    world = config().get_world(full_id.world_id).unwrap()
-    return Ok(world.fetch(full_id.artifact_id, render_context).unwrap())
-
-
-def list_artifacts(  # noqa: CCR001
-    pattern: FullArtifactIdPattern, render_context: ArtifactRenderContext | None = None
-) -> Result[list[Artifact], ErrorsList]:
-
-    if render_context is None:
-        render_context = ArtifactRenderContext(primary_mode=RenderMode.view)
-
-    artifacts: list[Artifact] = []
-    errors: ErrorsList = []
-
-    for world in reversed(config().worlds_instances):
-        for artifact_id in world.list_artifacts(pattern):
-            full_id = FullArtifactId((world.id, artifact_id))
-            artifact_result = load_artifact(full_id, render_context)
-            if artifact_result.is_err():
-                errors.extend(artifact_result.unwrap_err())
-                continue
-            artifacts.append(artifact_result.unwrap())
-
-    if errors:
-        return Err(errors)
-
-    return Ok(artifacts)