starter.wiki中文

Decision map

Developer workflow

How should contributors collaborate, reproduce development, validate changes, document and test APIs, publish packages, review deployments, and adopt reusable project foundations?

Recommendation

Start with Git Repository Hosting

Software teams choosing repository collaboration, automation, testing and static analysis, API workflows, package distribution, reproducible development, cloud emulation, preview deployment, and starter-code ownership.

Open the starting decision

Scope

Use this boundary to avoid solving adjacent problems in the wrong layer.

Included

  • Hosted or self-hosted Git repository collaboration and governance
  • Continuous integration, delivery, and deployment workflow automation
  • Dynamic testing, API testing, API documentation, linting, and non-security static analysis
  • Package registry publication, access, provenance, and consumption
  • Reproducible development environments and local cloud-service emulation
  • Remote preview environments and reusable SaaS starting repositories

Excluded

  • Production hosting, container orchestration, and infrastructure provisioning
  • Security-focused vulnerability scanning and security finding triage
  • General editorial content management and end-user documentation
  • Starter Stack composition as a substitute for a concrete source-code boilerplate
135813151920

Important tools

These tools represent distinct routes inside this decision area; open the relevant Task before treating any as a default.

Decision sequence

Make the foundational ownership decisions before adding specialized capabilities.

  1. Where will source live and how will contributors access, review, merge, govern, and audit changes?

    Choose Git Repository Hosting before binding pipeline, package, or preview workflows to provider-specific integrations.

    Git Repository Hosting

  2. What toolchain and external cloud-service behavior must contributors reproduce before committing changes?

    Use Development Environments for workspace and toolchain reproducibility; add Local Cloud Emulation only for required cloud service APIs and document fidelity gaps.

    Development Environments Local Cloud Emulation

  3. Which defects require static inspection, executed tests, or specialist API workflows?

    Linters & Static Analysis inspects code without execution, Testing executes code or behavior, and API Testing exercises API contracts and environments.

    Linters & Static Analysis Testing API Testing

  4. What API description is authoritative and which reusable packages must be published and governed?

    Keep API Documentation synchronized with the contract and define package versioning, access, provenance, immutability, and retention.

    API Documentation Package Registry

  5. Which checks, artifacts, environments, approvals, and promotions should run for each change?

    Use CI/CD to automate reliable local commands, and Preview Environments for deployed, shareable, isolated change review.

    CI/CD Preview Environments

  6. Should the project adopt and maintain a prebuilt SaaS code foundation?

    Evaluate SaaS Boilerplates as owned source code with architecture, dependencies, licensing, customization, security, and upgrade obligations rather than as a conceptual stack.

    SaaS Boilerplates

135713151920

Decision groups

Each Task owns a distinct user decision rather than a product feature label.

Source collaboration and automation

Repository ownership establishes the source boundary; CI/CD then automates repeatable validation, packaging, and delivery.

Review environments and project foundations

Preview deployments support change review, while SaaS Boilerplates supply concrete source code with long-term ownership and maintenance obligations.

135713151920

Common confusions

These boundaries prevent adjacent Tasks from collapsing into one generic shortlist.

Treating Git commands and repository hosting as the same decision.
Git is distributed revision control; Git Repository Hosting adds remote availability, identity and access, collaboration, review, integrations, and governance.
Treating linting, static analysis, and executed tests as interchangeable quality evidence.
Linters & Static Analysis inspect code without execution; Testing executes code or behavior and asserts outcomes.
Treating a machine-readable API description as proof that the implementation behaves correctly.
API Documentation describes and publishes the contract; API Testing exercises the implementation against expectations.
Treating a reproducible development workspace and local cloud-service emulation as one Local Development product decision.
Development Environments reproduce toolchains and workspace configuration; Local Cloud Emulation reproduces selected cloud APIs and behavior.
Treating local service emulation and deployed branch review as the same pre-production environment.
Local Cloud Emulation runs locally or in CI; Preview Environments are remote, deployed, shareable instances.
Treating a concrete starting repository and a curated architecture or tool combination as the same artifact.
SaaS Boilerplates provide source code with maintenance obligations; Starter Stacks recommend composition and do not need to ship a codebase.
57815171920

What to defer

Do not add specialized identity systems before the product has the requirement they serve.

The application has no cloud-service dependency that must be exercised locally or in CI, or remote integration tests are sufficient.

Emulation adds setup and fidelity risk and should follow a concrete cloud-service testing requirement.

Changes do not require live collaborative review, isolated remote configuration, or stakeholder QA before production.

Preview deployments add environment, data, access, cleanup, and cost responsibilities.

The team does not publish reusable versioned packages outside the current repository.

A registry publication workflow is unnecessary until packages have external or cross-repository consumers.

The team is not evaluating a prebuilt source foundation or has already committed to a greenfield architecture.

Boilerplate selection is a source-ownership and maintenance decision, not a mandatory step in every developer workflow.

13171920

Related starter stacks

See how these decisions appear inside complete application starting points.

Authoritative resources

Standards and primary documentation supporting the Category boundaries.

official-documentationGit User's Manual
official-documentationVercel Environments

Sources

Claim-level references used for this decision map.

  1. 1
    Git User's Manual

    Git · Accessed Official

  2. 2
    About Git

    GitHub · Accessed Official

  3. 3
    Continuous integration with GitHub Actions

    GitHub · Accessed Official

  4. 4
    Building and testing Node.js

    GitHub · Accessed Official

  5. 5
    Writing tests

    Vitest · Accessed Official

  6. 6
    Playwright best practices

    Playwright · Accessed Official

  7. 7
    Learn OpenAPI: The OpenAPI Specification

    OpenAPI Initiative · Accessed Official

  8. 8
    ESLint core concepts

    ESLint · Accessed Official

  9. 9
    ESLint glossary

    ESLint · Accessed Official

  10. 10
    Biome Linter

    Biome · Accessed Official

  11. 11
    Introduction to quality gates

    SonarSource · Accessed Official

  12. 12
    Code scanning with CodeQL

    GitHub · Accessed Official

  13. 13
    npm registry

    npm · Accessed Official

  14. 14
    npm publish

    npm · Accessed Official

  15. 15
    Development Containers specification

    Development Containers · Accessed Official

  16. 16
    Create a development container

    Microsoft · Accessed Official

  17. 17
    LocalStack documentation

    LocalStack · Accessed Official

  18. 18
    AWS SAM CLI

    AWS · Accessed Official

  19. 19
    Vercel Environments

    Vercel · Accessed Official

  20. 20
    Creating a repository from a template

    GitHub · Accessed Official