ambleloftExecute, review and recover
Follow real dependencies across the host, SDK, sample, service, website and guides. Partners work in their assigned projects while you handle requests, inspect handoffs and decide whether deliveries are accepted.
Outcome: Handle requests from the graph, inspect evidence and accept delivery or record rework and recovery steps.
Before you begin: Use a desktop source build with the collaboration workbench. Prepare the model, experts and practice projects described below; check release notes for installer coverage.
On this page
01Open work from the graph
Open Tasks in the project space. Nodes show owners, projects, execution states and blocking reasons; arrows represent saved dependencies. Select a node to open its conversation, delivery review, instructions and history. Returning preserves the graph view. The graph supports inspection and navigation, not gesture-based plan editing.
02Check the plan before starting
Before starting, confirm the shared agreement and each node’s main project and permissions. The SDK, service and website wait for valid host acceptance. They may then proceed independently when resources and permissions allow. The sample waits until both SDK and service are accepted; the guide waits for sample acceptance. Managed tasks sharing a directory remain serialized, and runtime capacity limits concurrency. A finished run or a stale reference cannot satisfy acceptance.
03Handle input and approval requests
Open the relevant node from Overview or the graph. Inspect and answer the active question or approve or deny the specific request. If it cannot be read, refresh requests or open the full task instead of resending the whole assignment. Execution approval is separate from delivery acceptance. Before choosing full access, inspect its stated scope; existing pending requests are not automatically approved.
04Review the handoff, not just the reply
When a task is Awaiting review, open Delivery review and compare actual files and command results with acceptance criteria and downstream input needs. Record the conclusion and choose Accept delivery or Reject with reason. Acceptance participates in scheduling, but does not install or publish packages. Check that downstream work can obtain its inputs.
| Node | Evidence | Acceptance check |
|---|---|---|
| Host | Changed files, contract revision, test commands and results | Behavior matches the contract and limitations are stated. |
| SDK | Changes, pinned version or artifact location, compilation and contract tests | The sample has a defined way to obtain the matching artifact. |
| SSH service | Remote revision, independent tests, logs and deployment/start/stop steps | Target environment and scope are correct; unexecuted deployment is not marked passed. |
| Sample | SDK and service references, build commands and actual results | Interfaces agree and error paths are reproducible. |
| Website and guide | Capability copy, available-version links and complete steps | Claims match evidence and instructions reproduce the accepted sample. |
| Final integration | Version inventory, reproduction record and remaining gaps | Deliveries match the same change; screenshots are not treated as execution evidence. |
05Keep context during rework
For work awaiting review, submit Change requirements in the node workspace or record a rejection reason, then retry through the provided action. Original attempts and evidence remain available. If retrying will resume the whole plan, confirm that other eligible tasks may also proceed. Respect read-only restrictions on accepted work, historical attempts and archived spaces; further discussion is not implicit rework.
06Pause and recover after restart
Pausing stops new scheduling and requests interruption of active work. Existing file changes and business effects are not rolled back. After restarting the app, inspect retained results, remote processes and service state before resuming from the plan. Interrupted commands are not assumed to replay automatically. Pause and revise changed references or dependencies, then reassess stale tasks and their dependents.
07Make local and remote handoffs explicit
The SSH node runs the test service that an extension connects to. It does not move the host’s Node extension backend onto the server. The SDK, sample, website and guides keep their own directories and obtain dependencies through the reviewed handoff method. Clarify unknown ports, artifact paths and interface versions instead of letting the model guess. For a business-form entry point later, use the separate Skill Master and declarative UI guides.
Create a business entry point for verified capabilities08Keep reproducible acceptance records
Record each project’s version, execution environment, verification commands, artifact locations and unverified items. Retain original tasks, pinned references and review decisions for the next change. This exercise and promotional illustrations do not certify real SSH deployment. Windows, Docker, packaged builds and other external dependencies still need target-environment acceptance. The plan is complete only when every package has valid acceptance.
Check the result and troubleshoot
Handle requests from the graph, inspect evidence and accept delivery or record rework and recovery steps.
Check actual results using this page’s verification steps. For business integrations, inspect UI submission, tool receipts and server records separately.
Check states and recovery steps →