007 vem primeiro porque elimina ambiguidade sobre qual documento manda.
008 vem em seguida porque reorganiza o terreno documental onde specs e arquitetura se apoiam.
006 entra depois porque refactor estrutural grande sem documentação estável tende a cristalizar decisões erradas.
a decisao 003 ja fechou o contrato base para trafego de bytes VM-owned e agora deve ser consumida, nao rediscutida aqui.
004 fecha a taxonomia de falhas que fs e outras bordas vao reutilizar.
009 usa a decisao 003 e a agenda 004 para fechar o dominio de filesystem sem texto improvisado.
010 e 011 isolam o dominio maior de input fora de syscall, tratando pad e touch como superfícies centrais, button como parte de pad, e explicitando a migracao da leitura de input para intrinsics.
005 fecha a barra de qualidade antes das implementações mais arriscadas.
001 e 002 dependem mais fortemente de contrato de sistema, ABI e documentação estáveis.

Dependências principais:

008 depende de 007
006 depende de 007
009 depende da decisao 003 e da agenda 004
010 depende de 007
011 depende de 010
001 depende de 007, da decisao 003, de 004, de 005 e deve alinhar com 009 quando usar fs
002 depende de 007 e deve ser alinhada com a reorganização documental de 008

Regra de uso:

se a implementação exigir decisão estrutural, ela deve nascer daqui antes de virar PR de código;
se uma agenda já estiver resolvida, a PR derivada deve citar explicitamente qual decisão foi tomada;
se a agenda revelar ambiguidade demais, ela não deve ser convertida em PR até o alvo ficar preciso.