# QNE User Data Import Agent Doctrine V1

Date: 2026-06-14

## Status

Current planning doctrine. This is a deliberate deferred work item, not an
immediate implementation target.

## Purpose

QNE should provide a user-authorized data import agent so a user can bring
their existing digital life into their Home Node. Target imports include social
network exports, transaction downloads, account statements, contacts, calendars,
email exports, utility bills, insurance documents, and similar user-owned data.

The import agent exists to make QNE useful as the user's private memory and
archive. It is not primarily a scraping feature; it is a private data custody
and migration feature.

## Timing Decision

Do not build this before the mobile-first PA scene, keyboard, conversation,
Home Node connection, and basic semantic action path are stable.

The import agent depends on a good PA conversation surface because the user must
understand and approve each sensitive step. Building the import machinery before
the mobile PA is comfortable would create tech debt and security risk.

The correct near-term action is to keep this doctrine current and return to it
after the mobile PA can reliably guide a user through multi-step tasks.

## Obscura / Browser Automation Role

Obscura or a similar Rust headless browser may be used as an implementation
option for a future `QNEWebAgentEngine`. It should run on the Home Node or a
trusted helper node, not inside the mobile app.

The QNE code should not depend directly on one browser engine. Use an internal
interface so the engine can be changed later:

- `QNEWebAgentEngine`
- `ObscuraWebAgentEngine`
- future `ChromeWebAgentEngine`
- future guided-manual import engine

## User Consent Rule

The import agent must operate under explicit user consent. QNE must not ask for
or store bank, social, email, or government passwords as a normal pattern.

Preferred flow:

1. The PA explains the import.
2. The user chooses a provider and data type.
3. The user logs in directly where required.
4. QNE assists navigation or provides manual instructions.
5. QNE downloads only user-approved exports or documents.
6. QNE stores raw files in the user's persist import area.
7. Parser skills convert raw files into structured QNE data.
8. QNE keeps provenance: provider, timestamp, filename, hash, and parser version.

## Financial Data Rule

Banking and financial imports are read-only. The import agent must not automate
payments, transfers, security-setting changes, password changes, or account
closure actions.

For banks, prefer official CSV, OFX, QIF, PDF, or statement downloads. If the
site blocks automation or the risk is unclear, QNE should guide the user through
manual download and then import the file.

## Storage Rule

Imported files belong in the user's Home Node persist area under an import
structure with stable provenance metadata. Raw exports should be retained unless
the user explicitly deletes them.

Imported structured data should be owned by the relevant QNENodeSkill, but the
raw source material remains the evidence trail.

## First Implementation Shape

When resumed, build the smallest useful version:

1. A `qne-user-data-import` planning crate or skill skeleton.
2. A provider-neutral import job model.
3. A local file import path for user-provided CSV/ZIP/PDF files.
4. A parser/provenance manifest.
5. Only then add optional Obscura-assisted browser automation.

The first automated provider should be low-risk and non-financial. Social export
download assistance is preferable before bank transaction automation.

## Deferred Work Marker

This doctrine is the active reminder to build the user data import agent after
mobile PA usability and Home Node semantic action transport have advanced.
