fix(configure): accept bare org name for --org

[jamesadevine]

Problem

ado-aw configure --org myorg --project Foo --definition-ids 2506 fails because the bare org name is used verbatim as the ADO organization URL. Every API call ends up at myorg/Foo/_apis/build/definitions/..., which is malformed.

This bites users whose pipeline source lives in GitHub but whose pipeline runs in Azure DevOps. In that case parse_ado_remote correctly rejects the GitHub remote and falls through to the (None, Some(org), Some(project)) branch in resolve_ado_context, which stored --org's value unchanged.

It was also a footgun even with an ADO remote: the --org override branch did the same thing.

Fix

Add normalize_org_url(&str) -> String and apply it in both branches of resolve_ado_context. It:

• prefixes the canonical https://dev.azure.com/ host when a bare org name is passed (no scheme, no slash, no dot)
• rewrites the legacy {org}.visualstudio.com form to dev.azure.com/{org} for consistency with parse_ado_remote
• trims whitespace and trailing slashes
• leaves already-correct https://dev.azure.com/{org} URLs untouched

The CLI --org help text and docs/cli.md are updated to advertise that both forms are accepted.

Verification

After this change, the user's command works as expected:

ado-aw configure --org msazuresphere --project AgentPlayground --definition-ids 2506

is equivalent to

ado-aw configure --org https://dev.azure.com/msazuresphere --project AgentPlayground --definition-ids 2506

Tests

Five new unit tests in src/configure.rs cover:

• bare org name → canonical URL
• full URL passthrough
• trailing slash stripped
• legacy *.visualstudio.com rewrite
• whitespace trimming

All 23 tests in cargo test --bin ado-aw configure:: pass. cargo build is clean and no new clippy warnings are introduced in src/configure.rs.

[github-actions]

🔍 Rust PR Review

Summary: Looks good — clean, focused fix with solid tests and documentation.

Findings

⚠️ Suggestions

• src/configure.rs:666 — normalize_org_url is declared pub. Since tests live in the same file's mod tests, pub(crate) would be sufficient unless it's intentionally exported for external consumers. Minor visibility hygiene.

• src/configure.rs:671-677 — The bare-org guard (!contains('.') && !contains('/')) correctly rejects dotted hostnames. However, myorg.visualstudio.com (no https:// scheme) would fall through both branches and be returned as-is rather than rewritten. This is an undocumented gap: the schema rewrite only fires when url::Url::parse succeeds, which requires an explicit scheme. Worth either handling or noting in the doc comment as "scheme required for legacy form".

✅ What Looks Good

• The three-part guard for bare org names (no ://, no /, no .) is correct — ADO org names can't contain dots, so there's no false-positive risk.
• The visualstudio.com rewrite correctly delegates parsing to the url crate, avoids brittle string matching, and handles the trailing-slash variant (test confirmed).
• Applying normalize_org_url in both resolve_ado_context branches (override and no-remote fallback) closes the bug comprehensively.
• Five targeted unit tests cover all documented input forms; test names are clear and self-documenting.
• Doc comment accurately describes all transformations.

Generated by Rust PR Reviewer for issue #579 · ● 148.8K · ◷