Coleções e Blueprints

Coleções

Uma coleção é uma pasta na raiz que contém Blueprints (planos) de um mesmo tipo que compartilham um template (modelo) de corpo. O Framework (a estrutura) declara cada uma sob folders com owned_by: "@eidos/collections", o único tipo de pasta que o padrão possui. O Eidos não nomeia nenhuma: specs, chapters, investigations, decisions são todas palavras do seu Framework.

Uma coleção é plana ou agrupada. Agrupada, ela guarda os seus Blueprints em um nível de subpastas, cada uma um grupo declarado, e um grupo contém Blueprints e nada mais fundo. Ela também pode declarar uma propriedade que nomeia o agrupamento (domain na semente software). O valor bate exatamente com o nome da pasta; um valor desconhecido avisa em vez de bloquear.

Directoryspecs/
- Directoryplayback/ um grupo
  - watch-a-video.md
  - resume-playback.md
- Directorychannels/
  - subscribe-to-a-channel.md

Um arquivo dentro de uma coleção que não seja markdown não é um Blueprint. Os arquivos que os Blueprints linkam pertencem a uma pasta sua na raiz, declarada sem dono (as sementes trazem uma chamada assets), ou a uma pasta que uma ferramenta possui e guarda para você.

Blueprints

Um Blueprint é um arquivo markdown que define uma unidade por completo. Duas partes:

---
id: resume-playback            ← frontmatter: the agreement
title: Resume Playback
summary: Returns a viewer to the exact second they stopped.
status: In Progress
domain: playback
---

# Resume Playback                ← body: the template

## Intent
…

O frontmatter é o acordo; o corpo é orientação. As propriedades são verificadas contra a tabela de propriedades do Framework. As seções do corpo são recomendadas: uma que falte é anotada e oferecida, nunca recusada.

O frontmatter é gerado a partir das propriedades que se aplicam à coleção do Blueprint, então um Blueprint novo nasce conforme e uma propriedade restrita a uma coleção nunca cai em outra.

Um Blueprint, uma unidade

A pergunta difícil é sempre “isto é um Blueprint ou dois?”. O teste vive no template: um template nomeia a própria parte estável. Na semente software é ## Intent. Se o porquê muda substancialmente, você tem um Blueprint novo. Se só os comportamentos mudam, você tem uma edição.

Blueprints não são tarefas

Sem campos de acompanhamento de trabalho. Nada de sprint, estimate ou assignee. Acrescente-os e um Blueprint vira uma tarefa e apodrece. Em vez disso, linke para um gerenciador de tarefas. O mesmo vale no corpo: como você pretende construir algo é intenção; quão longe você está é acompanhamento de trabalho. Por quê →

Referenciando outros Blueprints

Links, não nomes soltos, tanto na prosa quanto nas propriedades. O id é a identidade permanente por trás do link.

depends_on:
  - "[Watch a Video](../playback/watch-a-video.md)"

Ponha um link entre aspas no YAML: um [ inicial começa uma lista de outro modo. Se o alvo ainda não tem Blueprint, nomeie-o simplesmente em vez de fabricar um link.

As duas maneiras de um Blueprint dar errado

Ele se lê como um formulário. Toda seção presente, nenhuma com um julgamento dentro. Se um Blueprint se lê como texto de enchimento preenchido, remodele-o até que se leia como se alguém o tivesse escrito. Deixe uma seção de fora quando ela não se aplicar.

Ele não tem non-goals. ## Out of Scope é onde o escopo se sustenta, e a primeira seção a esvaziar quando ninguém é dono da raiz. Por quê →

Na CLI: eidos list e eidos show <id> leem; eidos new <collection> "<Title>" monta o esqueleto; eidos check relata um Blueprint cujo grupo e pasta discordam.