Skip to content

Translation

Translated from the Spanish source, which is the normative text. Status: draft pending human review. Differences are resolved in the Spanish text.

Templates

This page gathers one template for each open format in the requirements, plus a declaration of environments and one of the branching model. Each is filled in with a fictional example: Ana's online shop and its item TIE-12, "export orders to CSV".

How to use them

  • No serialisation is mandatory. The blocks use a key-and-value notation (generic YAML) only to be readable; a task manager, a file in the repository or a spreadsheet can hold the same fields.
  • The fields are the minimums of the requirements. A project may add others; it may not omit the required ones when the requirement applies.
  • The data are fictional. No real emails, names or secrets are copied; the values of digests, dates and people are invented. Addresses use the reserved domain .invalid.
  • Publishing a template creates no obligations and approves no profile. A filled-in template documents a declaration; it does not show that it is true or that the work is good.
  • What is not known is written as unknown or hypothesis, not as data.

For the complete cycle, see the project cycle, work and cadence, branches, environments and releases and crews.

Project charter

Format of R-019. The product owner completes it before the first feature batch.

project_charter:
  version: 1.0
  date: 2026-10-01
  goal: Sell handicrafts online with nationwide shipping.
  problem: Today orders are kept in a spreadsheet and orders get lost.
  scope: Catalogue, cart, payment, orders and order export.
  exclusions: International shipping; mobile app.
  owners:
    product: Ana
    coordination: Ana
    technical: Ana
    delivery: Ana
  critical_effects_catalogue:
    - deploying to production
    - payments or transfers
    - deleting data (for example, deleting orders)
    - permission changes
    - publishing or sending to third parties (for example, emails to real customers)
    - decisions that affect people
  data_restrictions:
    - Real customer data exist only in production.
    - All other environments use synthetic data.
  success_criterion: Every order received appears in the order list in under a minute.
  change_history:
    - {version: 1.0, date: 2026-10-01, decided_by: Ana, reason: initial version}

Baseline survey

Format of R-020, for adopting SCAFFOLD over existing work. Each item is a fact with a source or a hypothesis.

baseline_survey:
  date: 2026-10-02
  repositories:
    - {name: shop, data: fact, source: service repository list}
  environments:
    - {name: production, data: fact, source: hosting provider dashboard}
    - {name: testing, data: hypothesis, note: Ana believes it exists; not verified}
  checks:
    - {name: automated tests, latest_result: 3 of 40 fail, data: fact, source: run of 2026-10-02}
  versions_in_use:
    - {component: shop, version: unknown}
  owners: [{area: payments, owner: Ana, data: fact, source: Ana}]
  debt_and_risks:
    - {description: no tested backup, data: hypothesis}
  work_in_progress:
    - {description: export orders, destination: item TIE-12}
    - {description: homepage redesign, destination: discarded, reason: outside the scope of the charter}

Work item

Format of R-021 with the state of R-023. The states are propuesto (proposed), listo (ready), en_curso (in progress), en_revisión (in review), terminado (done) or descartado (discarded); it is a scheme of its own, distinct from that of a batch or a note.

work_item:
  identifier: TIE-12
  type: feature            # initiative, feature, fix, restructuring, investigation or another declared type
  goal: Export orders to CSV.
  acceptance_criteria:
    - The file includes order number, date, total and status.
    - With 1000 test orders the file is generated without error.
  owner: Ana
  state: en_curso          # in progress
  parent: TIE-3            # or none
  dependencies: []
  batches: [L-2026-014]
  branches: [feature/TIE-12-export-csv]
  changes: [references in the messages with the trailer Refs: TIE-12]
  release: pending

Integration request

Format of R-025 and R-026.

integration_request:
  item_or_batch: TIE-12 / L-2026-014
  branch: feature/TIE-12-export-csv
  owner: Ana
  assistants_involved: [code-assistant, testing-assistant]
  checks:
    - {name: automated tests, result: pass}
    - {name: contract and code versions match, result: pass}
    - {name: exclusion of the engineering layer, result: pass}
  human_reviewer: Beto
  critical_effects_touched: none

Deployment record

Format of R-027 and R-028.

deployment_record:
  version: 1.4.0
  artefact_digest: sha256:fictional-example-0f3a   # the real digest is calculated by the build tool
  environment: production
  authorised_by: Ana
  checks: [automated tests, exclusion of the engineering layer]
  rollback_plan: Return to the artefact of version 1.3.2; the export does not change data.
  result: successful
  time: 2030-03-04T16:20:00-06:00   # fictional example date

Release note

Format of R-029. The list of items is obtained from the work items, not written from memory.

release_note:
  version: 1.4.0
  tag: v1.4.0              # immutable once published
  items_included:
    - {id: TIE-12, title: Export orders to CSV}
    - {id: TIE-31, title: Fix rounding of totals}
  incompatible_changes: none
  authorised_by: Ana
  date: 2030-03-04         # fictional example date

Crew record

Format of R-030.

crew_record:
  name: Exports
  owner: Ana
  members:
    people: [Beto]
    agents:
      - name: code-assistant
        profile: writes code in the crew's zones
        scope: [src/export/]
        budget: unknown   # the data is recorded once measured
        supervisor: Beto
      - name: testing-assistant
        profile: writes tests
        scope: [tests/]
        budget: unknown
        supervisor: Beto
  zones: {src/export/: code-assistant, tests/: testing-assistant}
  work_types_accepted: [feature, fix]

Declaration of environments

Fields of R-027. The classification scale in the example is fictional (public, internal, confidential, critical; from lowest to highest) and the project declares its own (MILPA-R-003). Synthetic or anonymised data are a practice, not levels of the scale.

environments:
  - name: local
    purpose: develop and test
    maximum_value_admitted: public   # synthetic data
    origin_of_secrets: own, with no real value
    who_deploys: whoever is working
    entry_checks: none
  - name: integration
    purpose: automated checks on each branch
    maximum_value_admitted: public   # synthetic data
    origin_of_secrets: project secrets store, own
    who_deploys: continuous integration process
    entry_checks: automated tests
  - name: staging
    purpose: test the candidate release
    maximum_value_admitted: internal   # anonymised data
    origin_of_secrets: own, different from production
    who_deploys: delivery owner
    entry_checks: integration tests
  - name: production
    purpose: serve users
    maximum_value_admitted: critical
    origin_of_secrets: own, accessible only to the deployment process
    who_deploys: delivery owner, with informed confirmation
    entry_checks: artefact with the checked digest; rollback plan

Declaration of the branching model

Fields of R-026 and naming convention of R-025.

branching_model:
  main_branch: main
  protection: changed only through an integration request reviewed by a person
  branch_types:
    - {prefix: feature/, pattern: "feature/<id>-<summary>", example: feature/TIE-12-export-csv}
    - {prefix: fix/, pattern: "fix/<id>-<summary>", example: fix/TIE-31-rounding-of-totals}
  maximum_lifetime: 3 working days
  one_branch_per_batch: yes
  who_integrates: Ana or the person she designates; an assistant does not write to the main branch except through an integration request reviewed by a person; integrating what is catalogued as critical is decided by a person
  checks_before_integrating: [automated tests, version synchrony, exclusion of the engineering layer]
  turn_on_shared_branch: no shared branch declared
  attribution_in_changes:
    mechanism: trailers at the end of the message (key: value)
    keys: [Refs, Batch, Co-authored-by, Responsible]

Limits

The templates do not replace the requirements: if a template and a requirement differ, the requirement governs. That a file has all its fields does not show quality or truthfulness (residual risks of the records cited). The verification that would promote these example templates to a verified guide would be to fill them in on a real project and record which fields were missing or superfluous (Hypothesis until then).

Back to SCAFFOLD.