About Stretch Lab

Repo inventory

1. Hello Robot standard reposThe local standard repo list, setup audit, branch state and workspace policy, kept as part of the operating model.

Why this helps

1. Decision makingCompare options, pull the right evidence from several repos, and turn that into a clear recommendation instead of relying on memory or scattered notes.
2. Security and privacySeparate production-sensitive work from demo-safe material and keep the workflow aligned with local-first LLM usage rules.
3. Manageable code parsingInstead of dropping an entire repo into context, break code into smaller sections, interfaces and records so the model stays focused and less error-prone.
4. Shared dashboard memoryOnce a result is useful it becomes a reusable artifact for the team, which reduces repeated discovery and makes future answers faster.

Local publishing guardrails

Stretch Lab runs on the lab machine and is reached over LAN or Tailscale, so sensitive engineering context stays on controlled internal machines instead of being published externally.

1. 1Local validation gateBefore sharing an update, run the data validator and build check so project data and routes stay consistent.
2. 2Privacy reviewCheck content for production-sensitive material, internal-only notes, and whether a view is safe for demos versus internal engineering use.
3. 3Tailscale accessThe shared URL is the lab-machine hostname on port 3417, with live services on their local bridge ports.
4. 4Internal audienceReports and Slack-ready artifacts should be usable by the team without prior Stretch Lab context.

How I use it

1. 1Collect workspace stateRead the dashboard manifests, data files, and nearby repos that matter for the question.in: _stretch_lab/data/*, stretch_body_ii, stretch_firmware_ii, nuc-powerd, stress-test-moduleout: relevant files, repo paths, source anchors
2. 2Normalize into a shared shapeTurn mixed inputs into records with project, topic, privacy, source, and freshness fields.in: project manifests, tasks, notes, code references, runtime responsesout: knowledge records, topic tags, retrieval keys
3. 3Retrieve only the slice neededBuild prompt context from the smallest set of records that answer the request.in: question intent, knowledge tags, source paths, privacy rulesout: focused prompt context, supporting evidence
4. 4Generate the responseAsk the LLM to summarize, compare, plan, or draft using the retrieved evidence.in: prompt context, task goal, allowed tooling policyout: draft answer, workflow summary, candidate updates
5. 5Verify and publish backCheck the draft against source files, then push the result into a page, board, or notes file.in: draft answer, source anchors, dashboard componentsout: presentation page, updated dashboard content, sharable LAN view

Data I consume

The main source groups that feed the dashboard and the LLM workflow.

How responses are produced

1. 1Intent framingMap the request to a project, artifact type, and output format such as summary, plan, issue triage, or wiki page.What is being asked?
2. 2Context assemblyPull in only the manifests, tasks, repo files, and runtime facts needed for the request while respecting privacy tiers.What evidence is allowed and relevant?
3. 3LLM synthesisThe model compresses the retrieved context into an explanation, recommendation, or workflow that a teammate can act on.What is the best supported answer?
4. 4Source groundingEvery important claim should trace back to a file path, repo, API response, or canonical JSON record.Can I point to where this came from?
5. 5PublicationThe result is added to the dashboard so the next teammate can consume the answer without repeating the whole discovery step.Where should the result live?

Proposed knowledge structure

The data structure for reusable LLM-ready knowledge: each record source-backed, privacy-aware, and easy to retrieve by project or topic.

Example knowledge record

A normalized record can represent a repo fact, a planning artifact or a runtime-derived observation.

{
  "record_id": "stretch_lab:workflow:llm-usage",
  "project_id": "stretch-4",
  "topic": "llm_workflow",
  "source_kind": "canonical_json",
  "source_path": "_stretch_lab/data/stretch-4/projects.json",
  "privacy": "sensitive",
  "freshness": {
    "updated_at": "2026-03-03T02:18:19Z",
    "verification": "source_checked"
  },
  "summary": "Stretch Lab uses local structured data plus local repos to build grounded LLM answers for engineering planning and dashboard publishing.",
  "entities": [
    "Stretch Lab",
    "stretch_body_ii",
    "stretch_firmware_ii",
    "nuc-powerd",
    "stress-test-module"
  ],
  "claims": [
    {
      "statement": "Project manifests define owner, privacy tier, and page routing.",
      "evidence": "_stretch_lab/data/*/project.json"
    },
    {
      "statement": "Task boards and notes provide execution state for summaries and next-step generation.",
      "evidence": "_stretch_lab/data/*/{tasks.json,notes.json}"
    }
  ],
  "actions": [
    "retrieve source files for the question",
    "assemble compact prompt context",
    "verify key claims against code or JSON",
    "publish the result back into the dashboard"
  ],
  "tags": [
    "llm",
    "knowledge-graph",
    "dashboard",
    "retrieval",
    "hello-robot"
  ]
}

What the team should know

1. 1Keep the workflow local-first: use the NUC-hosted tooling and local files as the primary evidence layer.
2. 2Prefer structured JSON and explicit repo paths over free-form memory when building context for an LLM.
3. 3Treat the dashboard as a publish layer for verified outputs, not just a place to brainstorm.
4. 4Store reusable knowledge in small records so the next prompt can retrieve them instead of rediscovering them.

Before anything is shared, the local data validator and build should pass; the shared URL is served from the lab machine over LAN or Tailscale. The repositories behind all of this are listed under Repos.