Collabique

Version 0.10.3 makes Collabique search more forgiving and more informative while continuing the recent push to make MCP-based clients feel closer to first-class workspace users. Search results now do a better job of showing why a page matched and helping people recover from misspellings, while external clients can finally create and edit milestones directly instead of stitching that workflow together from lower-level page operations.

• Added MCP milestone create and edit tools so external clients can manage milestone names, deadlines, order, completion state, and codenames directly.
• Tightened MCP document-move and multipart-upload validation so invalid root moves and bad upload targets fail with clearer request handling.
• Highlight search-term matches in page titles and show "Did you mean?" suggestions when Solr finds a likely spelling correction.
• Show the standard fallback avatar more reliably in chat, activity, and profile views when a user does not have a generated avatar thumbnail.

Version 0.10.2 is a small task-list polish release focused on making completed work easier to scan in project views. Closed tasks now keep their deadlines visible without making them look like still-open due dates, so teams can review finished work with less visual ambiguity.

• Show closed task deadlines with a strikethrough style in the project task table.

Version 0.10.1 makes Collabique's MCP document and upload tools behave more reliably in Codex-style clients while also keeping the public release history aligned with the refreshed 0.9 positioning. The main functional change is compatibility: clients that consume Collabique's advertised MCP schemas can now accept and invoke the affected write tools without tripping over schema shapes they do not support.

• Simplified the MCP schemas for document edit, move, soft delete, and file-upload completion so Codex-compatible clients can call those tools successfully.
• Moved paired identifier validation into the writer layer so invalid MCP requests now fail with explicit field-level messages instead of schema-level rejection.
• Restored the collapsed 0.9 release slogan on the public Collabique history site so the release-line summary stays visible alongside older releases.

Version 0.10.0 starts the 0.10 release line with the same shipped product behavior as 0.9.19. This release is an intentional renumbering cut from the same Collabique code and deploy artifact as 0.9.19, so there are no additional user-visible changes in the app beyond what teams already received in that release.

Version 0.9 is where Collabique stops merely exposing external interfaces and starts making them feel complete, consistent, and trustworthy for real operational use. Version 0.8 formalized the idea that different clients could sit on top of the same workspace backend. Version 0.9 builds on that by pushing task and document parity much closer across the browser, CLI, and MCP, while also tightening a few weak spots in files, browsing, and authentication.

That is the real shift. Earlier releases proved Collabique could be used from outside the browser. In 0.9, the product starts behaving as though those outside clients are first-class users of the system, not second-tier add-ons. Tasks, milestones, pages, files, and auth all get refinements aimed at making external workflows less awkward, less lossy, and less dependent on cleanup in the web UI afterward.

A lot of that progress shows up in task parity. Across the 0.9 line, MCP task operations become much more complete: clients can create and edit tasks with assignees, reporters, supporters, labels, priority, requirements, parent-task references, origin links, related wiki pages, and milestone references. Task IDs become easier to target directly, and task tools become clearer about which metadata they accept and how values should be passed. That matters because it closes the gap between what teams can express in the browser and what automations or assistant-driven clients can express programmatically. The task model stops feeling half-open.

The same pattern extends to task maintenance. External clients can now delete tasks and milestones, reorder child documents, move documents and tasks to new parents, and manage labels directly instead of relying on manual follow-up in the browser. Milestone handling gets steadier too, with safer ordering, exact filtering, and better sorting across messy real-world metadata. These are the kinds of improvements that make a system feel operationally whole. It is not just that external tools can create structure. They can now maintain it.

Version 0.9 also makes Collabique better at representing non-document content as real workspace objects. Files become dedicated file pages with their own revision path, views, and integration hooks instead of behaving like loose uploads orbiting around the page model. That is a meaningful maturation step. Files now belong to the workspace in the same way documents and tasks do, and both browser users and external clients can work with them more consistently.

Authentication and integration surfaces get cleaner at the same time. MCP moves toward a modern bearer-token model, token handling becomes more unified across API and MCP access, encryption support gets hardened underneath, and the profile UI presents connection details more clearly. On top of that, MCP browsing becomes more practical with pagination and more focused listing tools for milestones, labels, and filtered task sets. The result is that external clients spend less time guessing and less time over-fetching.

There are also a few smaller but important usability wins woven through the line. New projects now start with seeded task and milestone templates, so structured work begins from a usable model instead of a blank setup chore. Task lists become more readable through deadline columns, better ordering, and clearer overdue highlighting. File-heavy project views get image thumbnails. Solr-backed browsing returns to the main project and child-page listings, keeping navigation aligned with the app's normal indexed behavior.

So the move from 0.8 to 0.9 is not a dramatic reinvention of the core model. It is a completeness release in the best sense. In 0.8, Collabique established itself as a workspace backend with multiple client surfaces. In 0.9, it starts making those surfaces agree with each other, cover more of the real task lifecycle, and behave like reliable entry points into the same system. If 0.8 said, "your tools can build on here," 0.9 says, "your whole workflow can rely on here."

Version 0.8 is where Collabique stops feeling like a browser-first workspace with a few helper APIs and starts acting like a real backend for multiple kinds of clients. Version 0.7 made the workflow system scriptable from outside the browser. Version 0.8 builds on that by standardizing those external interfaces and making them broad enough to support different client types more intentionally.

That is the key shift. The core page and task model from 0.6 and 0.7 remains largely intact. Pages can still be documents, folders, tasks, sheets, and structured records with metadata. Tasks still run on top of page revisions and metadata templates. What changes is the way outside systems are expected to interact with that model. Collabique starts drawing a clearer line between internal browser flows and formal external interfaces.

The CLI API grows into a much more capable operational surface. In 0.7, external tools could already list tasks, comment on them, resolve page paths, and make basic updates. In 0.8, that expands into task creation, task schema discovery, membership-aware user lists, folder creation, child-page listing, metadata patching, template assignment, and JSON row appends. That matters because the app is no longer just exposing a few convenient commands. It is exposing enough structure for outside tools to create and manage real workspace objects properly.

At the same time, 0.8 introduces a second, more standardized machine-facing layer through MCP. This is a bigger architectural signal than any single endpoint. With OAuth, PKCE, dynamic client registration, scoped permissions, and a dedicated MCP document server, Collabique starts supporting external clients through a clearer contract instead of just pragmatic JSON APIs. The CLI remains direct and task-oriented. MCP is more formal, scoped, and model-driven. Together, they make the product feel much more like a platform.

The underlying content model also becomes more machine-friendly. Pages can now expose JSON and binary content paths more explicitly, and external clients can work with hierarchy and metadata in more reliable ways. Folder pages become first-class in both browser and API flows. Task creation gets safer through project-level task index tracking rather than scanning for the next free ID. Milestones become more clearly reference-backed instead of acting like loose enum values. These are the kinds of changes that matter once multiple clients are creating and editing the same system.

Version 0.8 also improves operational consistency around people and integrations. Memberships gain richer role details, and access changes now clean up invalid task assignments automatically. URL metadata fields become first-class. A separate auth path appears for an external web client. Discord ingest starts landing as persisted system data. None of these changes rewrites the core model, but together they make the workspace feel more connected to the systems around it.

So the move from 0.7 to 0.8 is not mainly about new document types or new workflow primitives. It is about interface strategy. In 0.7, Collabique made the workspace scriptable. In 0.8, it starts formalizing how different clients are supposed to use it. If 0.7 said, “your workflow can connect here,” 0.8 says, “your tools can build on here.”

Version 0.7 is where Collabique stops being just a browser-based workflow system and starts becoming an operable platform around that workflow. Version 0.6 turned pages into real work objects, especially through tasks, metadata-driven actions, work-log comments, and automation hooks. Version 0.7 builds on that by making those workflow objects easier to drive from outside the app and easier to inspect in day-to-day operations.

That is the real shift. The core page and task model does not change dramatically. Pages can still be documents, sheets, chapter containers, or tasks. Revisions still carry content and metadata. Tasks still run on top of metadata templates and revisioned state changes. What changes is the control layer around them. Collabique starts exposing a clearer machine-facing interface for tasks, milestones, and pages, so the workspace is no longer only something people click through in the browser. It becomes something other tools can operate against.

The CLI API is the clearest expression of that change. Tasks can now be listed, updated, commented on, and reassigned through compact project-scoped endpoints. Milestones can be listed and closed in a similarly task-oriented way. Pages can be resolved by path, read in explicit output formats, and created or updated programmatically. That makes the document and task model from earlier releases much more usable in real workflows. Collabique starts to feel scriptable.

The same pattern shows up in uploads. Earlier versions handled inline images and comment attachments, but 0.7 adds a dedicated multipart upload system for large project files. That is a different kind of capability. It is not just file support inside a page. It is a separate transfer workflow with object storage coordination, token-authenticated API endpoints, and a handshake to an external uploader. The product starts accommodating heavier operational use, not just richer content.

Version 0.7 also makes work logging easier to read from a human perspective. The timesheet data introduced in task comments now rolls up into a user calendar view, so logged work becomes visible across a month instead of only inside individual tasks. That is a simple change on the surface, but it makes the system feel much more usable as an actual work-tracking environment.

External events begin to matter more too. Perforce activity can now be attached to tasks, and the activity feed adjusts to represent those events more meaningfully. That is another sign of the same transition: Collabique is no longer only tracking what users type inside the app. It is starting to absorb events from the surrounding workflow.

So the move from 0.6 to 0.7 is not a deep model rewrite. It is an operational expansion. In 0.6, Collabique made structured work first-class inside the workspace. In 0.7, it makes that structured work more scriptable, more transferable, and easier to inspect from both tools and people. If 0.6 said, “your work can be run here,” 0.7 says, “your workflow can connect here.”

Version 0.6 is where Collabique stops being mainly a structured document system and starts becoming a workspace for managing work itself. Version 0.5 made pages richer by adding metadata templates, sheets, and more flexible document processing. Version 0.6 builds on that by turning some pages into real workflow objects.

That is the key shift. A page is no longer only something you write, structure, and relate to other pages. It can now also behave like a task, with its own lifecycle, actions, metadata rules, grouping views, and work log. Collabique starts treating structured work as a first-class part of the product, not just structured content.

Tasks are the clearest expression of that change. In 0.5, metadata gave pages schema. In 0.6, that schema becomes operational. Projects can define task metadata templates, generate task IDs, track assignees, milestones, labels, and states, and render task pages through dedicated task views instead of the normal document display. That makes the product feel less like a knowledge base with extra fields and more like a real project workspace.

The supporting workflow gets much stronger too. Tasks can be grouped by milestone, assignee, or label. State changes become explicit actions rather than just manual edits. Comments on task pages become more than discussion, because they can also act as work logs with attachments, timesheet dates, durations, and threaded replies. Revision history grows up alongside this by tracking metadata changes directly, not just body text changes.

Version 0.6 also adds an important safety layer. With autosave, AI edits, metadata updates, and task actions all touching the same pages, stale-save protection becomes essential. This release introduces base-revision checks so the app can detect conflicting edits instead of silently overwriting work. That is one of those changes users may not notice immediately, but it makes the product far more trustworthy.

Automation becomes a much bigger part of the story as well. AI evolves from proposal-based editing into project-scoped assistant conversations that can actually use tools to read and update pages. Webhooks expand the system in both directions, with outbound notifications for page updates and inbound webhook capture for external data. That makes Collabique feel less self-contained and more like a workspace that can participate in broader workflows.

So the move from 0.5 to 0.6 is a real product transition. In 0.5, Collabique broadened what a document could be. In 0.6, it starts specializing those documents into active workflow objects. If 0.5 said, “your knowledge can be modeled here,” 0.6 says, “your work can be run here.”

Version 0.5 is where Collabique stops being just a structured document workspace and starts becoming a mixed-content knowledge system. Version 0.4 made pages hierarchical, draft-aware, and AI-editable. Version 0.5 builds on that by making pages schema-aware, format-flexible, and much more capable of holding structured information alongside writing.

That is the real shift. A page is no longer only a rich text document, a chapter rollup, or a draftable node in a page tree. It can now also carry typed metadata through project-defined templates, and its revisions can store different body formats, most importantly sheets. This changes the product in a fundamental way. Collabique is no longer just organizing documents. It is starting to organize documents and data together.

The metadata system is a big part of that change. Projects can now define reusable metadata templates, and pages can inherit or attach to them. That means pages are not only described by title, body, and hierarchy anymore. They can also carry structured fields like references, dates, enums, numbers, booleans, and text. Just as importantly, that metadata becomes part of the page experience, not hidden configuration. It shows up in the page rail, it can link pages together explicitly, and it can be queried and reused across the workspace. The product starts to feel less like a set of pages and more like a connected information model.

Sheets are the second major leap. In earlier versions, Collabique had one main document world with different display modes layered on top. In 0.5, revisions themselves can now represent a sheet body format backed by JSON and rendered through a separate pipeline. That makes sheets a first-class page type, not a hack inside rich text. And these sheets are not passive grids. They can reference pages, pull metadata from them, compute values like summaries and word counts, and even populate themselves from parts of the page tree. That is a major expansion of the product’s ambition. Collabique starts to look not just like a writing workspace, but like a lightweight system for structured planning, tracking, and reporting.

The document pipeline also gets broader. Rich text pages can now embed other pages more directly, split into sibling documents through explicit breakpoints, and move through a more general processing layer. That makes authoring feel more modular and more intentional. Documents are no longer only edited as isolated units. They can be composed, forked, and connected in more deliberate ways.

AI editing matures in the same release. In 0.4, AI could propose changes inside a review flow. In 0.5, that proposal system becomes asynchronous and streamed. Instead of waiting for one completed result, the browser receives the proposal progressively, then drops into the same accept-or-reject review loop once the output is finished. That makes the editing workflow feel more like part of the product’s live system and less like a blocking helper bolted onto the side.

So the move from 0.4 to 0.5 is not just a feature expansion. It is a broader definition of what a page can be. In 0.4, Collabique treated pages as structured, draft-aware documents. In 0.5, it treats them as flexible knowledge objects that can combine writing, schema, references, and tabular structure inside the same workspace. If 0.4 said, “your work can be shaped here,” 0.5 says, “your knowledge can be modeled here.”

Version 0.4 is where Collabique stops treating a page as a single stateful document and starts treating it as a structured document system. Version 0.3 gave pages history, activity, chat, archive state, and lifecycle. Version 0.4 builds on that by making pages hierarchical, draft-aware, and much more deeply shaped by AI.

That is the real shift. A page is no longer just one document with revisions around it. It can now be a parent, a child, a chapter container, or a generated rollup of other pages. Projects stop behaving like flat collections of documents and start behaving more like organized knowledge trees. Top-level browsing focuses on root pages, child pages can be ordered directly, and display modes let a page act either as its own document or as a composed view over its descendants.

That change makes the workspace feel much more editorial. A long document can be split into subpages. Child pages can be reordered intentionally. Parent pages can present raw chapter content or AI-generated summaries of those chapters. The product starts supporting not just writing and revising documents, but shaping larger bodies of work into clearer structures.

Version 0.4 also introduces a more meaningful draft model. In 0.3, revisions were mainly about history and recovery. In 0.4, autosave creates a real distinction between draft state and live state. The app can now preserve unsaved work as autosave revisions without immediately replacing the published version. That makes editing feel safer and more modern, while also making page history more honest about the difference between background drafting and intentional saves.

The AI layer gets much deeper too. Earlier versions already used AI for summaries and guided creation, but in 0.4 AI moves into the editing path itself. Users can run editing passes in different modes, review proposed changes side by side, accept or reject individual edits, and merge the result back into the page. That is an important product step. AI is no longer just helping around the document. It is now participating in the document, with the app providing a real review loop instead of forcing blind replacement.

Rendering becomes more flexible in the same release. A page is no longer always just its stored body. Depending on display mode, it may render its own content, a composed set of child chapters, or a processed summary of those child pages. Table of contents generation also becomes part of that display pipeline, making longer structured pages easier to navigate.

So the move from 0.3 to 0.4 is not just more capability. It is a deeper change in what a page is. In 0.3, Collabique treated pages as stateful collaborative documents. In 0.4, it treats them as document nodes in a larger system, with structure, draft/live semantics, and AI-assisted transformation built in. If 0.3 said, “your work can live here,” 0.4 says, “your work can be shaped here.”

Version 0.3 is where Collabique stops feeling like a collaborative document editor and starts feeling like a real workspace system. Version 0.2 made the product more searchable, expressive, and collaborative. Version 0.3 builds on that by making pages stateful.

That is the real shift. A page is no longer just something you write, edit, and comment on. It now has lifecycle, history, status, activity, chat, archive state, and API-readable forms. Pages can be discussed, revisited, reverted, archived, surfaced in feeds, and accessed programmatically. The product starts treating documents less like static content and more like living units of work.

You can feel that change across the workspace. Activity feeds add a real sense of motion. Page chat adds a broader discussion layer beyond inline comments. Historic views and revert actions make revision history more useful. Archive screens and page options make lifecycle management clearer. Search becomes more serious too, with stronger indexing, highlighting, filtering, and pagination, so knowledge is not just stored, but actually navigable at scale.

Project views also become more operational. Instead of simply listing pages, they now surface richer metadata like word count, revisions, comments, and chat activity. That makes projects feel less like folders and more like active bodies of work.

At the same time, Collabique starts opening outward. API endpoints for reading and creating pages, plus version awareness and token-based access, make the system feel more like a platform and less like a browser-only tool. Under the hood, the frontend and test infrastructure also mature to support a more dynamic, eventful product.

So the move from 0.2 to 0.3 is not just more features. It is a deeper product transition. In 0.2, Collabique helped teams create and discuss work together. In 0.3, it helps that work persist, evolve, and stay visible over time. If 0.2 said, “your ideas can grow here,” 0.3 says, “your work can live here.”

Version 0.2 is where Collabique moves from a solid writing foundation to a real creative workspace. Version 0.1 proved ideas could live here. Version 0.2 helps them move.

Search is the biggest shift. It makes pages easier to find, revisit, and reuse, turning saved knowledge into working knowledge. The editor also gets stronger, with smoother linking, richer formatting, and a more natural writing flow that makes shaping ideas feel easier.

Collaboration becomes much more central in this release. Inline comments bring feedback directly into the document, so discussion happens in context, exactly where the work is happening. Profiles, avatars, and better membership flows also make the workspace feel more human, more social, and more clearly built for teams.

Version 0.2 also pushes Collabique further toward guided creativity. Templates, questionnaires, and brainstorm flows make it easier to get started, especially when a team has momentum but needs structure. Import and export features help Collabique fit more naturally into real workflows instead of feeling like a closed system.

The result is simple: 0.2 makes Collabique more searchable, more collaborative, and more useful for creative teams. It feels less like a place to store pages and more like a place where ideas can be developed, refined, and moved forward together.

Collabique is where creative work starts to feel real. Version 0.1 is the first big step, the moment this product becomes something teams can actually use to capture ideas, shape projects, and build momentum together. It is the beginning of a writing experience built for people who create.

At its core, Collabique gives creative teams a smarter home for ideas. It is not just a place to drop notes or pile up documents. It is a workspace where concepts can take shape, pages can grow into shared knowledge, and projects can develop with clarity and energy. For writers, strategists, designers, founders, and makers, that is a big deal. Great work needs more than storage. It needs structure, flow, and a space that helps people think better together.

What makes Collabique exciting is that it treats documentation as a living part of the creative process. Teams can create, shape, and organize work across companies, projects, and pages in a way that feels natural, visual, and purposeful. From the very beginning, the product is built around the idea that knowledge should be active, connected, and useful.

And that changes everything.

Because once there is a real place for ideas to live, creativity accelerates. A brainstorm becomes a page. A page becomes shared understanding. Shared understanding becomes alignment. And alignment becomes action. Collabique turns documentation into a creative engine, a place where ideas are captured, refined, connected, and moved forward.

This is especially compelling for creative teams and ambitious individuals who need more than a blank page. They need a workspace that feels collaborative, organized, and alive. Collabique gives them that foundation. It creates the conditions for better thinking, stronger communication, and faster progress. It helps teams turn scattered inspiration into something tangible and shared.

Version 0.1 is the start, but it already makes the vision clear. Collabique is built for people with ideas worth developing and teams with work worth aligning around. It is not just another app. It is the start of a better creative workflow, a place where people can write with purpose, collaborate with confidence, and turn momentum into something real.