Install and qualify the Sales sampleLesson 1 of 6
Prepare a clean learning repository
Check tooling and separate approved distribution from a public installation assumption.
Confirm the learning boundary
The Sales lab begins in an approved learning checkout. Access to the core is a prerequisite. The local software has an MIT licence, but that does not establish a public repository, download URL or completed clean-install experience. Obtain the approved distribution through the owning process. Do not guess a repository address or turn an internal source path into a public installation instruction.
You need Node 24 or newer and Git. Fabric and source permissions are needed only for the optional live lab. The offline demonstrations described in this course make no Fabric request and need no Hosted account. Read the root README and the Analytical Spine overview in the approved checkout before selecting the route for your harness. Preserve technical command names even though this website uses the working brand Analytical Spine.
Protect an existing proof
A learning repository and a retained proof project have different purposes. A retained project already owns its catalogue, expectations and receipt history. Initialisation is for a new project. Do not initialise over an existing proof or treat its frozen expectations as disposable exercise material. Use the documented demonstrations, which work with their own temporary artifacts, for the offline steps.
Make a local worksheet containing only synthetic descriptions. Record the approved checkout's revision and the source-document date you reviewed. Use role names and non-executable placeholders where a future live lab would need private scope. Keep credentials, customer data and signing material out of the worksheet. Nothing in this lesson requests an external upload or a change to an existing customer project.
Inspect before installation
For a Codex target, the overview provides these read-only planning commands. Run them from the approved library checkout only after replacing the target placeholder using the reviewed learning manifest. The second command describes a proposed installation; it is not an apply operation.
node tools/agent-skills.mjs validate suites/analytics-spine.jsonnode tools/agent-skills.mjs plan suites/analytics-spine.json --target <target-repository> --profile full --agents openai-codexRead required parameters and target writes before considering separately documented apply and verify commands. Do not invent those commands from memory. The offline lab can proceed from the approved library checkout without applying a target installation. Installation itself never supplies consent to query a database or deploy into a workspace.
Check the expected outputs
The preparation step should leave you with an identified learning checkout, the required tools and a written route decision. It should not leave a fabricated passing gate, a new source connection or an external service account. In the next lessons, the dimensional-model demonstration produces temporary artifacts and removes them. The ledger regression exercise deliberately tests missing-evidence refusal. Knowing those expected outcomes prevents a successful script from being misreported as live proof.
| Preparation item | Record in the worksheet |
|---|---|
| Approved access | Which reviewed distribution you may use |
| Tooling | Node 24+ and Git available for the lab |
| Checkout | Revision and reviewed documentation date |
| Target plan | Required parameters and proposed writes, if inspected |
| Live scope | Explicitly unperformed during offline preparation |
Completion check
Explain why a free licence does not imply public distribution, why an existing proof must retain its own history, and why planning is separate from installation. Name the outputs you expect from preparation and mark live source access, Fabric execution and Hosted push as unperformed. You are ready to choose a harness when your worksheet describes an approved route without assuming permissions that have not been granted.