refactor!: remove ArkTS integration

- Drop ArkTS package, config, CLI diagnostic wiring, and linter setup
- Remove arkcompiler scenario harness and stale validation guidance
- Keep provider smoke and TUI validation helpers as focused release checks

Co-Authored-By: devagent <devagent@egavrin>

Author: egavrin

.agents/skills/add-feature-e2e/SKILL.md

@@ -15,11 +15,9 @@ Step-by-step guide for adding a feature to DevAgent, from understanding the code
    - **LLM provider** → `packages/providers/`
    - **CLI/prompt** → `packages/cli/`
    - **Machine execution contract** → `packages/executor/`
-   - **ArkTS integration** → `packages/arkts/`
 3. Decide whether this is also a public surface change:
    - **CLI/runtime/docs/help/prompt/session UX change** → pair with `surface-change-e2e`
    - **Provider or model-registry change** → pair with `provider-adapter-change`
-   - **Live validation coverage change** → pair with `live-validation-authoring`
    - **Executor contract change** → pair with `execute-contract`
 4. Read existing similar features to understand the pattern
 
@@ -31,7 +29,7 @@ Draft the approach before writing code:
 - Which modules need modification?
 - What's the wiring path (how does the feature connect to the rest)?
 - What tests will verify it works?
-- Which docs, help text, prompt assets, or live-validation scenarios need updating?
+- Which docs, help text, or prompt assets need updating?
 
 ## Phase 3: Types First
 
@@ -117,7 +115,7 @@ Write minimal code to make tests pass. Follow these patterns per package:
 If the feature changes human-facing behavior, do this before calling the work done:
 
 1. Reconcile README, `WORKFLOW.md`, command help, prompt assets, and nearby documentation tests.
-2. Decide whether the change needs a live-validation scenario update or a `release-matrix.md` update.
+2. Decide whether the change needs a validation helper update or a `release-matrix.md` update.
 3. Keep the public story aligned with the supported DevAgent surface; do not leave docs or help text behind the code.
 
 ## Phase 8: Integration Test
@@ -155,7 +153,7 @@ For packaging, install, or release-critical changes, escalate to:
 
 ```bash
 bun run test:bundle-smoke
-bun run test:live-validation
+bun run validate:live:provider-smoke
 ```
 
 Review your changes:
@@ -168,7 +166,7 @@ git diff            # Content review
 ## Module Dependency Rules
 
 ```
-runtime ← cli, executor, providers, arkts
+runtime ← cli, executor, providers
 providers ← cli
 runtime provides the internal task loop, review pipeline, and tool layer
 ```

.agents/skills/ci-triage-devagent/SKILL.md

@@ -30,7 +30,7 @@ Read `references/check-matrix.md` first. Pair with the GitHub CI skill if the fa
    - unit or integration test regression
    - OSS or docs drift
    - bundle or publish problem
-   - live-validation or provider-environment blocker
+   - validation-helper or provider-environment blocker
 3. Reproduce the narrowest failure locally.
    - Prefer package-local tests when the failure points at one package.
    - Use root commands for cross-package or release checks.
@@ -44,7 +44,7 @@ Read `references/check-matrix.md` first. Pair with the GitHub CI skill if the fa
 
 - Use `debug-test-failure` once the failing test is isolated.
 - Use `release-train` for publish or packaging failures.
-- Use `live-validation-authoring` when the failing CI path reflects stale live-validation coverage.
+- Use `validate-user-surface` when the failing CI path reflects stale release-validation coverage.
 
 ## Red Flags
 

.agents/skills/ci-triage-devagent/references/check-matrix.md

@@ -6,7 +6,7 @@
 | Package test failure | `cd packages/<pkg> && bun run test` | package that owns the failing file | Pair with `debug-test-failure` |
 | Docs or OSS drift | `bun run check:oss` | docs, README, package metadata, CLI docs | Check command-help tests when docs mention behavior |
 | Bundle or publish smoke | `bun run test:bundle-smoke` | packaging, bundle scripts, CLI install flow | Escalate to `release-train` |
-| Live-validation failure | `bun test scripts/live-validation/live-validation.test.ts` | scenario, runner, docs, or underlying feature | Distinguish provider/setup blockers from regressions |
-| Provider auth or network failures | provider-local tests first, then targeted live validation if needed | `packages/providers`, CLI config, doctor/auth flow | Missing credentials or external service availability should be reported as blockers |
+| Validation helper failure | Focused helper test or `--help` run | helper script, docs, or underlying feature | Distinguish provider/setup blockers from regressions |
+| Provider auth or network failures | provider-local tests first, then provider smoke if needed | `packages/providers`, CLI config, doctor/auth flow | Missing credentials or external service availability should be reported as blockers |
 
 Prefer one narrow repro command with a clear expected signal over a broad “run everything” pass.

.agents/skills/commit/SKILL.md

@@ -46,7 +46,6 @@ Derive from the package or module changed:
 - `fix(runtime):` — change in `packages/runtime`
 - `refactor(executor):` — change in `packages/executor`
 - `test(providers):` — change in `packages/providers`
-- `chore(arkts):` — change in `packages/arkts`
 - Omit scope for cross-cutting changes
 
 ## Body

.agents/skills/live-validation-authoring/SKILL.md

@@ -13,7 +13,7 @@ Use this skill when a task edits public documentation, contributor workflow, rel
 - Contributor guidance stays aligned with the current repo layout and verification commands.
 - Package metadata and top-level docs remain compatible with `scripts/check-oss.mjs`.
 - Root docs, `devagent help`, and nearby command/documentation tests stay aligned when public behavior changes.
-- When public commands, release-critical flows, or live-validation coverage changes, `.agents/skills/validate-user-surface/references/release-matrix.md` stays current.
+- When public commands, release-critical flows, or validation coverage changes, `.agents/skills/validate-user-surface/references/release-matrix.md` stays current.
 
 ## Primary Evidence
 
@@ -33,7 +33,7 @@ Use this skill when a task edits public documentation, contributor workflow, rel
 1. Read the docs and metadata you are changing plus `scripts/check-oss.mjs`.
 2. Remove or avoid references to unsupported surfaces, deprecated workflows, local machine paths, or stale package layout claims.
 3. If the change affects command help, CLI output, or other tested behavior, check the nearest command or documentation tests before making the claim.
-4. If the change adds or removes public commands, live-validation scenarios, or release-critical flows, update `release-matrix.md` or explicitly confirm that no matrix change is needed.
+4. If the change adds or removes public commands, validation helpers, or release-critical flows, update `release-matrix.md` or explicitly confirm that no matrix change is needed.
 5. Run `bun run check:oss` before finalizing, and pair it with `bun run typecheck` and `bun run test` when the change intersects executable behavior.
 
 ## Red Flags

.agents/skills/live-validation-authoring/references/scenario-matrix.md

@@ -4,7 +4,7 @@
 | --- | --- | --- | --- |
 | OpenAI-compatible transport, headers, proxy, streaming | `packages/providers/src/openai.ts`, `packages/providers/src/network.ts`, `packages/providers/src/shared.ts`, nearby tests | `cd packages/providers && bun run test`, `bun run typecheck` | CLI tests if provider config or doctor output changed |
 | Registry or provider availability | `packages/providers/src/index.ts`, `packages/providers/src/registry.ts`, `models/*.toml`, nearby tests | `cd packages/providers && bun run test`, `bun run typecheck` | `bun run check:oss` if docs or provider list changed |
-| Credential or auth expectation changes | Provider files plus CLI config or auth files | `cd packages/providers && bun run test`, `cd packages/cli && bun run test`, `bun run typecheck` | `security-checklist`; live validation for real auth flows |
+| Credential or auth expectation changes | Provider files plus CLI config or auth files | `cd packages/providers && bun run test`, `cd packages/cli && bun run test`, `bun run typecheck` | `security-checklist`; provider smoke for real auth flows |
 | Doctor or remediation copy changes | Provider files, `packages/cli/src/doctor.test.ts`, `README.md` | `cd packages/cli && bun run test`, `bun run check:oss` | `validate-user-surface` if the fix path is release-critical |
 
 Prefer provider-local tests first, then add cross-package verification only when the provider change is surfaced through the CLI or public docs.

.agents/skills/oss-surface-guard/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: release-train
-description: Run release-hardening work when a request says bundle smoke, release checks, packaging changes, install-flow drift, or pre-release readiness without needing the full live-validation sweep.
+description: Run release-hardening work when a request says bundle smoke, release checks, packaging changes, install-flow drift, or pre-release readiness.
 triggers:
   - bundle smoke
   - release checks
@@ -49,7 +49,7 @@ Read `package.json`, `scripts/bundle.ts`, `scripts/smoke-publish-bundle.ts`, and
 
 - Use `validate-user-surface` for full release-candidate validation, real provider coverage, or install/auth/TUI/executor end-to-end checks.
 - Use `oss-surface-guard` for doc-only public-surface drift.
-- Use `live-validation-authoring` when release-hardening uncovers missing scenario coverage.
+- Use `validate-user-surface` when release-hardening uncovers missing validation coverage.
 
 ## Red Flags
 

.agents/skills/provider-adapter-change/references/verification-matrix.md

@@ -37,20 +37,19 @@ Read `AGENTS.md`, then use `references/change-matrix.md` to scope the work.
    - Check README, `WORKFLOW.md`, command help, prompt assets, and documentation tests together.
    - Keep the public story aligned with the supported DevAgent surface.
 4. Decide whether validation coverage changes.
-   - If public behavior, command inventory, or release-critical flows changed, inspect `scripts/live-validation/` and `release-matrix.md`.
-   - If no scenario or matrix update is needed, say why in the final summary.
+   - If public behavior, command inventory, or release-critical flows changed, inspect `release-matrix.md` and the relevant focused tests or validation helpers.
+   - If no matrix update is needed, say why in the final summary.
 5. Run verification in two tiers.
    - First run the minimum checks from `references/change-matrix.md`.
-   - Then widen to `bun run check:oss`, bundle smoke, or live validation if the change is release-critical.
+   - Then widen to `bun run check:oss`, bundle smoke, or focused validation helpers if the change is release-critical.
 
 ## Escalate
 
 - Use `execute-contract` if the change touches `packages/executor` or the `devagent execute` contract.
-- Use `live-validation-authoring` if a scenario needs to be added, removed, or rewritten.
 - Use `release-train` for packaging, publish, install, or pre-release work.
 
 ## Red Flags
 
 - Updating `README.md` without checking `packages/cli/src/documentation.test.ts`.
 - Changing command behavior without checking help text or prompt assets.
-- Treating live validation as optional when the public contract changed materially.
+- Treating release validation as optional when the public contract changed materially.