fix(sell): accept --yes / -y as aliases for --force on sell delete

[bussyjd]

Summary

obol sell delete <name> -n <ns> only accepted --force / -f to skip the confirmation prompt. The conventional non-interactive flags --yes and -y were rejected outright:

$ obol sell delete aeon -n llm --yes
Incorrect Usage: flag provided but not defined: -yes
✗ flag provided but not defined: -yes

This blocks scripted teardowns and surprises operators muscle-memoried on -y. Surfaced on spark2 today while tearing down an offer between two flow runs.

Fix: add y, yes as aliases on the existing --force BoolFlag. Same runtime path, just more accepted surface.

Scope

Intentionally narrow to sell delete because that is what surfaced. Several other places also gate destructive commands on --force without -y:

• obol stack purge -f
• obol agent delete --force
• obol app delete --force
• obol network remove --force

A consistency pass across all of them is a reasonable follow-up; I left it out here to keep the PR scoped to a single confirmed regression.

Test plan

• obol sell delete --help now lists --force, -f, -y, --yes.
• go build ./... clean.
• Manual: obol sell delete aeon -n llm --yes and -y both run without the "flag not defined" error.

Full report (PR template) added as the first comment.

[bussyjd]

Summary

What changed: cmd/obol/sell.go adds y, yes as aliases on the --force BoolFlag for obol sell delete. No runtime path change — just additional accepted flag names.

Why it matters: scripted teardowns and operators muscle-memoried on -y were rejected with Incorrect Usage: flag provided but not defined: -yes. Adding the conventional names to the same flag closes the regression with zero behaviour change.

Risk level: low

Commit under test: tip of fix/sell-delete-yes-alias (2eee76b)

Base branch: main

Scope

• Code
• Charts / manifests
• Flows / QA scripts
• Docs / skills
• Images / dependencies
• Other:

Validation

CI checks:

Check	Status	Link
GitHub Actions CI	pending	(set by PR open)

Unit tests:

n/a — flag aliasing is wholly inside urfave/cli/v3 and is not the unit under test here. urfave/cli has its own coverage of multi-alias resolution.

Integration tests:

$ go run ./cmd/obol sell delete --help
…
   --force, -f, -y, --yes         Skip confirmation (aliases: -f, -y, --yes)

Flow tests:

Flow	Network	QA machine label	Worktree	Result	Artifacts
(none — additive flag; no flow impact)

Release smoke:

n/a — flag surface change only.

Live Chain Evidence

n/a — obol sell delete does call into the chain via ERC-8004 deactivation, but this PR does not alter that path; only the confirmation gating.

Runtime Evidence

QA environment:

Item	Value
OS / arch	linux/arm64 (Ubuntu 24.04.4 LTS on NVIDIA GB10)
Backend	k3d, dev mode
Tool versions	obol@dev (go run wrapper at fix/sell-delete-yes-alias)

Images: n/a

Kubernetes / stack:

Item	Value
Stack IDs	merry-troll
Namespaces	llm
Pod readiness	unchanged by this PR
Cleanup result	sell delete with -y removes ServiceOffer/Service/Endpoints as before

Model and routing: n/a

Artifacts and logs:

Artifact	Location / link	Notes
help output	inline above	shows the new aliases

Demo readiness:

Item	Status	Notes
Seller visible / registered	unchanged
Buyer discovery works	unchanged
Paid route works	unchanged
Settlement visible on-chain	unchanged

Review Notes

Known gaps:

• No new test. The change is one-line flag metadata; urfave/cli covers the resolution semantics. Open to adding a CLI-level smoke test if the project wants one.

Follow-ups:

• Apply the same alias treatment to other destructive --force callers: obol stack purge, obol agent delete, obol app delete, obol network remove. Skipped here to keep the PR scoped to the confirmed regression.

Reviewer focus:

• Is --force the right canonical name vs --yes? I kept --force to avoid breaking existing scripts; --yes/-y are pure additions.