Feat/studio vibe agent

.gitattributes

@@ -0,0 +1,2 @@
+# Minified build artifacts can contain semantic whitespace inside template literals.
+veadk/webui/assets/*.js -whitespace

frontend/README.md

@@ -28,6 +28,24 @@ server that `veadk frontend` launches — no separate backend.
   AgentKit. Connected Harness agents expose supported image, video, and
   presentation task types; Studio mounts only missing task tools for the
   current session and preserves tools already supplied by the Agent.
+- **Intelligent Agent development**: describe the intended VeADK Agent once and
+  receive immediate, cancellable preparation feedback before the development
+  conversation opens. Studio then automatically runs intent gating,
+  implementation, local checks, a temporary cloud deployment, acceptance calls,
+  log inspection, and cleanup.
+  Public Codex reasoning updates and Assistant replies use the normal
+  conversation renderer; credentials, raw Sandbox paths, and internal commands
+  stay hidden. Each build appears in the shared conversation history for the
+  lifetime of its remote development environment (up to eight hours); reopening
+  it restores the latest conversation and current source-delivery card.
+  Navigating away from an active build requires confirmation and stops that
+  build before leaving, while the conversation remains available until expiry.
+  Stopping preserves received output and blocks the next submission until
+  cleanup finishes. Users can inspect generated text files and download the
+  complete ZIP (including binary assets) as soon as the source is ready.
+  Deployable source can be sent to Runtime manually; an incomplete verification
+  report requires an explicit confirmation. No separate “start verification”
+  action is required.
 - **Reasoning & tool calls** shown inline (collapsible "thinking", tool blocks).
 - **Agent context rail** keeps the selected Agent's description, model, tools,
   skills, and optional live multi-Agent topology together in the conversation's

frontend/public/coding-agent-skills/veadk-agent-development/references/agentkit-delivery.md

@@ -0,0 +1,157 @@
+# AgentKit Delivery
+
+Use the installed AgentKit CLI directly to validate the current working tree in a temporary
+cloud Runtime.
+
+## Task environment
+
+Verify these environment facts at runtime instead of inventing values:
+
+- `ak` and `agentkit` are installed;
+- the current working directory contains the intended project;
+- task-scoped cloud credentials are available outside the deliverable project;
+- production deployment remains a separate user-confirmed action.
+
+## Credentials
+
+Use the task-provided credential mechanism exactly as task context describes. Never open a
+credential file to inspect values and never echo the environment. Keep credential material
+outside the project and Artifact. Do not pass AK/SK as CLI flags because they
+can leak through process listings, command history, tool traces, or Thread output.
+
+If the credential contract is absent or invalid, finish safe local checks and report cloud
+validation as blocked. Do not search home directories for alternative credentials.
+
+## Verify the installed CLI
+
+Before cloud work, run non-secret discovery commands such as:
+
+```bash
+ak --version
+ak --help
+ak init --help
+ak init --list-templates
+ak config --help
+ak build --help
+ak deploy --help
+ak status --help
+ak invoke run --help
+ak runtime show --help
+ak runtime logs --help
+ak runtime delete --help
+```
+
+The reviewed environment currently exposes AgentKit CLI `0.52.1`, where `ak init` provides
+version-aligned project templates and the project flow supports `ak config`, `ak build`,
+`ak deploy`, `ak status`, `ak invoke run`, and Runtime show/log/delete commands. Treat this as
+a reviewed baseline only; follow actual help when the installed version differs.
+
+The CLI also exposes higher-level developer capabilities such as lifecycle `launch`/`release`,
+datasets and evaluation, knowledge and memory resources, MCP, and Skill management.
+Select these from the accepted product requirements, not from a fixed showcase checklist.
+Prefer the smallest observable workflow: for example, do not provision a knowledge base when a
+deterministic local corpus satisfies the contract, and do not run an evaluation campaign when a
+small set of representative acceptance invokes is sufficient. Conversely, when quality targets
+explicitly require a dataset or scored evaluation, use the installed `ak dataset`/`ak eval`
+help and preserve its sanitized result as additional evidence.
+
+## Prepare a validation attempt
+
+Before spending a cloud attempt:
+
+1. require relevant local tests and the exact process-level `/ping` probe to pass;
+2. inspect the recursive Artifact inventory, not only ignore patterns;
+3. require a valid project-root `agentkit.yaml` and verify its entry point exists;
+4. choose a unique validation Runtime name derived from the task/session and attempt number;
+5. ensure the name cannot collide with a production Runtime;
+6. record the working-tree state that the attempt validates.
+
+Keep the AgentKit control-plane project separate from that unique Runtime identity. Use the
+existing validation project supplied by task configuration (normally `default`) and set
+`launch_types.cloud.project_name` to that exact value. Never derive `project_name` from the
+validation Runtime, image repository, pipeline, or Agent name. Confirm the effective value with
+the installed CLI before build. A `CreateRegistry: NotFound.Project` response means the project
+configuration is wrong or unavailable; it is not evidence of missing IAM permission. Correct
+the configuration and restart the complete attempt rather than asking for broader credentials.
+
+Do not mutate an unrelated Runtime. Use at most two attempts for one accepted user change.
+
+## Complete one cloud attempt
+
+Use the flags proven by current help. A typical `0.52.1` project flow is:
+
+```bash
+ak config --runtime_name <unique-validation-name>
+ak build --config-file agentkit.yaml
+ak deploy --config-file agentkit.yaml
+ak status --config-file agentkit.yaml --verbose
+ak invoke run --config-file agentkit.yaml --payload '<json>' --raw
+ak runtime logs <runtime-id-or-name> --limit 200 --json
+ak runtime delete <runtime-id-or-name> --yes
+```
+
+These commands are examples of the reviewed version, not permission to skip `--help`. Use the
+credential launcher for commands that require cloud access. Never include credential values
+in the command line.
+
+Poll readiness with a bounded deadline. Preserve only bounded, sanitized output. Run enough
+representative invokes to cover the material acceptance criteria; `/ping` or Runtime `Ready`
+alone is insufficient.
+
+Inspect logs for startup, authentication, model, tool, state, request, crash, timeout, and
+secret-exposure failures. A warning is non-blocking only when it does not violate intended
+behavior, safety, or trace requirements.
+
+## Repair and full revalidation
+
+On the first code/configuration failure:
+
+1. retain the failed stage and sanitized evidence;
+2. reconcile and delete the failed validation Runtime;
+3. identify and repair the smallest evidence-backed cause;
+4. rerun affected local tests and the exact service probe;
+5. select a new validation Runtime identity;
+6. rerun the complete cloud sequence beginning with `build`.
+
+Do not reuse a previously built Artifact after source/configuration changes. Do not perform a
+third cloud attempt for the same accepted change.
+
+For a deploy timeout or malformed remote response, the Runtime may still exist. Query by the
+unique validation name before deciding whether to retry or delete. If existence or cleanup
+cannot be established, return `indeterminate` rather than claiming failure or success.
+
+## Resume after user interruption
+
+Stopping a reply interrupts the current turn; it does not prove that the last local process or
+cloud write rolled back. On the next accepted message in the same conversation:
+
+1. inspect the current working tree and retain coherent source changes instead of reinitializing;
+2. treat the interrupted command and prior completion evidence as incomplete;
+3. query every validation Runtime identity already used by the interrupted turn;
+4. delete the Runtime or prove it absent before starting another cloud attempt;
+5. rerun the affected local checks and, after any source/configuration change, the complete
+   cloud sequence from build through cleanup.
+
+If the interrupted turn had already started a cloud deployment, count that real attempt when
+applying the two-attempt limit for the same accepted change. A new follow-up requirement starts
+a new acceptance cycle, but it still must reconcile resources left by the previous cycle. Never
+claim that the interruption itself cleaned a Runtime, and never discard a valid working tree only
+to make recovery simpler.
+
+## Completion evidence
+
+Cloud validation is complete only when the current source has evidence for:
+
+- successful build and deploy;
+- a fresh Runtime reaching `Ready`;
+- representative invoke results satisfying current acceptance criteria;
+- bounded logs with no blocking error;
+- deletion or confirmed absence of the validation Runtime.
+
+After the final successful build begins, do not change deliverable source unless you invalidate
+that attempt and run the complete cloud sequence again. AgentKit CLI currently archives its
+build context in memory and uploads it directly; do not invent or search for a local `ak build`
+archive path. Leave the verified working tree unchanged and report it as the deliverable.
+
+The validation Runtime is temporary evidence, not the production service. Preserve the
+project and sanitized evidence; leave production deployment to the user.

frontend/public/coding-agent-skills/veadk-agent-development/references/architecture-and-components.md

@@ -0,0 +1,89 @@
+# VeADK Architecture and Components
+
+Choose components from observable user requirements, then verify exact APIs against the target VeADK version. Patterns below guide design but do not override an existing valid project structure.
+
+## Minimal architecture
+
+A minimal local Agent commonly has an `Agent`, a `Runner`, and a stable application identity:
+
+```python
+import asyncio
+
+from veadk import Agent, Runner
+
+root_agent = Agent(
+    name="assistant",
+    instruction="Answer accurately and state uncertainty.",
+)
+runner = Runner(agent=root_agent, app_name="assistant")
+
+result = asyncio.run(
+    runner.run(
+        messages="Hello",
+        user_id="local_user",
+        session_id="local_session",
+    )
+)
+print(result)
+```
+
+Verify constructor fields and `Runner.run` semantics against the installed version before use.
+
+## Topology selection
+
+| Requirement | Likely shape | Required contract |
+|---|---|---|
+| One reasoning context and a small tool set | one `Agent` | instruction, tool schemas, final output |
+| Fixed ordered stages | `SequentialAgent` | stage inputs/outputs and failure policy |
+| Independent branches | `ParallelAgent` | branch isolation, aggregation, partial-failure policy |
+| Measurable bounded repetition | `LoopAgent` | exit criterion and maximum iterations |
+| Dynamic specialist transfer | root Agent with `sub_agents` | distinct descriptions, transfer and permission boundaries |
+
+Prefer one Agent unless another shape solves a real control-flow requirement. Do not split a simple prompt into cosmetic roles. Parallel branches must not mutate shared resources without coordination, and loops must have a measurable bound.
+
+For deterministic workflows, define producer, consumer, key/schema, missing-data behavior, retry safety and aggregation rules. Verify session-state and `output_key` APIs in the target version.
+
+## Function tools
+
+Use a typed function for deterministic local behavior:
+
+```python
+def get_city_weather(city: str) -> dict[str, str]:
+    """Return the current weather summary for a city."""
+    return {"result": f"Sunny in {city}"}
+```
+
+The signature and docstring are model-facing contracts. Validate untrusted inputs and test the function directly before testing model tool selection.
+
+`veadk.tools.get_builtin_tool(name)` accepts only registered names. Inspect `list_builtin_tools()` or the target version's registry before using a string name. A module's presence alone does not prove registry support.
+
+Use MCP only when a capability already has that contract or requires independent discovery. Verify endpoint, authentication, network reachability, tool listing, timeout and failure behavior; expose only necessary actions.
+
+## State and knowledge
+
+| Need | VeADK concept | Verification focus |
+|---|---|---|
+| Continue one conversation | `ShortTermMemory` / session service | app, user and session identity; restart behavior |
+| Recall approved cross-session facts | `LongTermMemory` | save timing, consent, retention, deletion and tenant isolation |
+| Search stable domain material | `KnowledgeBase` | ingestion, retrieval relevance, citations and tenant isolation |
+| Pass workflow data | session state / explicit output contract | schema, missing values and retry behavior |
+
+Attaching retrieval does not prove writes or indexing work. Test save and retrieval directly, then run an Agent-level request. For knowledge retrieval, include one answerable and one unanswerable query and verify source handling.
+
+## Models and structured output
+
+Verify model names, providers, endpoint fields, structured-output support, fallback behavior and credentials in the target version. Never copy fields from an unpinned newer example into an older dependency.
+
+When output is machine-consumed, validate it against the declared schema and define behavior for invalid model output. Remote model and tool calls need timeouts, an explicit failure policy and logs that do not reveal secret or unnecessary user content.
+
+## Component evidence
+
+For each nontrivial component, identify:
+
+1. target-version import and constructor;
+2. non-secret configuration names;
+3. automatic or explicit Agent exposure;
+4. external effects and permission boundary;
+5. smallest direct test;
+6. Agent-level integration test;
+7. timeout, failure and observability behavior.