Skip to content

Keep maintainer tooling out of the student template #54

Description

@raghubetina

Outcome

Keep First Draft's maintainer-only testing and image-development machinery out of the student-facing Drawing Board template. Students receive the workspace and, after Compilation, their application; they should not inherit our tooling for testing those products.

Accepted direction from the owner discussion on 2026-09-24. Implementation has not started. Track under the emitted-code quality audit, Service #663; related workshop context is Drawing Board #43.

Problem and current evidence

Drawing Board currently combines the distributed starter workspace with its maintainer source, tests, and investigation reports. GitHub templates copy the repository's directory structure and files. Hiding those files in an editor, or archiving them under .firstdraft/design/ after Compilation, does not remove them from the initial student experience.

Source inspected at Drawing Board 296043d8928a6bed71fe548edcf68069aba9b905:

  • Ordinary CI runs source/configuration checks and the Dev Container installation smoke. The agent probes check installation/discovery without sign-in or a model request. The container smoke checks that Selenium remains stopped.
  • Image publication has separate published-image checks: AMD64 runtime and ARM64 metadata, not equivalent runtime proof.
  • script/application-smoke is an optional nested-application runner: it starts Selenium, runs the already-compiled app's setup, checks PostgreSQL/readiness, and invokes that app's own bin/ci. It does not define a separate Drawing Board browser-test suite. Ordinary CI skips this path because application/ is absent; it is not the root-Compilation workflow.

These checks may be useful without belonging in the distributed template.

Agreed responsibility boundary

Owner Contents
Student-facing Drawing Board Minimal devcontainer/bootstrap configuration, onboarding instructions, and the student's planning material.
Image/environment Installed tools and services, with necessary environment setup commands.
Compiled application Application source, ordinary development commands, and useful application-owned tests.
Maintainer tooling outside the distributed template Template tests, image-build/verification machinery, qualification runners, and investigation reports.

Inventory files by actual responsibility. Do not classify every script as a test: real installation, CLI configuration, and Codespaces lifecycle behavior still need an explicit working home. This does not require baking frequently updated agent releases into the image.

Implementation approach

Use existing CI to check out the exact template candidate into a disposable workspace, start its actual devcontainer, and run externally maintained checks against it. Mount or temporarily copy test code into that disposable environment only when execution inside the container requires it. Many checks can run from outside without modifying the template at all.

For application integration, materialize a representative application and run its normal setup and CI commands. Start Selenium when browser tests need it. Keep test-runner files outside the student artifact and retained planning archive; clean up only runner-owned resources.

Prefer moving maintainer-only material to existing First Draft maintainer tooling. Resolve the concrete repository and cross-repository CI wiring during implementation, preserving checks against the exact candidate revision. A new testing service or elaborate template-generation pipeline is not required by this decision.

Review test value while relocating: retain behavioral guarantees such as successful installation, preserved user state, credential handling, and application boot/tests. Reassess assertions that merely repeat exact source strings; retain meaningful compatibility/version checks. Do not delete useful application-owned tests as part of this cleanup.

Acceptance criteria

  • Inventory the current template and record the destination or removal of maintainer-only scripts, image-build inputs, workflows, receipts, and research documents; preserve material with a real student/runtime purpose.
  • A fresh student template checkout contains no maintainer test harness or investigation reports. Merely hiding or archiving those files is insufficient.
  • Maintainer CI still tests the exact Drawing Board candidate and selected image/tooling; required checks remain connected to template changes after relocation.
  • Execute the retained setup/discovery/container checks from outside the distributed template, preserving their actual proof boundaries.
  • Exercise normal root materialization and application setup/tests without depending on Drawing Board test helpers or .firstdraft/design/. Keep student design/Plan/notes available as optional context.
  • Update contributor, image-maintenance, and affected onboarding guidance to the new locations. Evaluate the optional nested-application runner separately from the primary root workflow.
  • Report exact source, local/container CI, provider qualification, and distribution evidence separately. Run any further paid Codespaces trial only under its own approved scope.

Related work and boundaries

  • Service #677 removed Compiler/Core-only contracts from generated applications. This issue applies the same ownership principle to Drawing Board's distributed template; it does not reopen that completed work.
  • Service #730 owns archive-independent continuation. Its merged attach fix is prior work, not evidence that the template is free of maintainer files.
  • Service #729 owns generated Compose/browser-startup qualification. Moving our tests does not resolve the observed Selenium session-start timeout or approve a timeout change, another paid trial, or a release.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions