keel asset onboard: one guided flow for declare → attest → allowlist → fetch/screen, ending at a candidate rule

[eaitbrahim]

Problem

Adding an asset takes five separate manual steps today:

1. Declare: direct choice, keel assets discover, or keel assets propose --from <shortlist.json>.
2. Attest: keel assets attest (shariah classification: sector, backing, yield, source) and keel assets attest-instrument (the venue contract).
3. Configure: add the symbol to the profile's allowlist and target_weights.
4. Fetch and screen: keel fetch --products <P>, then keel assets screen.
5. Rule: keel rules add --kind dca …, then promotion.

Each step exists for a reason, but running them separately is error-prone. It's easy to attest without adding to the allowlist, or to add to the allowlist before history is fetched.

Proposal: keel asset onboard <PRODUCT> (interactive, TTY only)

One guided flow that runs steps 1–4 in order and stops at a candidate rule.

• Attestation prompts ask for sector, backing, pays-yield and a source URL from the human. The tool never invents or defaults an attestation, because the human provides that provenance (design spec §5 asymmetry: tools may propose, humans attest).
• Config edits are shown as a diff of the profile file before they're written, behind a Y/N. Nothing is written without the diff being confirmed.
• Fetch and screen run next and show the admission result. If the asset fails admission, the flow stops there and says why, before any rule exists.
• The rule step hands off to keel dca plan (this milestone), or creates one dca rule at status candidate with the chosen budget and cadence.

Hard limits (from decisions of 2026-09-27)

• No promotion. Reaching paper or live stays a deliberate keel rules promote at a terminal.
• No browser path. Onboarding changes attestations and config, which is capability-adjacent; the web console stays read-only for this (keel/capabilities.py, D3 — A GUI human gate, architecturally distinct from _is_interactive #436).
• Rail 14 wording. It is a monthly buy cap, not a fee waiver (Rail 14: the "fee-free allowance" is not fee-free on Advanced Trade -- relabel it a monthly buy cap, and re-scope what rests on the premise #836). The flow may check the planned spend against the cap, and must not call it fee-free.
• Off a TTY, the command prints what it would do and writes nothing.

Out of scope

• Promotion.
• Browser apply.
• Any change to the attestation schema or the admission criteria.