Arrows from an epic to the ones that wait for it («bloquea» / «depende
de»), drawn over the bars; dashed red, plus a note in words, when one
starts before the epic blocking it ends. The next batch and the ideas
kept or dropped are written down in docs/10-futuro.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Text, number, date or option-list fields defined in the project settings
(archived, never removed; their type is fixed once saved). Tickets hold
them, edited in the side panel, listed under the title and filtered by
option in the list view; also over GraphQL, REST (?field=ID:value) and MCP.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- What reaches the bell also reaches the devices where the person
turned «Avisos en este dispositivo» on, with TaskStream closed: the
Notifier sends each new notification encrypted (aes128gcm) and signed
with VAPID, and forgets subscriptions the push service dropped
(404/410). A failure never blocks the event stream.
- The API keeps one subscription per device (push_subscriptions) and
exposes the VAPID public key in the notification settings; GraphQL
subscribePush/unsubscribePush, REST /me/push-subscriptions. Without
VAPID_PUBLIC_KEY and VAPID_PRIVATE_KEY push is off.
- The web registers /push-sw.js, a service worker that only shows the
notification and opens its ticket on a tap (no caching, served
without cache by nginx), and a manifest that makes it installable,
which iPhones need for push.
- The bell's toggles show their text next to them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Each person can subscribe their dates in Google Calendar, Outlook or
Apple Calendar: GET /api/calendar/{token}.ics (no session) brings
their unfinished tickets with a due date (assigned or followed), the
planned and running sprints and the planned releases of their
projects, as all-day events linking to the web. The token is made,
renewed or dropped under /me/calendar (and in GraphQL); in the web,
from «Calendario» in «Mi trabajo».
- The backlog panel keeps the selected rows' background inside its
rounded corners.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Bulk editing gets «Release…» (open releases or none), and the list
view a release filter, also reachable from each release («Ver en la
lista», ?release=).
- Archiving a release asks where its unfinished tickets go, as closing
a sprint does: ReleaseArchivedEvent carries `moveTo` (an open release
of the same project, or none) and the saga moves them there; finished
ones stay. In GraphQL, REST and the MCP's archive_release.
- Chapter 10 lists the next features and the ideas to weigh.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Mongo read models are @Schema/@Prop classes (SchemaFactory), still
loose: the props declared are the indexed or shaped ones.
- CommandBus and QueryBus are used by the application services alone.
Duplicating a ticket, bulk updates, CSV imports, proposals and
emptying the trash chain several commands, so they are service
methods now and their composite commands are gone; every command
handler is atomic. No forwardRef is needed.
- The due-date and trash timers are entry points: they live in the
presenters and call the services. The automations event handler has
its own file and calls AutomationsService.
- The tracker's user directory asks IdentityService; the composition
root hands the identity application module to the tracker
infrastructure (withIdentity), with no global module.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Postgres: every table has a uuid `id` (gen_random_uuid()); the event
store keeps its relay order in `seq`, and the lookup tables their
uniqueness in constraints of their own.
- MongoDB: `_id` is Mongo's ObjectId; `id` is the domain id (the same
uuid as the aggregate's stream in Postgres), unique, and every query
goes by it. Production starts from empty databases.
- Web: linking tickets and hanging one from a parent are picked from a
searchable select (links across projects, parents within the project)
instead of typing a key; every checkbox is @pi/ui's pi-checkbox.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ts-rich-editor (TipTap) shows the formatting while writing: bold,
italic, strike, code, headings, lists, task lists, quotes, code blocks
and links, with @ suggesting the project's members and pasted
screenshots uploaded as attachments. It reads and writes the same
Markdown the API keeps (mentions as @[Name](id), images as
attachment:<id>, tables too), so nothing already written changes.
Used for comments, replies, editing a comment or a description, a new
ticket from the board and the public proposal form; the Markdown hint
and the paste directive are gone. List markers sat on a line of their
own, and task lists showed a stray bullet, in the editor and when read.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The library no longer registers Chart.js on import nor depends on lodash,
so the size warning is gone. Chapter 10 updated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- The web pings the live connection, reconnects when it goes quiet and
reloads what each screen shows after reconnecting.
- Dropping a card on a column it cannot go to puts it back.
- Owners and admins get a notice when a proposal arrives.
- The proposal limit lives in Redis, so it holds across instances.
- REST tells whether I voted; pasted images leave the attachment list.
- Deleting a project removes its Git integration; no lint warnings left.
- Reactions and the blocked badge are components of their own.
- Docs: what is done and what is left (chapter 10), Word and PDF.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
What it takes to call the product done in production, the known bugs and
debt, the next features in order and what is set aside for now. The note
on chat notifications moves here from the docs index. Word and PDF
regenerated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Formatted text
- Descriptions, comments, replies and release notes render Markdown,
sanitised with DOMPurify (tested against scripts, handlers and
javascript: links). A pasted image is uploaded and written as
; the web fetches it with the reader's session,
so it works on private projects. Every text box has a preview. The
attachment upload now answers its attachmentId.
List view
- /p/:key/list: every ticket as rows, sortable by any column, filtered by
text, open/closed, type, priority and assignee; status, priority and
assignee change in place; bulk edit (the backlog's bar, now shared).
Ticket details
- Reactions on comments (GitHub's eight), for members and viewers.
- Duplicate a ticket: what it says, not where it stands.
- blockedBy: open tickets it waits for (BLOCKS / DEPENDS_ON), worked out
when reading with one query per board or page; shown on cards, list
rows and the ticket.
Public proposals
- A public project can take bug reports and ideas from anyone
(acceptsProposals): POST /api/explore/projects/{project}/proposals and
the form at /p/:key/proponer. They become tickets labelled «propuesta»,
opened by TaskStream; a honeypot field and 5 per address every 15
minutes keep spam out. No e-mail is asked: it would be public.
Votes
- Anyone signed in votes on a public project's tickets, members on a
private one (voteIssue, PUT/DELETE /api/issues/{issue}/vote): votes and
voted on each ticket, buttons on the ticket and the roadmap, a column
in the list. The showcase carries votes and the open proposals.
MCP: vote_issue, duplicate_issue, react_to_comment; listings show
blockers and votes. Docs, Word and PDF updated; chat notifications
(Discord, Slack, Telegram) noted for later.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Like a commenter, whoever opens a ticket and whoever it is assigned to
(also on reassigning) follow it from then on, so they hear of its
priority, due date and sprint changes and find it under "Que sigo".
Existing tickets are left as they are. Docs, Word and PDF updated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"Que sigo" on the home page lists the open tickets I follow, whoever
works on them; `watching` filters my issues (REST, GraphQL, MCP) and a
project's search (none without a session).
Followers now also hear when a ticket's priority or due date changes,
and when it enters or leaves a sprint. Smaller edits (title, labels…)
still do not notify.
Docs (with the REPLIED row the replies change missed), Word and PDF
updated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A comment can answer another one (replyTo), one level deep: answering a
reply joins the same thread, and it must be on the same ticket. Whoever
wrote the comment gets a new REPLIED notification, and the activity says
"respondió a un comentario".
A comment deleted while it has replies stays, without its text
(deleted: true), so the thread still reads; it goes with its last reply
and does not count in commentCount.
The ticket page shows threads with their replies indented and a
"Responder" box; REST, GraphQL and the MCP (add_comment, get_issue) take
and show replyTo. Existing comments are unchanged. Docs, Word and PDF
updated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A project keeps a list of repositories (api, web, admin…), each with its
own secret, instead of a single webhook secret. They all call the same
URL; the secret that verifies the signature tells which one it was, and
every commit, branch or pull request is linked with its repository's
name (shown on the ticket and in the MCP). Rotating or removing one
leaves the others alone, and what it linked stays.
A project that had turned the single webhook on keeps its secret, as a
repository named "principal".
API: the enable/disable endpoints and mutations give way to adding a
repository, rotating its secret and removing it (REST and GraphQL). The
web settings card lists the repositories. Docs, Word and PDF updated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Thirty new tools (54 in all) for what the API gained since the MCP:
create a project and read its public showcase; sprints (list, progress
and burndown, plan, change, start, close with carry-over, delete, move a
ticket in or out); epics and the backlog (list epics with progress, set
a ticket's parent, rank); bulk edit of up to 100 tickets by key, saying
which refused; the trash; checklists; following a ticket, removing a
relation, editing and deleting comments; editing and archiving releases,
drafting and saving their notes; notifications.
Searching filters by epic, sprint and dates and sorts by backlog order;
get_issue shows parent, checklist, commits and followers; create and
update take parent and start date.
API: `unreadOnly` and `dryRun` were documented as objects in the
OpenAPI; they are booleans now. Chapter 9 lists every tool; Word and PDF
regenerated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Logs default to warnings and errors (MCP_LOG_LEVEL): the library logged
every tool on every request (~48 lines per call).
- DNS rebinding protection on /mcp, as the MCP spec asks of HTTP servers:
the Host header must be in MCP_ALLOWED_HOSTS (default: localhost; compose
default mcp.taskstream.pireon.dev,localhost) and a browser Origin, when
present, too; otherwise 403 with a JSON-RPC error. Uses the official
validators from @modelcontextprotocol/server.
- Test for allowed/foreign Host and Origin; .env.example, compose and
docs/09-mcp.md document the variables; Word/PDF regenerated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
New app apps/mcp (NestJS + @nestjs-mcp/server 2): Streamable HTTP at
POST /mcp, stateless.
- 24 tools: projects (mine, public, details with settings, board, stats,
analytics, activity), tickets (my work, search, details with comments and
history, create, update, move, assign, release, comment, link), releases
(list, upcoming, details with progress and burnup, create, publish) and
users (whoami, search). Admin operations stay in the web.
- No credentials of its own: each call's Authorization header (a Pireon
token) is forwarded to the API; without it only public projects are read.
- Typed REST client generated from apps/api/openapi.json (openapi-fetch +
openapi-typescript via `nx run mcp:openapi-types`); API refusals become
readable tool errors; parameters validated with zod.
- Tests: the real MCP against a simulated API (token forwarding, errors,
validation, writes).
- Docker target `mcp` (Node 24) and an optional compose service under the
`mcp` profile; zod declared as a root dependency.
- Docs: chapter 9 «Servidor MCP», references in 01/06/07 and the index;
Word/PDF regenerated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Public projects:
- Project.isPublic (create/update, owners and admins). Anyone can read a
public project without a token: project, board, tickets, comments,
history, releases, activity, tracking and statistics, over GraphQL and
REST. Writes stay for members (401 anonymous, 403 outsiders).
- @OptionalAuth() / @ApiOptionalPireonAuth(): anonymous callers allowed,
invalid tokens still rejected. ReadAccess lets anonymous viewers read
public projects only; linked tickets are filtered by visibility.
- publicProjects (GraphQL) and GET /api/explore/projects (REST).
- Web: «Explorar» page, project pages open without a session (read-only
notice, sign-in hints), public badge, visibility switch in settings,
no realtime subscriptions without a session.
Project deletion:
- Owner only, confirming the key (deleteProject / DELETE
/api/projects/{project}?confirm=KEY). The key is freed; the read model
drops the project and members are notified (web goes home).
Sagas (run by the EventsBridge after projections, durable and ordered):
- ProjectDeletionSaga: project deleted → delete its tickets and releases;
ticket deleted → purge its comments and drop links from other tickets.
- ReleaseArchivedSaga: unfinished tickets leave an archived release.
- UserDeactivatedSaga: the Pireon webhook records UserDeactivatedEvent in
the event store (EventRecorder); the tracker unassigns that user's open
tickets as the system actor.
- Internal idempotent commands; domain refusals are logged and skipped,
concurrency conflicts retried. Affected streams come from the event store
(TrackerStreamsRepository).
Tests: domain lifecycle specs, saga specs run like the bridge, facade
tests, e2e for public access, cascade deletion, archived releases and
deactivation webhook. Docs, READMEs, schema.gql/openapi.json and Word/PDF
updated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Per-project settings (owners/admins, «Configuración» tab):
- Statuses with category (TODO, IN_PROGRESS, QA, DONE, CANCELLED), colour and
"requires reason"; configurable transitions; ticket types (icon, colour) and
areas. Defaults are the previous fixed values; projects created before keep
them without migration.
- Values are archived, never deleted: tickets, history and statistics keep
referring to them. Validated in the domain (ProjectSettingsChangedEvent).
- Releases, board, tracking and "my work" use categories, so custom statuses
keep working. Status changes carry name/category metadata for history.
- GraphQL: status/type/area are strings (breaking for clients sending enum
literals); Project.settings, updateProjectSettings, statusCategory,
myIssues(categories). REST: PUT /projects/{project}/settings, category filters.
- Read model: statusCategory on issues (backfilled at startup).
Statistics («Estadísticas» tab):
- New issue_timeline projection; pure functions compute created vs resolved,
cumulative flow, cycle/lead time (avg + p85), throughput per person, QA
pass/fail and release burnup. GraphQL Project.analytics(days),
Release.burnup; REST /projects/{project}/analytics, /releases/{id}/burnup.
- Web: SVG charts with validated light/dark palette, crosshair tooltip,
keyboard navigation, legend and data table.
Home "Mi trabajo": my open tickets across projects grouped by category (QA
failures first), tickets waiting for QA, upcoming releases and "Ir a…".
Tests: domain/application specs, e2e scenario for settings and analytics,
facade tests. Docs, READMEs, schema.gql/openapi.json and Word/PDF updated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"¿Quién está con qué?" only listed people with open tickets. The tracking
page now shows the whole team: every member with their role and open
tickets (0 included), busiest first, plus former members who still have
tickets and the unassigned count. Each person links to the board filtered
by them: the board accepts ?assignee= like ?release=.
Role colours move to ui/copy.ts (shared with the members page). Docs and
Word/PDF updated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Registering clients: the authorization_code client is confidential and needs
its secret; Pireon shows it once (rotate-secret if lost); containers must be
recreated to read new environment variables.
- Production URLs (taskstream.pireon.dev, api.taskstream.pireon.dev) and their
redirect URIs.
- "Si el login falla": each error seen while deploying (not configured,
unauthorized_client, missing client_secret, invalid_client, redirect URI,
expired code, wrong credentials, intermittent 404s) with cause and fix.
- READMEs mention both clients; Word/PDF regenerated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Pireon OAuth clients allow a single grant type. With one PIREON_CLIENT_ID of
type password, email + password worked but "Sign in with Pireon" failed with
`unauthorized_client`.
- PIREON_CLIENT_ID/SECRET: authorization_code client (Sign in with Pireon,
Swagger UI). New PIREON_PASSWORD_CLIENT_ID/SECRET: password client, falling
back to the former so existing setups keep working.
- Refresh tries both clients: a refresh token only works with its issuer.
- PIREON_PASSWORD_GRANT=false now also rejects password grants in the API
(before it only hid the form).
- /api/auth/config returns clientId: null when there is no authorization_code
client, and the web hides "Sign in with Pireon".
- docker-compose passes the new variables; docs 05/07, .env.example,
openapi.json; unit tests for the client selection.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
In Dokploy, services with a domain join the shared dokploy-network, where
another project also has an `api`. nginx proxied /api to `api:3000`, so
Docker DNS returned both containers and half of the requests went to the
other app: 404 "Cannot POST /api/auth/token" on sign-in and "sign-in not
configured" when /api/auth/config was answered by it.
Services now get task-stream-* aliases on the project network and nginx and
the API use them (task-stream-api, -postgres, -mongo, -redis). The API's
OPENAPI_FILE is empty in the container; docs 07 explain the aliases.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
docker-compose.yml is the production definition (deployed by Dokploy) and no
longer publishes any port: postgres, mongo, redis and the API are reachable
only on the compose network, and the web goes out through the platform's
proxy (domain → service web, port 80). The ports moved to
docker-compose.override.yml, which Compose loads automatically locally and
Dokploy (-f docker-compose.yml) does not.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Dokploy builds failed with "failed to stat /root/.npmrc": the compose build
secret pointed at ${HOME}/.npmrc, which only exists on a developer machine.
The token now comes from the NEXUS_TOKEN environment variable (Dokploy's
Environment tab or .env), is written to a temporary npmrc and removed in the
same RUN, so it never lands in an image layer.
Also removes a temporary UI dev-server spec that was committed by mistake,
and documents the variable (.env.example, docs 06/07, Word/PDF export).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
