Archive Node

  1. Overview
  2. Hand Off Documentation
  3. Design (Dual Editor)
  4. Archive Node

Feature Owner: Joshua Uriel Tribiana
Module: Design ( Dual Editor )
Priority: P1
Week 7 Sprint: Fully Implemented
Date: 06-30-2026

EXECUTIVE SUMMARY

What is this feature?
Archive Node lets creators hide nodes from the visual canvas without permanently deleting them. It is a lightweight content-management feature for the quest editor that keeps archived nodes preserved in state, removes them from the visible canvas, and allows them to be restored later.

Why does it matter?
Creators often need to remove content from view temporarily while preserving the underlying structure for later reuse. This reduces clutter, helps with iterative editing, and prevents accidental deletion during content refinement.

What’s the MVP scope?

  • Archive and restore actions from node-level controls

  • A dedicated archived-nodes modal for managing hidden content

  • Hidden-node behavior in both linear and exploration canvas modes

  • Preservation of node data so it can be restored later

  • Permanent delete support from the archived-node management UI

1. USER PAIN POINT & SOLUTION

Current State (Without Feature)

Creators often have to leave unused or outdated nodes visible on the canvas, which makes the editing experience cluttered and harder to navigate. Deleting a node is risky because it removes the content permanently.

Pain Point

Emotional: Frustration and fear of losing content while reorganizing a quest
Functional: Visual clutter and limited control over which nodes are visible during editing
Business Impact: Slower iteration, accidental content loss, and reduced confidence while authoring complex quests

Future State (With Feature)

Creators can archive nodes they no longer want visible, keep them safely stored, and restore them later when needed. The canvas becomes cleaner while preserving editing flexibility.

Marketing Hook

“Declutter your quest editor without losing your work — archive nodes and bring them back whenever you need them.”

2. CODEBASE ASSESSMENT

Current Implementation Status

The archive-node experience is already implemented in the quest editor’s visual-canvas layer. The feature is wired into the node action menu, the canvas state management hooks, and the archived-node modal.

Primary Files

Current Behavior Summary

  • Archive action is available through the node action menu

  • Archived nodes are removed from the visible canvas and hidden from the creator view

  • Archived nodes remain in the backing React Flow state and can be restored

  • Archived nodes can be permanently deleted from the archived-node modal

  • Archived nodes are visually marked as archived in the UI and are non-editable

Strengths Already Present

  • Clear creator-facing archive/restore flow

  • Data preservation before permanent deletion

  • Works across both linear and exploration canvas modes

  • Supports both regular nodes and child nodes inside scenario structures

Gaps / Hardening Opportunities

  • No dedicated analytics or audit trail for archives yet

  • No bulk archive/restore experience beyond the current per-node workflow

  • No explicit “show archived nodes” toggle outside the modal entry point

3. 4D FRAMEWORK MAPPING

Diagnose

The feature helps creators evaluate and reorganize their content by removing clutter from the active editing view without losing the underlying content structure.

Design

It supports a cleaner content-authoring experience by allowing creators to temporarily hide nodes they are not actively editing or that are no longer relevant.

Develop

Creators can continue iterating faster because they can de-emphasize older or draft content without permanently deleting it.

Deliver

Archived nodes remain safe in the quest payload and can be restored at any time, making authoring more resilient and less destructive.

4. USER FLOWS

Entry Point

A creator is editing a quest in the visual canvas and opens the node actions menu.

Success Criteria

  • The selected node is hidden from the visible canvas

  • The node is preserved and can be restored later

  • The creator can review and manage archived nodes from the archived-node modal

Main Flow (Happy Path)

  1. Creator clicks the node actions menu on a node

  2. Creator chooses “Archive”

  3. The node is removed from the visible canvas and stored as archived

  4. The archived-node count appears in the canvas toolbar

  5. Creator opens the archived-node modal and restores or permanently deletes the node

Edge Cases

  • Child node inside a scenario: The archive action removes the child from the visible scenario structure and preserves it in archive state

  • Archived node already hidden: The UI should avoid duplicate archive actions or stale state

  • Permanent delete: The node is removed from archive state and cannot be restored afterward

Decision Points

  • IF the creator restores the node → it reappears on the canvas

  • IF the creator deletes it permanently → it is removed from the archive list and the canvas

  • ELSE → the node remains archived and hidden

5. INFORMATION ARCHITECTURE

Primary Information (Always visible)

  • Node label or node type

  • Archived-node count in the canvas UI

  • Restore and Delete actions in the archived-node modal

Secondary Information

  • Node status badge such as “Archived”

  • Whether the node is a start/end node or AI-generated scenario node

Tertiary Information (Hidden until needed)

  • Full archived-node list

  • Child-node archival state inside scenario structures

  • Internal node metadata preserved in canvas state

Actions

Primary CTA:

  • Restore archived node

Secondary Actions:

  • Delete permanently

  • Close modal

6. WIREFRAMES

No standalone new screen is required for this feature.

Key Screens:

  1. Node action menu on a canvas node

  2. Archived-nodes modal listing hidden nodes

  3. Empty state when no nodes are archived

  4. Confirmation dialog for permanent delete

Annotations:

  • Archive is a non-destructive action

  • Restore returns the node to the canvas

  • Permanent delete is explicit and destructive

7. WIREFLOWS

+--------------------+
| Canvas Node        |
+--------------------+
          |
          v
+--------------------+
| Context Menu       |
| Archive            |
+--------------------+
          |
          v
+--------------------+
| Status Updated     |
| (ARCHIVED)         |
+--------------------+
          |
     +----+----+
     |         |
     v         v
+-----------+  +----------------+
| Hidden    |  | Archived Nodes |
| on Canvas |  | Modal          |
+-----------+  +----------------+
                     |
                     v
              +----------------+
              | Restore Node   |
              +----------------+
                     |
                     v
              +----------------+
              | Visible Again  |
              +----------------+

8. PROTOTYPE

Excluded — feature is fully implemented.

How to test:

  1. Open a quest in the visual canvas

  2. Archive a node from the node action menu

  3. Confirm it disappears from the canvas and shows up in the archived list

  4. Restore it and confirm it reappears

  5. Delete it permanently and confirm it is removed from the archive list

9. BACKEND SCHEMA

Data Model

No dedicated archive table is required for this feature. The archive state is stored as node-level metadata on the canvas payload and persisted with the quest’s saved canvas data.

Relevant Runtime Shape

The archive state is represented through node data such as:

interface NodeData {
  isArchived?: boolean;
  label?: string;
  type?: string;
  [key: string]: unknown;
}

Constraints

  • Archived nodes must remain part of the saved canvas structure until explicitly removed

  • Archived nodes should not be visible to creators or learners while archived

  • Restoring a node should restore its prior node data and position context

10. API ENDPOINTS

Current Pattern

This feature does not use a separate archive API endpoint. It operates through the existing canvas save and load flow.

Relevant Behavior

  • Nodes are archived and unarchived in the client-side React Flow state

  • Those changes are saved as part of the overall canvas state when the quest is saved

Expected Payload Behavior

The persisted canvas data carries node metadata including isArchived, letting the app rehydrate the correct visible state on reload.

11. DATA REQUIREMENTS

Frontend Needs

The UI needs to:

  • Show archive/restore actions on each node

  • Display a count of archived nodes in the canvas toolbar

  • Open a modal listing archived nodes

  • Support restore and permanent delete actions

Client State Requirements

  • Current canvas nodes

  • Archived-node list

  • Node metadata including archived status

  • Save and reload behavior for canvas state

Caching Strategy

No special caching is required. The archive state is part of the saved canvas model and should be reloaded with the rest of the quest content.

12. PERFORMANCE CONSIDERATIONS

UI Performance

The feature is lightweight and runs entirely in the canvas state layer. Since archived nodes are simply filtered from the visible render path, it avoids unnecessary rendering overhead.

Save Behavior

The archive state is part of the normal canvas save process, so it should not introduce a separate persistence burden.

Reliability

The archive state should remain stable across refreshes and canvas reloads, even when a node is hidden from the visible canvas.

13. SECURITY & AUTHORIZATION

Who can access this feature?

  • Creator: ✓

  • Reviewer: ✗

  • Learner: ✗

Authorization Logic

This interaction is part of the creator editing experience and is controlled by the existing quest editor permissions and published-edit confirmation flow.

Data Validation

  • Archive and restore actions should only occur in creator-editable contexts

  • Permanent delete should require explicit confirmation

  • Archived content should remain protected from normal learner navigation and editing flows

14. ERROR HANDLING

Common Errors

  • Node not found: The selected node may already have been removed or reloaded

  • Save failure: The archive change may not persist if the canvas save fails

  • Published content restriction: Some edits may be blocked when the quest is published or in a protected state

Handling Guidance

  • Show a graceful fallback if the node is no longer present

  • Preserve the last known archived state if the save action fails

  • Use the existing published-edit confirmation mechanism before destructive actions

15. TESTING CHECKLIST

Happy Path

  • A node can be archived from the node action menu

  • The node disappears from the visible canvas

  • The archived-node count updates correctly

  • The node can be restored from the archived-node modal

  • The node can be permanently deleted from the archived-node modal

Edge Cases

  • Child nodes inside a scenario can be archived and restored

  • The canvas remains stable after archiving multiple nodes

  • Archived nodes are excluded from normal learner and editor flows

  • The UI handles empty archived-node state correctly

16. OPEN QUESTIONS

For Frontend

  • Should there be a bulk archive/restore action for multiple selected nodes?

  • Should archived nodes be visually distinguishable in the canvas when the modal is closed?

For Backend / Persistence

  • Should archived state be surfaced in any analytics or content-history view?

  • Should there be a stronger “soft delete” lifecycle for canvas content beyond the current archive flow?

17. OUT OF SCOPE (v1.1+)

  • Bulk archive/restore across large sets of nodes

  • A dedicated archive history or audit timeline

  • Cross-quest node recovery workflow

  • Advanced filtering of archived content by type or date

Why: The current scope is to ship a dependable per-node archive/restore experience that fits the existing editor workflow.

18. SUCCESS METRICS

How will we know this feature is working well?

  • Creators successfully archive nodes without losing content

  • Restores happen reliably and quickly

  • The canvas feels less cluttered during editing sessions

  • Permanent delete is used only when the creator intentionally wants to remove content

19. DEPENDENCIES

This feature depends on:

  • The existing visual-canvas editor infrastructure

  • React Flow node state and save/load logic

  • The published-edit confirmation flow for protected content

These features depend on this:

  • Any future content-cleanup and content-organization flows in the quest editor

  • Any future soft-delete or recovery system for quest content

20. TIMELINE & OWNERSHIP

Implementation Ownership

  • Owner: Joshua Uriel Tribiana

  • QA: JD Billate

Written by Uriel Last updated June 30, 2026
Was this article helpful?