@opentask/taskin-task-manager 3.0.2 → 3.2.0

package/CHANGELOG.md

@@ -1,5 +1,124 @@
 # @opentask/taskin-task-manager
 
+## 3.2.0
+
+### Minor Changes
+
+- d5fafdd: A third filter: `active` — tasks that started and have not finished.
+  
+  `open` includes `pending`, which is work nobody has begun; on a board you are watching while work happens, that is noise. `status: in-progress` is the opposite problem: a task vanishes the moment someone pauses it or sends it for review. `active` is the middle that was missing — `in-progress`, `paused` and `in-review`.
+  
+  `blocked` stays out, deliberately: it is work that started, but nobody is moving it right now.
+  
+  Available as `taskin list --active`, as `active` on the MCP `list_tasks` tool, and as `taskin dashboard --active` / `?filter=active`.
+- f84d9c6: Task groups are an entity now: the name lives in one place, and a task carries only the group id.
+  
+  Until now every member of a group carried its own copy of the name. Renaming meant writing N files with no transaction, so a failure halfway left the group answering to two names — and the write path deleted the name whenever it arrived empty, which is how a real project ended up with four grouped tasks and no name at all.
+  
+  - **`Group { id, name }`** in `@opentask/taskin-types`, and `groupName` is gone from `Task`.
+  - **`IGroupRegistry`** with a contract suite any provider proves itself against. Deleting a group says where its tasks go — `deleteGroup(id, { reassignTo })`, the same shape Redmine and Jira offer — so nothing is ever left pointing at a group that no longer exists.
+  - **A provider without groups simply does not expose the registry**, and callers find out by its absence rather than by an operation that fails.
+  - **`taskin group`** — `list`, `add`, `rename`, `remove` — plus `list_groups` over MCP, and the dashboard resolving names from the server instead of from each task.
+  
+  Renaming a three-member group used to be three writes. It is one, and no task file is touched.
+- 9d11a3d: Listings can be ordered: `taskin list --sort <mode>` and a `sort` argument on the MCP `list_tasks` tool, using the same vocabulary the prioritization board already uses — `manual` (by priority), `diff-asc`, `diff-desc`.
+  
+  Until now `taskin list` returned tasks in whatever order the provider found them, which in practice is by id: the priority column went up and down with no pattern, and whoever read the output had to reorder it in their head. That cost is not hypothetical — an autonomous agent reading the list picked a task with priority 30 while one with 255 sat in the same output.
+  
+  `taskin list --json` now also emits **groups as groups**. A group node carries its id, its name, the members that matched the filter, and how many the filter left out — so a partial group says so instead of quietly looking whole, and a consumer never has to reimplement the grouping rule to get it back.
+  
+  Sorting and grouping are separate functions in `@opentask/taskin-task-manager`, so a caller that wants order without grouping gets exactly that.
+- 6e1c7fa: Three loose ends closed: duplicate priorities are flagged, the dashboard stops carrying its own copies of the domain rules, and the prioritisation warning reaches the screen.
+  
+  **`taskin lint` flags duplicate priorities.** Two tasks on the same number corrupt nothing — ordering breaks the tie by input order — but they mean a decision was lost somewhere. It only shows up looking at the whole set, so it is a pass of its own. Absence is not duplication: tasks with no priority are never compared against each other.
+  
+  **The dashboard consumes the domain rules instead of copying them.** Both the filter sets and the manual sort were byte-for-byte copies living in the Vue packages, because importing the domain package appeared to be blocked by the build. It was not the declaration files: the repo's base config marks every package as a composite project, and a composite project consuming another has to declare the reference. Two lines of configuration.
+  
+  `ordenarTarefas` now asks for `OrdenavelPorPrioridade` — the two fields it reads — instead of a whole `Task`, which is what lets the board's own view model share the rule.
+  
+  **The board warns before it costs you.** On a project where only some tasks carry a priority, the first drag rewrites every file above it. The dashboard now says how many are unnumbered and offers to number them once, and the warning disappears when the state it warns about does.
+- 93a60fe: A task marked `done` has to say what was actually done.
+  
+  This comes from a real audit: of eight tasks closed by autonomous agents over two days, **four** read `done` with the whole checklist untouched. In every one of them the work was genuinely finished and covered by tests — but the file showed none of it, so whoever reviewed had nowhere to start. In one, the audit found an item that had in fact **not** been done, hidden among five that had.
+  
+  Three spellings, and only three: `- [x] item` is done, `- [ ] item` is open, and `- [ ] item — adiado: <reason>` is dropped on purpose, with the decision written down. An empty reason does not count — otherwise the convention would be theatre.
+  
+  Two places ask for it, and they ask differently. **`taskin finish` warns**: it names the open items and their lines, then closes the task anyway, because finishing is a one-shot gesture and refusing there only teaches people to route around it. **`taskin lint` refuses**: a `done` task with an unjustified open item is an error, and CI is where the demand can afford to be hard. `canceled` is exempt — an abandoned task owes nobody a ticked box.
+  
+  Both read the checklist through the same parser, so the linter can never refuse what `finish` just accepted. Providers without the concept of a checklist simply do not implement the capability, and close with no gate at all.
+  
+  Evidence belongs next to the ticked item — a test name, a command, a file — and `TASKS/README.md` now documents the whole vocabulary, including where it came from.
+- 0aa99db: `taskin prioritize` gives every task a priority number, once and on purpose — and `prioritize_tasks` does the same over MCP.
+  
+  A project where only some tasks carry a priority is expensive to reorder: a task with no number sorts last, so giving one to a task in the middle means numbering every task before it. On a 500-task project, moving one from the middle of the unnumbered stretch rewrote **124 files**. After this command, the same move rewrites **one**.
+  
+  It preserves what you already decided: tasks that carry a number keep it, and the gaps around them are filled. Running it again writes nothing, so it is safe in a script. `--dry-run` reports how many would be numbered without touching anything.
+  
+  The rule itself lives in one place — `ITaskManager.prioritizeAll()` — so the CLI and the MCP server share it rather than each carrying a copy.
+
+### Patch Changes
+
+- Updated dependencies [f84d9c6]
+- Updated dependencies [0f83ec2]
+  - @opentask/taskin-types@2.3.0
+
+## 3.1.0
+
+### Minor Changes
+
+- 6bebe35: O taskin passa a entregar a lista de tarefas de forma que outra ferramenta
+  consuma — `taskin list --json` e `list_tasks` no servidor MCP.
+  
+  ## O que havia
+  
+  O `list` só imprimia tabela colorida. O servidor MCP não tinha ferramenta de
+  listagem, e o recurso `taskin://tasks` **anunciava** a capacidade e respondia
+  com um espaço reservado:
+  
+  ```json
+  {"message": "Task list would be here", "note": "Requires ITaskProvider integration"}
+  ```
+  
+  Pior que não oferecer: quem consome recebe algo com cara de dado.
+  
+  ## Uma seleção, não três
+  
+  Havia duas implementações da mesma pergunta, já discordando — o comando `list`
+  casava o responsável por substring em nome ou id, e a classe `Taskin` casava
+  `userId` exato, além de projetar a task derrubando o `assignee`. A saída em
+  JSON e o MCP seriam a terceira e a quarta.
+  
+  `filterTasks` e `summarizeTask` vivem no pacote agnóstico, e os três caminhos
+  perguntam ao mesmo lugar.
+  
+  ## Detalhes que importam para quem consome
+  
+  `list --json` sai **sem cabeçalho, moldura ou aviso** — a saída inteira é JSON
+  válido, e lista vazia é `[]`. Não carrega `content` nem `description`: o
+  provider de arquivos guarda o markdown inteiro neles, e a listagem deste
+  repositório passaria de vinte mil linhas. O corpo se busca pelo id.
+  
+  `getAllTasks` entrou no `ITaskManager`, delegando ao provider como `lint` já
+  fazia — era o que faltava para um consumidor que só tem o manager responder
+  "que trabalho existe?".
+  
+  `ListTasksOptions.status` e `.type` passam a usar os tipos do domínio em vez de
+  `string`. Um valor fora do conjunto nunca casaria, e falhava em silêncio.
+  
+  ## Um defeito de transporte, corrigido junto
+  
+  Exercitando o servidor por stdio, o SDK recusava a resposta com
+  `invalid_union: expected string, received array`. O invólucro fazia
+  `text: result.content`, embrulhando o arranjo de blocos dentro de um bloco cujo
+  `text` precisa ser string — então **`start_task` e `finish_task` nunca
+  funcionaram pelo transporte real**. Nenhum teste pegava porque todos chamavam
+  `callTool` direto, pulando o invólucro.
+
+### Patch Changes
+
+- Updated dependencies [6bebe35]
+  - @opentask/taskin-types@2.2.0
+
 ## 3.0.2
 
 ### Patch Changes

package/dist/completion-blockers.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/completion-blockers.test.js

@@ -0,0 +1,57 @@
+import { parseTaskId } from '@opentask/taskin-types';
+import { describe, expect, it, vi } from 'vitest';
+import { TaskManager } from './task-manager.js';
+const tarefa = (extra = {}) => ({ id: parseTaskId('001'), title: 'Uma tarefa', status: 'in-progress', type: 'feat', ...extra });
+function provider(overrides = {}) {
+    return {
+        initialize: vi.fn(async () => { }),
+        findTask: vi.fn(async () => tarefa()),
+        getAllTasks: vi.fn(async () => [tarefa()]),
+        updateTask: vi.fn(async () => { }),
+        createTask: vi.fn(),
+        lint: vi.fn(),
+        ...overrides,
+    };
+}
+/**
+ * O aviso no `finish`, e por que ele **avisa** em vez de recusar.
+ *
+ * Fechar uma tarefa e um gesto que acontece uma vez, muitas vezes com pressa.
+ * Recusar ali torna o comando fragil e ensina a contornar. O portao duro vive no
+ * `lint` (task-075), que roda em CI e quebra o build; aqui o papel e outro —
+ * dizer, no momento em que a pessoa ainda esta olhando, o que ficou para tras.
+ *
+ * E uma **capacidade opcional** do provider: nem toda fonte tem checklist. Um
+ * provider sem ela conclui sem portao nenhum, em vez de receber uma chamada que
+ * falha.
+ */
+describe('finishTask e os criterios em aberto', () => {
+    it('conclui em silencio quando o provider nao tem a capacidade', async () => {
+        const manager = new TaskManager(provider());
+        const { blockers } = await manager.finishTaskComRelato(parseTaskId('001'));
+        expect(blockers).toEqual([]);
+    });
+    it('relata os itens em aberto que o provider aponta', async () => {
+        const manager = new TaskManager(provider({
+            getCompletionBlockers: vi.fn(async () => [{ texto: 'Documentar', linha: 12 }]),
+        }));
+        const { blockers } = await manager.finishTaskComRelato(parseTaskId('001'));
+        expect(blockers).toHaveLength(1);
+        expect(blockers[0]?.texto).toBe('Documentar');
+    });
+    it('conclui mesmo assim: avisa, e nao recusa', async () => {
+        const updateTask = vi.fn(async () => { });
+        const manager = new TaskManager(provider({
+            updateTask,
+            getCompletionBlockers: vi.fn(async () => [{ texto: 'Documentar', linha: 12 }]),
+        }));
+        const { task } = await manager.finishTaskComRelato(parseTaskId('001'));
+        expect(task.status).toBe('done');
+        expect(updateTask).toHaveBeenCalled();
+    });
+    it('nao relata nada quando tudo esta feito ou adiado', async () => {
+        const manager = new TaskManager(provider({ getCompletionBlockers: vi.fn(async () => []) }));
+        expect((await manager.finishTaskComRelato(parseTaskId('001'))).blockers).toEqual([]);
+    });
+});
+//# sourceMappingURL=completion-blockers.test.js.map

package/dist/completion-blockers.test.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"completion-blockers.test.js","sourceRoot":"","sources":["../src/completion-blockers.test.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,WAAW,EAAa,MAAM,wBAAwB,CAAC;AAChE,OAAO,EAAE,QAAQ,EAAE,MAAM,EAAE,EAAE,EAAE,EAAE,EAAE,MAAM,QAAQ,CAAC;AAClD,OAAO,EAAE,WAAW,EAAE,MAAM,mBAAmB,CAAC;AAGhD,MAAM,MAAM,GAAG,CAAC,QAAuB,EAAE,EAAQ,EAAE,CACjD,CAAC,EAAE,EAAE,EAAE,WAAW,CAAC,KAAK,CAAC,EAAE,KAAK,EAAE,YAAY,EAAE,MAAM,EAAE,aAAa,EAAE,IAAI,EAAE,MAAM,EAAE,GAAG,KAAK,EAAE,CAAS,CAAC;AAE3G,SAAS,QAAQ,CAAC,YAAoC,EAAE;IACtD,OAAO;QACL,UAAU,EAAE,EAAE,CAAC,EAAE,CAAC,KAAK,IAAI,EAAE,GAAE,CAAC,CAAC;QACjC,QAAQ,EAAE,EAAE,CAAC,EAAE,CAAC,KAAK,IAAI,EAAE,CAAC,MAAM,EAAE,CAAC;QACrC,WAAW,EAAE,EAAE,CAAC,EAAE,CAAC,KAAK,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,CAAC;QAC1C,UAAU,EAAE,EAAE,CAAC,EAAE,CAAC,KAAK,IAAI,EAAE,GAAE,CAAC,CAAC;QACjC,UAAU,EAAE,EAAE,CAAC,EAAE,EAAE;QACnB,IAAI,EAAE,EAAE,CAAC,EAAE,EAAE;QACb,GAAG,SAAS;KACe,CAAC;AAChC,CAAC;AAED;;;;;;;;;;;GAWG;AACH,QAAQ,CAAC,qCAAqC,EAAE,GAAG,EAAE;IACnD,EAAE,CAAC,4DAA4D,EAAE,KAAK,IAAI,EAAE;QAC1E,MAAM,OAAO,GAAG,IAAI,WAAW,CAAC,QAAQ,EAAE,CAAC,CAAC;QAE5C,MAAM,EAAE,QAAQ,EAAE,GAAG,MAAM,OAAO,CAAC,mBAAmB,CAAC,WAAW,CAAC,KAAK,CAAC,CAAC,CAAC;QAE3E,MAAM,CAAC,QAAQ,CAAC,CAAC,OAAO,CAAC,EAAE,CAAC,CAAC;IAC/B,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,iDAAiD,EAAE,KAAK,IAAI,EAAE;QAC/D,MAAM,OAAO,GAAG,IAAI,WAAW,CAC7B,QAAQ,CAAC;YACP,qBAAqB,EAAE,EAAE,CAAC,EAAE,CAAC,KAAK,IAAI,EAAE,CAAC,CAAC,EAAE,KAAK,EAAE,YAAY,EAAE,KAAK,EAAE,EAAE,EAAE,CAAC,CAAC;SACrD,CAAC,CAC7B,CAAC;QAEF,MAAM,EAAE,QAAQ,EAAE,GAAG,MAAM,OAAO,CAAC,mBAAmB,CAAC,WAAW,CAAC,KAAK,CAAC,CAAC,CAAC;QAE3E,MAAM,CAAC,QAAQ,CAAC,CAAC,YAAY,CAAC,CAAC,CAAC,CAAC;QACjC,MAAM,CAAC,QAAQ,CAAC,CAAC,CAAC,EAAE,KAAK,CAAC,CAAC,IAAI,CAAC,YAAY,CAAC,CAAC;IAChD,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,0CAA0C,EAAE,KAAK,IAAI,EAAE;QACxD,MAAM,UAAU,GAAG,EAAE,CAAC,EAAE,CAAC,KAAK,IAAI,EAAE,GAAE,CAAC,CAAC,CAAC;QACzC,MAAM,OAAO,GAAG,IAAI,WAAW,CAC7B,QAAQ,CAAC;YACP,UAAU;YACV,qBAAqB,EAAE,EAAE,CAAC,EAAE,CAAC,KAAK,IAAI,EAAE,CAAC,CAAC,EAAE,KAAK,EAAE,YAAY,EAAE,KAAK,EAAE,EAAE,EAAE,CAAC,CAAC;SACrD,CAAC,CAC7B,CAAC;QAEF,MAAM,EAAE,IAAI,EAAE,GAAG,MAAM,OAAO,CAAC,mBAAmB,CAAC,WAAW,CAAC,KAAK,CAAC,CAAC,CAAC;QAEvE,MAAM,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC;QACjC,MAAM,CAAC,UAAU,CAAC,CAAC,gBAAgB,EAAE,CAAC;IACxC,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,kDAAkD,EAAE,KAAK,IAAI,EAAE;QAChE,MAAM,OAAO,GAAG,IAAI,WAAW,CAC7B,QAAQ,CAAC,EAAE,qBAAqB,EAAE,EAAE,CAAC,EAAE,CAAC,KAAK,IAAI,EAAE,CAAC,EAAE,CAAC,EAA4B,CAAC,CACrF,CAAC;QAEF,MAAM,CAAC,CAAC,MAAM,OAAO,CAAC,mBAAmB,CAAC,WAAW,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,CAAC,OAAO,CAAC,EAAE,CAAC,CAAC;IACvF,CAAC,CAAC,CAAC;AACL,CAAC,CAAC,CAAC"}

package/dist/filter-tasks/filter-criteria.d.ts

@@ -0,0 +1,181 @@
+import { z } from 'zod';
+/**
+ * Os criterios que restringem uma listagem, definidos **uma vez so**.
+ *
+ * Antes cada criterio existia em cinco lugares escritos a mao: o tipo, a flag da
+ * CLI, o mapeamento da CLI, o schema JSON do MCP e o mapeamento do MCP.
+ * Acrescentar um exigia lembrar dos cinco, e esquecer nao quebrava nada — so
+ * fazia uma superficie ficar para tras, em silencio. O sintoma ja tinha
+ * aparecido: o criterio chamava-se `assignee` e a flag da CLI chamava-se
+ * `--user`, duas grafias para a mesma coisa que ninguem decidiu.
+ *
+ * Aqui o schema e a fonte. As superficies **derivam** dele:
+ *
+ * - `TaskFilterCriteria` e `z.infer` deste schema — o tipo nao se escreve a mao.
+ * - O schema JSON do `list_tasks` sai de `filterCriteriaJsonSchema`.
+ * - As opcoes do `taskin list` saem de `filterCriteriaCliOptions`.
+ * - A validacao e a conversao saem de `parseFilterCriteria` — os dois
+ *   mapeamentos a mao desaparecem.
+ *
+ * O portao que fecha o circuito e o `satisfies Record<keyof TaskFilterCriteria,
+ * ...>` em {@link FILTER_CRITERIA_SURFACES}: acrescentar um criterio ao schema e
+ * **nao** ligar a superficie vira erro de compilacao, que e o unico lembrete que
+ * nao depende de ninguem lembrar.
+ *
+ * **Como acrescentar um criterio novo.** Duas linhas, e o compilador cobra a
+ * segunda:
+ *
+ * 1. uma propriedade `.optional()` em {@link FilterCriteriaSchema};
+ * 2. a entrada correspondente em {@link FILTER_CRITERIA_SURFACES} (descricao +
+ *    onde mora na CLI).
+ *
+ * A CLI, o schema JSON do MCP e a validacao passam a conhece-lo sem mais nenhuma
+ * edicao. Esquecer o passo 2 nao compila.
+ */
+export declare const FilterCriteriaSchema: z.ZodObject<{
+    status: z.ZodOptional<z.ZodEnum<{
+        pending: "pending";
+        "in-progress": "in-progress";
+        paused: "paused";
+        "in-review": "in-review";
+        done: "done";
+        blocked: "blocked";
+        canceled: "canceled";
+    }>>;
+    type: z.ZodOptional<z.ZodEnum<{
+        feat: "feat";
+        fix: "fix";
+        refactor: "refactor";
+        docs: "docs";
+        test: "test";
+        chore: "chore";
+    }>>;
+    assignee: z.ZodOptional<z.ZodString>;
+    open: z.ZodOptional<z.ZodBoolean>;
+    closed: z.ZodOptional<z.ZodBoolean>;
+    active: z.ZodOptional<z.ZodBoolean>;
+    text: z.ZodOptional<z.ZodString>;
+}, z.core.$strip>;
+/**
+ * O que restringe uma listagem de tarefas.
+ *
+ * Todos os campos sao opcionais e **se somam**: informar dois exige os dois. Um
+ * criterio ausente nao restringe nada. Derivado de {@link FilterCriteriaSchema}
+ * — mudar o schema muda o tipo.
+ *
+ * @public
+ */
+export type TaskFilterCriteria = z.infer<typeof FilterCriteriaSchema>;
+/** Onde um criterio aparece na linha de comando. */
+export type CriterionCli = {
+    readonly kind: 'positional';
+} | {
+    readonly kind: 'flag';
+    readonly short?: string;
+};
+/**
+ * O que uma superficie precisa saber de um criterio alem da sua forma: o texto
+ * de ajuda (compartilhado entre `--help` da CLI e a propriedade do MCP) e onde
+ * ele mora na linha de comando.
+ */
+export interface CriterionSurface {
+    readonly description: string;
+    readonly cli: CriterionCli;
+}
+/**
+ * A superficie de cada criterio, gateada a cobrir **todos** os campos de
+ * {@link TaskFilterCriteria}.
+ *
+ * O `satisfies Record<keyof TaskFilterCriteria, ...>` e o portao: acrescentar um
+ * criterio ao schema sem uma entrada aqui nao compila.
+ */
+export declare const FILTER_CRITERIA_SURFACES: {
+    status: {
+        description: string;
+        cli: {
+            kind: "flag";
+            short: string;
+        };
+    };
+    type: {
+        description: string;
+        cli: {
+            kind: "flag";
+            short: string;
+        };
+    };
+    assignee: {
+        description: string;
+        cli: {
+            kind: "flag";
+            short: string;
+        };
+    };
+    open: {
+        description: string;
+        cli: {
+            kind: "flag";
+        };
+    };
+    closed: {
+        description: string;
+        cli: {
+            kind: "flag";
+        };
+    };
+    active: {
+        description: string;
+        cli: {
+            kind: "flag";
+        };
+    };
+    text: {
+        description: string;
+        cli: {
+            kind: "positional";
+        };
+    };
+};
+type SurfaceMap = Record<string, CriterionSurface>;
+/** O schema JSON de entrada de uma ferramenta MCP: objeto com propriedades. */
+export interface FilterJsonSchema {
+    readonly type: 'object';
+    readonly properties: Record<string, unknown>;
+    readonly required: string[];
+}
+/** Uma opcao de CLI, na forma que o `commander` (e o `defineCommand`) consome. */
+export interface FilterCliOption {
+    readonly flags: string;
+    readonly description: string;
+}
+/**
+ * O schema JSON das propriedades de filtro, derivado do zod.
+ *
+ * Nao e aposta: o `packages/types-ts` ja gera JSON Schema de schemas zod pelo
+ * mesmo `z.toJSONSchema()` desde a migracao para o zod 4. Aqui e o mesmo
+ * mecanismo, aplicado ao schema de filtro, com a descricao de cada campo vinda
+ * da superficie unica.
+ *
+ * Recebe schema e superficies para poder ser exercitado com um criterio
+ * ficticio nos testes — a prova de que deriva, em vez de repetir a mao.
+ */
+export declare function filterCriteriaJsonSchema(schema?: z.ZodObject, surfaces?: SurfaceMap): FilterJsonSchema;
+/**
+ * As opcoes do `taskin list`, derivadas das superficies.
+ *
+ * Um criterio `positional` (o texto livre) nao vira flag: ele e o argumento
+ * `[filter]` do comando. Um criterio booleano nao leva valor (`--open`); os
+ * demais levam (`-s, --status <status>`). O tipo — booleano ou nao — sai do
+ * proprio schema JSON, e nao de uma segunda lista.
+ */
+export declare function filterCriteriaCliOptions(schema?: z.ZodObject, surfaces?: SurfaceMap): FilterCliOption[];
+/**
+ * Valida os argumentos crus e os converte em {@link TaskFilterCriteria}.
+ *
+ * E o `parse` do proprio schema, sem mapeamento a mao. Chaves desconhecidas sao
+ * descartadas (o `--json` do CLI, por exemplo, nao e criterio); um valor com o
+ * tipo errado — um status fora do conjunto — passa a **falhar barulhento**, em
+ * vez de devolver lista vazia como se nao houvesse tarefa.
+ */
+export declare function parseFilterCriteria(raw: unknown): TaskFilterCriteria;
+export {};

package/dist/filter-tasks/filter-criteria.js

@@ -0,0 +1,115 @@
+import { TaskStatusSchema, TaskTypeSchema } from '@opentask/taskin-types';
+import { z } from 'zod';
+/**
+ * Os criterios que restringem uma listagem, definidos **uma vez so**.
+ *
+ * Antes cada criterio existia em cinco lugares escritos a mao: o tipo, a flag da
+ * CLI, o mapeamento da CLI, o schema JSON do MCP e o mapeamento do MCP.
+ * Acrescentar um exigia lembrar dos cinco, e esquecer nao quebrava nada — so
+ * fazia uma superficie ficar para tras, em silencio. O sintoma ja tinha
+ * aparecido: o criterio chamava-se `assignee` e a flag da CLI chamava-se
+ * `--user`, duas grafias para a mesma coisa que ninguem decidiu.
+ *
+ * Aqui o schema e a fonte. As superficies **derivam** dele:
+ *
+ * - `TaskFilterCriteria` e `z.infer` deste schema — o tipo nao se escreve a mao.
+ * - O schema JSON do `list_tasks` sai de `filterCriteriaJsonSchema`.
+ * - As opcoes do `taskin list` saem de `filterCriteriaCliOptions`.
+ * - A validacao e a conversao saem de `parseFilterCriteria` — os dois
+ *   mapeamentos a mao desaparecem.
+ *
+ * O portao que fecha o circuito e o `satisfies Record<keyof TaskFilterCriteria,
+ * ...>` em {@link FILTER_CRITERIA_SURFACES}: acrescentar um criterio ao schema e
+ * **nao** ligar a superficie vira erro de compilacao, que e o unico lembrete que
+ * nao depende de ninguem lembrar.
+ *
+ * **Como acrescentar um criterio novo.** Duas linhas, e o compilador cobra a
+ * segunda:
+ *
+ * 1. uma propriedade `.optional()` em {@link FilterCriteriaSchema};
+ * 2. a entrada correspondente em {@link FILTER_CRITERIA_SURFACES} (descricao +
+ *    onde mora na CLI).
+ *
+ * A CLI, o schema JSON do MCP e a validacao passam a conhece-lo sem mais nenhuma
+ * edicao. Esquecer o passo 2 nao compila.
+ */
+export const FilterCriteriaSchema = z.object({
+    status: TaskStatusSchema.optional(),
+    type: TaskTypeSchema.optional(),
+    assignee: z.string().optional(),
+    open: z.boolean().optional(),
+    closed: z.boolean().optional(),
+    active: z.boolean().optional(),
+    text: z.string().optional(),
+});
+/**
+ * A superficie de cada criterio, gateada a cobrir **todos** os campos de
+ * {@link TaskFilterCriteria}.
+ *
+ * O `satisfies Record<keyof TaskFilterCriteria, ...>` e o portao: acrescentar um
+ * criterio ao schema sem uma entrada aqui nao compila.
+ */
+export const FILTER_CRITERIA_SURFACES = {
+    status: { description: 'Exact status (pending, in-progress, done, ...)', cli: { kind: 'flag', short: 's' } },
+    type: { description: 'Exact type (feat, fix, chore, ...)', cli: { kind: 'flag', short: 't' } },
+    assignee: { description: 'Assignee id or name, whole or in part', cli: { kind: 'flag', short: 'u' } },
+    open: { description: 'Only tasks still open', cli: { kind: 'flag' } },
+    closed: { description: 'Only tasks already closed', cli: { kind: 'flag' } },
+    active: {
+        description: 'Only tasks started and not finished (in-progress, paused, in-review)',
+        cli: { kind: 'flag' },
+    },
+    text: { description: 'Free text over id, title, status and assignee', cli: { kind: 'positional' } },
+};
+/**
+ * O schema JSON das propriedades de filtro, derivado do zod.
+ *
+ * Nao e aposta: o `packages/types-ts` ja gera JSON Schema de schemas zod pelo
+ * mesmo `z.toJSONSchema()` desde a migracao para o zod 4. Aqui e o mesmo
+ * mecanismo, aplicado ao schema de filtro, com a descricao de cada campo vinda
+ * da superficie unica.
+ *
+ * Recebe schema e superficies para poder ser exercitado com um criterio
+ * ficticio nos testes — a prova de que deriva, em vez de repetir a mao.
+ */
+export function filterCriteriaJsonSchema(schema = FilterCriteriaSchema, surfaces = FILTER_CRITERIA_SURFACES) {
+    const described = z.object(Object.fromEntries(Object.entries(schema.shape).map(([key, prop]) => [
+        key,
+        prop.describe(surfaces[key]?.description ?? ''),
+    ])));
+    const json = z.toJSONSchema(described, { target: 'draft-7', io: 'output' });
+    return { type: 'object', properties: json.properties ?? {}, required: [] };
+}
+/**
+ * As opcoes do `taskin list`, derivadas das superficies.
+ *
+ * Um criterio `positional` (o texto livre) nao vira flag: ele e o argumento
+ * `[filter]` do comando. Um criterio booleano nao leva valor (`--open`); os
+ * demais levam (`-s, --status <status>`). O tipo — booleano ou nao — sai do
+ * proprio schema JSON, e nao de uma segunda lista.
+ */
+export function filterCriteriaCliOptions(schema = FilterCriteriaSchema, surfaces = FILTER_CRITERIA_SURFACES) {
+    const { properties } = filterCriteriaJsonSchema(schema, surfaces);
+    const options = [];
+    for (const [key, surface] of Object.entries(surfaces)) {
+        if (surface.cli.kind !== 'flag')
+            continue;
+        const short = surface.cli.short ? `-${surface.cli.short}, ` : '';
+        const takesValue = properties[key]?.type !== 'boolean';
+        const flags = takesValue ? `${short}--${key} <${key}>` : `${short}--${key}`;
+        options.push({ flags, description: surface.description });
+    }
+    return options;
+}
+/**
+ * Valida os argumentos crus e os converte em {@link TaskFilterCriteria}.
+ *
+ * E o `parse` do proprio schema, sem mapeamento a mao. Chaves desconhecidas sao
+ * descartadas (o `--json` do CLI, por exemplo, nao e criterio); um valor com o
+ * tipo errado — um status fora do conjunto — passa a **falhar barulhento**, em
+ * vez de devolver lista vazia como se nao houvesse tarefa.
+ */
+export function parseFilterCriteria(raw) {
+    return FilterCriteriaSchema.parse(raw);
+}
+//# sourceMappingURL=filter-criteria.js.map

package/dist/filter-tasks/filter-criteria.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"filter-criteria.js","sourceRoot":"","sources":["../../src/filter-tasks/filter-criteria.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,gBAAgB,EAAE,cAAc,EAAE,MAAM,wBAAwB,CAAC;AAC1E,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAExB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,MAAM,CAAC,MAAM,oBAAoB,GAAG,CAAC,CAAC,MAAM,CAAC;IAC3C,MAAM,EAAE,gBAAgB,CAAC,QAAQ,EAAE;IACnC,IAAI,EAAE,cAAc,CAAC,QAAQ,EAAE;IAC/B,QAAQ,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAC/B,IAAI,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;IAC5B,MAAM,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;IAC9B,MAAM,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;IAC9B,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;CAC5B,CAAC,CAAC;AA0BH;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,wBAAwB,GAAG;IACtC,MAAM,EAAE,EAAE,WAAW,EAAE,gDAAgD,EAAE,GAAG,EAAE,EAAE,IAAI,EAAE,MAAM,EAAE,KAAK,EAAE,GAAG,EAAE,EAAE;IAC5G,IAAI,EAAE,EAAE,WAAW,EAAE,oCAAoC,EAAE,GAAG,EAAE,EAAE,IAAI,EAAE,MAAM,EAAE,KAAK,EAAE,GAAG,EAAE,EAAE;IAC9F,QAAQ,EAAE,EAAE,WAAW,EAAE,uCAAuC,EAAE,GAAG,EAAE,EAAE,IAAI,EAAE,MAAM,EAAE,KAAK,EAAE,GAAG,EAAE,EAAE;IACrG,IAAI,EAAE,EAAE,WAAW,EAAE,uBAAuB,EAAE,GAAG,EAAE,EAAE,IAAI,EAAE,MAAM,EAAE,EAAE;IACrE,MAAM,EAAE,EAAE,WAAW,EAAE,2BAA2B,EAAE,GAAG,EAAE,EAAE,IAAI,EAAE,MAAM,EAAE,EAAE;IAC3E,MAAM,EAAE;QACN,WAAW,EAAE,sEAAsE;QACnF,GAAG,EAAE,EAAE,IAAI,EAAE,MAAM,EAAE;KACtB;IACD,IAAI,EAAE,EAAE,WAAW,EAAE,+CAA+C,EAAE,GAAG,EAAE,EAAE,IAAI,EAAE,YAAY,EAAE,EAAE;CACvC,CAAC;AAiB/D;;;;;;;;;;GAUG;AACH,MAAM,UAAU,wBAAwB,CACtC,SAAsB,oBAAoB,EAC1C,WAAuB,wBAAwB;IAE/C,MAAM,SAAS,GAAG,CAAC,CAAC,MAAM,CACxB,MAAM,CAAC,WAAW,CAChB,MAAM,CAAC,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC,GAAG,EAAE,IAAI,CAAC,EAAE,EAAE,CAAC;QAChD,GAAG;QACF,IAAkB,CAAC,QAAQ,CAAC,QAAQ,CAAC,GAAG,CAAC,EAAE,WAAW,IAAI,EAAE,CAAC;KAC/D,CAAC,CACH,CACF,CAAC;IAEF,MAAM,IAAI,GAAG,CAAC,CAAC,YAAY,CAAC,SAAS,EAAE,EAAE,MAAM,EAAE,SAAS,EAAE,EAAE,EAAE,QAAQ,EAAE,CAEzE,CAAC;IAEF,OAAO,EAAE,IAAI,EAAE,QAAQ,EAAE,UAAU,EAAE,IAAI,CAAC,UAAU,IAAI,EAAE,EAAE,QAAQ,EAAE,EAAE,EAAE,CAAC;AAC7E,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,UAAU,wBAAwB,CACtC,SAAsB,oBAAoB,EAC1C,WAAuB,wBAAwB;IAE/C,MAAM,EAAE,UAAU,EAAE,GAAG,wBAAwB,CAAC,MAAM,EAAE,QAAQ,CAAC,CAAC;IAClE,MAAM,OAAO,GAAsB,EAAE,CAAC;IAEtC,KAAK,MAAM,CAAC,GAAG,EAAE,OAAO,CAAC,IAAI,MAAM,CAAC,OAAO,CAAC,QAAQ,CAAC,EAAE,CAAC;QACtD,IAAI,OAAO,CAAC,GAAG,CAAC,IAAI,KAAK,MAAM;YAAE,SAAS;QAE1C,MAAM,KAAK,GAAG,OAAO,CAAC,GAAG,CAAC,KAAK,CAAC,CAAC,CAAC,IAAI,OAAO,CAAC,GAAG,CAAC,KAAK,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC;QACjE,MAAM,UAAU,GAAI,UAAU,CAAC,GAAG,CAAmC,EAAE,IAAI,KAAK,SAAS,CAAC;QAC1F,MAAM,KAAK,GAAG,UAAU,CAAC,CAAC,CAAC,GAAG,KAAK,KAAK,GAAG,KAAK,GAAG,GAAG,CAAC,CAAC,CAAC,GAAG,KAAK,KAAK,GAAG,EAAE,CAAC;QAE5E,OAAO,CAAC,IAAI,CAAC,EAAE,KAAK,EAAE,WAAW,EAAE,OAAO,CAAC,WAAW,EAAE,CAAC,CAAC;IAC5D,CAAC;IAED,OAAO,OAAO,CAAC;AACjB,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,UAAU,mBAAmB,CAAC,GAAY;IAC9C,OAAO,oBAAoB,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC;AACzC,CAAC"}

package/dist/filter-tasks/filter-criteria.test.d.ts

@@ -0,0 +1 @@
+export {};

package/dist/filter-tasks/filter-criteria.test.js

@@ -0,0 +1,86 @@
+import { describe, expect, it } from 'vitest';
+import { z } from 'zod';
+import { FILTER_CRITERIA_SURFACES, FilterCriteriaSchema, filterCriteriaCliOptions, filterCriteriaJsonSchema, parseFilterCriteria, } from './filter-criteria.js';
+/**
+ * Um criterio sem superficie e **erro de compilacao**, e nao aviso em tempo de
+ * execucao. Esta linha e a prova: um mapa que cobre `TaskFilterCriteria` menos a
+ * chave `text` nao satisfaz o gate por tipo. O `@ts-expect-error` falha o
+ * `typecheck` se um dia a omissao passar a compilar — que e o defeito que a task
+ * fecha.
+ */
+const semText = { status: FILTER_CRITERIA_SURFACES.status };
+// @ts-expect-error — falta a chave 'text': um criterio sem superficie nao compila.
+const _gateIncompleto = semText;
+void _gateIncompleto;
+/**
+ * Uma definicao so para os criterios de filtro.
+ *
+ * A propriedade que vale nao afirma a forma do schema — afirma que um criterio
+ * definido num lugar so **aparece nas duas superficies** sem edicao manual. Por
+ * isso os geradores recebem um schema e superficies: o teste acrescenta um
+ * criterio ficticio e prova que ele emerge na CLI e no MCP, o que so e possivel
+ * se as superficies derivarem, em vez de repetir a lista a mao.
+ */
+describe('criterios de filtro derivam de uma definicao so', () => {
+    const schemaEstendido = FilterCriteriaSchema.extend({ fictional: z.string().optional() });
+    const superficiesEstendidas = {
+        ...FILTER_CRITERIA_SURFACES,
+        fictional: { description: 'criterio ficticio para o teste', cli: { kind: 'flag' } },
+    };
+    it('um criterio novo aparece no schema JSON do MCP sem editar o MCP', () => {
+        const json = filterCriteriaJsonSchema(schemaEstendido, superficiesEstendidas);
+        expect(json.properties).toHaveProperty('fictional');
+        expect(json.properties.fictional.description).toBe('criterio ficticio para o teste');
+    });
+    it('um criterio novo aparece nas opcoes da CLI sem editar a CLI', () => {
+        const opcoes = filterCriteriaCliOptions(schemaEstendido, superficiesEstendidas);
+        const ficticia = opcoes.find((o) => o.flags.includes('--fictional'));
+        expect(ficticia).toBeDefined();
+        expect(ficticia?.description).toBe('criterio ficticio para o teste');
+    });
+    it('cada criterio do schema tem uma superficie — nenhum fica para tras', () => {
+        const doSchema = Object.keys(FilterCriteriaSchema.shape).sort();
+        const comSuperficie = Object.keys(FILTER_CRITERIA_SURFACES).sort();
+        expect(comSuperficie).toEqual(doSchema);
+    });
+});
+describe('o schema JSON derivado do MCP', () => {
+    it('descreve todo criterio, e usa enum onde o valor e fechado', () => {
+        const json = filterCriteriaJsonSchema();
+        expect(json.type).toBe('object');
+        expect(json.required).toEqual([]);
+        // status e um conjunto fechado: o schema JSON traz o enum, e nao string solta.
+        expect(json.properties.status.enum).toContain('pending');
+        expect(json.properties.open.type).toBe('boolean');
+    });
+});
+describe('as opcoes derivadas da CLI', () => {
+    it('booleano nao leva valor; os demais levam <chave>', () => {
+        const opcoes = filterCriteriaCliOptions();
+        const porFlag = (frag) => opcoes.find((o) => o.flags.includes(frag));
+        expect(porFlag('--open')?.flags).toBe('--open');
+        expect(porFlag('--status')?.flags).toBe('-s, --status <status>');
+    });
+    it('unifica a grafia: a flag do responsavel e --assignee, e nao --user', () => {
+        const opcoes = filterCriteriaCliOptions();
+        expect(opcoes.some((o) => o.flags.includes('--assignee'))).toBe(true);
+        expect(opcoes.some((o) => o.flags.includes('--user'))).toBe(false);
+    });
+    it('o texto livre e argumento posicional, e nao vira flag', () => {
+        const opcoes = filterCriteriaCliOptions();
+        expect(opcoes.some((o) => o.flags.includes('--text'))).toBe(false);
+    });
+});
+describe('parseFilterCriteria', () => {
+    it('descarta chaves que nao sao criterio, como o --json', () => {
+        const criteria = parseFilterCriteria({ status: 'done', json: true, foo: 1 });
+        expect(criteria).toEqual({ status: 'done' });
+    });
+    it('falha barulhento num valor fora do conjunto, em vez de silenciar', () => {
+        expect(() => parseFilterCriteria({ status: 'inexistente' })).toThrow();
+    });
+    it('objeto vazio e um criterio valido que nao restringe nada', () => {
+        expect(parseFilterCriteria({})).toEqual({});
+    });
+});
+//# sourceMappingURL=filter-criteria.test.js.map

package/dist/filter-tasks/filter-criteria.test.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"filter-criteria.test.js","sourceRoot":"","sources":["../../src/filter-tasks/filter-criteria.test.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,QAAQ,EAAE,MAAM,EAAE,EAAE,EAAE,MAAM,QAAQ,CAAC;AAC9C,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EAEL,wBAAwB,EACxB,oBAAoB,EACpB,wBAAwB,EACxB,wBAAwB,EACxB,mBAAmB,GAEpB,MAAM,sBAAsB,CAAC;AAE9B;;;;;;GAMG;AACH,MAAM,OAAO,GAAG,EAAE,MAAM,EAAE,wBAAwB,CAAC,MAAM,EAAE,CAAC;AAC5D,mFAAmF;AACnF,MAAM,eAAe,GAAuD,OAAO,CAAC;AACpF,KAAK,eAAe,CAAC;AAErB;;;;;;;;GAQG;AACH,QAAQ,CAAC,iDAAiD,EAAE,GAAG,EAAE;IAC/D,MAAM,eAAe,GAAG,oBAAoB,CAAC,MAAM,CAAC,EAAE,SAAS,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE,EAAE,CAAC,CAAC;IAC1F,MAAM,qBAAqB,GAAG;QAC5B,GAAG,wBAAwB;QAC3B,SAAS,EAAE,EAAE,WAAW,EAAE,gCAAgC,EAAE,GAAG,EAAE,EAAE,IAAI,EAAE,MAAe,EAAE,EAAE;KAC7F,CAAC;IAEF,EAAE,CAAC,iEAAiE,EAAE,GAAG,EAAE;QACzE,MAAM,IAAI,GAAG,wBAAwB,CAAC,eAAe,EAAE,qBAAqB,CAAC,CAAC;QAE9E,MAAM,CAAC,IAAI,CAAC,UAAU,CAAC,CAAC,cAAc,CAAC,WAAW,CAAC,CAAC;QACpD,MAAM,CAAE,IAAI,CAAC,UAAU,CAAC,SAAsC,CAAC,WAAW,CAAC,CAAC,IAAI,CAAC,gCAAgC,CAAC,CAAC;IACrH,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,6DAA6D,EAAE,GAAG,EAAE;QACrE,MAAM,MAAM,GAAG,wBAAwB,CAAC,eAAe,EAAE,qBAAqB,CAAC,CAAC;QAEhF,MAAM,QAAQ,GAAG,MAAM,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,KAAK,CAAC,QAAQ,CAAC,aAAa,CAAC,CAAC,CAAC;QACrE,MAAM,CAAC,QAAQ,CAAC,CAAC,WAAW,EAAE,CAAC;QAC/B,MAAM,CAAC,QAAQ,EAAE,WAAW,CAAC,CAAC,IAAI,CAAC,gCAAgC,CAAC,CAAC;IACvE,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,oEAAoE,EAAE,GAAG,EAAE;QAC5E,MAAM,QAAQ,GAAG,MAAM,CAAC,IAAI,CAAC,oBAAoB,CAAC,KAAK,CAAC,CAAC,IAAI,EAAE,CAAC;QAChE,MAAM,aAAa,GAAG,MAAM,CAAC,IAAI,CAAC,wBAAwB,CAAC,CAAC,IAAI,EAAE,CAAC;QAEnE,MAAM,CAAC,aAAa,CAAC,CAAC,OAAO,CAAC,QAAQ,CAAC,CAAC;IAC1C,CAAC,CAAC,CAAC;AACL,CAAC,CAAC,CAAC;AAEH,QAAQ,CAAC,+BAA+B,EAAE,GAAG,EAAE;IAC7C,EAAE,CAAC,2DAA2D,EAAE,GAAG,EAAE;QACnE,MAAM,IAAI,GAAG,wBAAwB,EAAE,CAAC;QAExC,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC;QACjC,MAAM,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC,OAAO,CAAC,EAAE,CAAC,CAAC;QAClC,+EAA+E;QAC/E,MAAM,CAAE,IAAI,CAAC,UAAU,CAAC,MAA8B,CAAC,IAAI,CAAC,CAAC,SAAS,CAAC,SAAS,CAAC,CAAC;QAClF,MAAM,CAAE,IAAI,CAAC,UAAU,CAAC,IAA0B,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,SAAS,CAAC,CAAC;IAC3E,CAAC,CAAC,CAAC;AACL,CAAC,CAAC,CAAC;AAEH,QAAQ,CAAC,4BAA4B,EAAE,GAAG,EAAE;IAC1C,EAAE,CAAC,kDAAkD,EAAE,GAAG,EAAE;QAC1D,MAAM,MAAM,GAAG,wBAAwB,EAAE,CAAC;QAC1C,MAAM,OAAO,GAAG,CAAC,IAAY,EAAE,EAAE,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,KAAK,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC;QAE7E,MAAM,CAAC,OAAO,CAAC,QAAQ,CAAC,EAAE,KAAK,CAAC,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC;QAChD,MAAM,CAAC,OAAO,CAAC,UAAU,CAAC,EAAE,KAAK,CAAC,CAAC,IAAI,CAAC,uBAAuB,CAAC,CAAC;IACnE,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,oEAAoE,EAAE,GAAG,EAAE;QAC5E,MAAM,MAAM,GAAG,wBAAwB,EAAE,CAAC;QAE1C,MAAM,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,KAAK,CAAC,QAAQ,CAAC,YAAY,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;QACtE,MAAM,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,KAAK,CAAC,QAAQ,CAAC,QAAQ,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;IACrE,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,uDAAuD,EAAE,GAAG,EAAE;QAC/D,MAAM,MAAM,GAAG,wBAAwB,EAAE,CAAC;QAE1C,MAAM,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,KAAK,CAAC,QAAQ,CAAC,QAAQ,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;IACrE,CAAC,CAAC,CAAC;AACL,CAAC,CAAC,CAAC;AAEH,QAAQ,CAAC,qBAAqB,EAAE,GAAG,EAAE;IACnC,EAAE,CAAC,qDAAqD,EAAE,GAAG,EAAE;QAC7D,MAAM,QAAQ,GAAG,mBAAmB,CAAC,EAAE,MAAM,EAAE,MAAM,EAAE,IAAI,EAAE,IAAI,EAAE,GAAG,EAAE,CAAC,EAAE,CAAC,CAAC;QAE7E,MAAM,CAAC,QAAQ,CAAC,CAAC,OAAO,CAAC,EAAE,MAAM,EAAE,MAAM,EAAE,CAAC,CAAC;IAC/C,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,kEAAkE,EAAE,GAAG,EAAE;QAC1E,MAAM,CAAC,GAAG,EAAE,CAAC,mBAAmB,CAAC,EAAE,MAAM,EAAE,aAAa,EAAE,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC;IACzE,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,0DAA0D,EAAE,GAAG,EAAE;QAClE,MAAM,CAAC,mBAAmB,CAAC,EAAE,CAAC,CAAC,CAAC,OAAO,CAAC,EAAE,CAAC,CAAC;IAC9C,CAAC,CAAC,CAAC;AACL,CAAC,CAAC,CAAC"}

package/dist/filter-tasks/filter-tasks.d.ts

@@ -0,0 +1,26 @@
+import type { Task } from '@opentask/taskin-types';
+import type { TaskFilterCriteria, TaskSummary } from './filter-tasks.types.js';
+/**
+ * Seleciona tarefas por criterio, sem saber como elas serao exibidas.
+ *
+ * Vive aqui, no pacote agnostico, porque a mesma pergunta e feita de tres
+ * lugares: o comando `list`, a saida em JSON e o servidor MCP. Antes eram duas
+ * implementacoes que ja discordavam — o comando casava o responsavel por
+ * substring em nome ou id, e a classe `Taskin` casava `userId` exato.
+ *
+ * Nao ordena e nao muda o arranjo recebido: a ordem que entra e a que sai.
+ *
+ * @public
+ */
+export declare function filterTasks(tasks: readonly Task[], criteria: TaskFilterCriteria): Task[];
+/**
+ * O que identifica uma tarefa numa listagem, sem o que ela diz.
+ *
+ * O provider de arquivos carrega o markdown inteiro em `content` e
+ * `description`. Incluir isso faria a listagem deste repositorio passar de
+ * vinte mil linhas — e quem lista quer **escolher** uma tarefa, nao le-las
+ * todas. O corpo se busca depois, pelo id.
+ *
+ * @public
+ */
+export declare function summarizeTask(task: Task): TaskSummary;