Collabique

Version 0.9.18 keeps pushing Collabique's task tooling toward a more complete external planning API. MCP clients can now set more of the same structure that people already care about in the browser, instead of creating a task and then needing follow-up cleanup or extra discovery calls. Priority, dependency-style requirements, richer metadata guidance, and safer label representation all move the integration surface closer to the real day-to-day task model.

• MCP create_task and edit_task now accept numeric priority values directly, so integrations can set or update task urgency in the same write operation.
• MCP create_task and edit_task now accept REQUIREMENTS references, which lets external clients link prerequisite tasks by UUID, task:// URI, or visible TASK_ID.
• MCP task tool descriptions now spell out the supported task metadata fields and expected formats more explicitly, which makes client-side validation and form generation more practical.
• Task labels can now behave as optional references instead of only loose strings, while task views and integrations still resolve them to readable display names.

Version 0.9.17 finishes an obvious missing piece in Collabique's MCP task workflow. Before this release, external clients could already create tasks, edit tasks, move task metadata around, and generally participate in planning, but assignment still had to be cleaned up by hand in the browser afterward. This patch removes that last awkward seam. Task routing, triage bots, automated intake flows, and handoff tooling can now create or update a task and assign the right people in the same write operation, which makes the MCP surface feel much more complete and trustworthy for real project operations.

• MCP create_task and edit_task now accept assignees directly instead of treating assignment as a browser-only follow-up step.
• Assignees can be passed as user UUIDs, email addresses, or display names, which makes the tools practical for both strongly typed clients and looser human-assisted automations.
• Task writes now resolve and validate each requested assignee against actual project members, and callers can clear all assignees by passing an empty list.

Version 0.9.16 is a small release, but it makes the task list feel much smarter at a glance. Earlier deadline styling treated "this task was once late" and "this task still needs immediate attention" almost the same way, which made busy boards noisier than they needed to be. This patch tightens that signal. The deadlines that remain visually loud are the ones that still matter, and work due today gets its own distinct look instead of being lumped in with already-overdue tasks.

• Overdue task deadlines now stay red only for open tasks, so finished or rejected work no longer reads like an active deadline problem.
• Open tasks due today now render in yellow, which gives teams a separate "needs attention soon" signal without overstating the urgency.

Version 0.9.15 is a good example of Collabique getting better for both people and automation at the same time. In the browser, overdue work becomes more visible in task views, which helps planning meetings and triage sessions converge faster. Outside the browser, the CLI and MCP surfaces finally gain two missing maintenance operations that teams routinely need: label management and document reordering. The result is that scripted workflows can do more of the real cleanup and organization work that used to force a jump back into the web UI.

• Task views now highlight overdue deadlines more clearly, so urgent items are easier to notice during routine planning and backlog grooming.
• CLI and MCP task workflows can now set, replace, and clear labels with the same normalized behavior, instead of leaving label management to manual browser edits.
• CLI and MCP can now reorder child documents directly, which means automated documentation flows can preserve the intended page order without browser-only follow-up.

Version 0.9.14 makes Collabique feel less mechanical in two places that matter a lot in practice: browsing file-heavy projects and targeting existing tasks from integrations. Image uploads now look like images when you browse project lists instead of hiding behind a generic file placeholder, so visual assets are much easier to recognize at a glance. At the same time, MCP task tools stop insisting on internal identifiers when the human-facing TASK_ID is what people actually know and share. That cuts out unnecessary lookup chatter in external clients and makes browser lists more informative at the same time.

• Project page lists and child-page lists now render thumbnails for uploaded image file pages instead of the generic file placeholder.
• MCP edit_task now accepts visible human task IDs in addition to the lower-level UUID and resource-style identifiers.
• MCP task listing can now filter for an exact visible TASK_ID, which helps automation find the right task without scanning or guessing through the full project list.

Version 0.9.13 is much more than a cosmetic reorder patch. It continues the recent push to make Collabique's task ecosystem feel equally strong in the browser, the CLI, and MCP-driven tools. Project task lists now behave more like deadline-first planning boards, milestone sorting becomes safer in the face of messy legacy metadata, and external clients finally gain delete operations for tasks and milestones instead of being able to create structure without being able to clean it up. For teams using Collabique as an operational system rather than just a note-taking app, this is a meaningful completeness release.

• Project task lists now sort by earlier valid deadlines before priority, which better matches deadline-driven planning and triage workflows.
• CLI and MCP milestone listings now handle mixed integer, numeric-string, text, and blank ORDER values without throwing sort errors on older or inconsistent projects.
• CLI and MCP can now delete tasks and milestones directly, so external tools can fully maintain work structures instead of creating state they cannot later retire.
• The release continues the push toward shared behavior across interfaces, so browser, CLI, and MCP task workflows diverge less than they did in earlier patches.

Version 0.9.12 fixes the kind of bug that looks small in code and surprisingly disruptive in day-to-day planning. Teams that use milestones as a real roadmap often rely on an explicit ordering field, but the task view could still drift back toward title-based grouping in some cases. That meant milestones with names like "March", "April", "Phase 10", or custom labels could appear in an order that made visual sense to the computer but not to the team. This patch makes the milestone sections honor the saved ordering metadata again, so the page reads like the roadmap people intended to build.

• Project task lists now group milestone sections by the milestone ORDER value instead of falling back to title sorting when rendering the board.

Version 0.9.11 is mostly a stability and packaging release, but it still removes a real operational annoyance. Older projects and hand-edited milestone metadata do not always keep ORDER values perfectly consistent, and the CLI or MCP list views could pay the price for that inconsistency. This patch hardens the sorting behavior so mixed numeric, string, text, and blank values no longer blow up the listing path. The visible effect is simple: integrations keep working on imperfect real-world data instead of failing on metadata edge cases.

• CLI and MCP milestone listings no longer raise sorting errors when milestone ORDER values mix integers, numeric strings, text, or blank values.

Version 0.9.10 sharpens task ordering for teams that care about both priority and the calendar. Earlier releases already started surfacing deadlines more clearly, but this patch makes the within-priority ordering more useful by preferring earlier valid deadlines over later or missing ones. That means urgent work stops getting buried among equally prioritized tasks just because the list has no secondary time-based signal. On the integration side, the bundled MCP layer also moves forward to a newer Ruby SDK baseline while preserving Collabique's pagination behavior, so client compatibility stays aligned with the current implementation.

• Project task lists now keep priority as the primary sort, then place earlier valid deadlines ahead of later or missing deadlines inside the same priority bucket.
• Missing or malformed deadlines stay at the end of their bucket instead of disrupting the visible order.
• The bundled MCP integration now tracks the upstream Ruby SDK 0.10.1 baseline while preserving Collabique's compatibility behavior for paginated resources/list clients.

Version 0.9.9 gives task lists a much better sense of time. Instead of hiding deadline information inside the task body or metadata pane, Collabique now surfaces it directly in the project task list whenever the active task template defines a deadline field. That sounds simple, but it changes how quickly people can scan a board, especially when the list is being used as a schedule rather than just a backlog. The release is also careful about bad data, so blank or malformed deadlines quietly stay out of the way instead of breaking the whole page.

• Project task lists now show a DEADLINE column whenever the active task metadata template defines that field.
• Deadline values render as YYYY-MM-DD, which makes them compact and easy to scan in list form.
• Blank or malformed deadline metadata is ignored safely instead of crashing or corrupting the page layout.

Version 0.9.8 fixes one of the nastier regressions in the recent MCP work. Some task edits coming from MCP clients could accidentally store the result as an ordinary document revision instead of a task revision, which effectively made the task vanish from task-specific screens even though the content still existed. This patch closes that hole and, just as importantly, gives teams a way to repair already-affected tasks without rewriting them by hand. It is the difference between "the data is still somewhere in the system" and "the task workflow is actually trustworthy again."

• Tasks edited through MCP now remain task revisions, so they stay visible in task lists, task pages, and other task-specific flows instead of silently degrading into generic documents.
• MCP task bodies are saved on the correct task revision path, which prevents future edits from breaking the task/document distinction.
• Teams can now repair already affected tasks without losing current content, metadata, or revision history.

Version 0.9.7 is a tiny release in terms of scope, but it fixes a very visible break in a brand-new feature area. The main file-details partial could raise an error while rendering the action buttons, which meant a file page could fail at exactly the moment somebody was trying to open or download the file it existed to represent. This patch removes that regression and restores the basic confidence that file pages can be browsed and used like normal project content. It is the kind of small patch that matters because it lands right on top of a core user action.

• Viewing a file page no longer crashes while rendering the Open and Download actions, so uploaded files and external file links can be accessed normally again.

Version 0.9.6 makes brand-new projects feel far less empty and much more intentional. Before this patch, teams that wanted to use Collabique for structured task work still had to do a lot of template setup by hand before the task and milestone features really came alive. Now new projects are born with a usable schema instead of a blank slate. That shortens the path from "create project" to "start tracking work" and also nudges different projects toward a more consistent shared model.

• New projects now start with seeded task and milestone metadata templates instead of requiring manual template design before structured work can begin.
• The default task template includes richer starter fields such as labels, assignees, supporters, blockers, wiki links, priority, and parent-task references.
• The milestone template now matches the conventions already used by MCP and task flows, so new projects behave more consistently across the browser and integration surfaces.

Version 0.9.5 is one of the most substantial patches in the 0.9 line because it upgrades both the content model and the access model at the same time. On the content side, files stop behaving like loose upload blobs and become real page-like objects with revisions, dedicated views, and proper integration hooks. On the access side, Collabique stops treating API tokens and MCP tokens as separate worlds and moves to one shared bearer-token model. The product ends up feeling more coherent in both places: files belong to the workspace instead of orbiting around it, and external clients authenticate through a cleaner, more unified story.

• Uploaded files can now live as dedicated file pages backed by their own file revisions, which makes them durable project content instead of detached attachments.
• The web UI, API, CLI, and MCP layers can all create, read, and update file pages, including chunked upload flows for larger programmatic transfers.
• File page reads can return raw file responses and stable URLs for programmatic consumers, which makes integration use cases much more practical.
• User-managed access now flows through a shared access-token model across API and MCP usage, with renamed access-token management in the user profile.

Version 0.9.4 makes the MCP surface feel less like a raw catalog and more like an actual integration API. Earlier clients could technically crawl Collabique resources, but they had to discover a lot of useful task structure indirectly and with more round-trips than they really wanted. This patch introduces dedicated list tools for the kinds of project data external clients actually need to show and filter work. That means less guessing, less over-fetching, and a much cleaner first-run experience for task-aware MCP consumers.

• MCP clients can now list milestones directly instead of inferring milestone structure by walking the broader resource tree.
• MCP clients can now list labels and filtered task sets through dedicated tools, which makes task-aware integrations much easier to build.
• Task list responses now include assignee and reporter summaries, so clients can render more useful task context without extra lookup calls.

Version 0.9.3 is a quiet but meaningful release for anyone pointing an MCP client at a large Collabique workspace. Instead of forcing the server to materialize the whole resource catalog just to answer a list request, Collabique can now page through results incrementally and hand the client a cursor for the next slice. At the same time, revision previews become more deliberate and reusable, relying on cached preview bodies instead of eagerly warming everything up. Most browser users will never see this directly, but large-project integrations should feel notably more predictable and less wasteful.

• MCP resources/list now supports paginated nextCursor responses, so clients can browse large resource catalogs incrementally instead of asking for everything at once.
• Cached revision previews are now reused more intentionally, which makes document preview browsing cheaper and more stable for integration clients.
• Preview generation remains lazy, so Collabique no longer needs to warm large catalogs just because a client started browsing them.

Version 0.9.2 is a narrow compatibility release, and it is narrow on purpose. There is no new visible workflow here, but the patch broadens Active Record encryption query support so the newer encrypted access and token paths behave more reliably under normal runtime lookups. In other words, it strengthens the infrastructure underneath the authentication work that landed just before it. For most teams the product should feel the same as Version 0.9.1, only steadier.

• Encrypted access and token queries now work with the broader query support needed by Collabique's newer bearer-token flows.

Version 0.9.1 is the release where MCP authentication starts looking like a modern API instead of a product-specific special case. Rather than baking the secret into the endpoint URL, Collabique now expects a standard bearer token on /mcp, and the user profile presents the endpoint and the secret as two separate things. That makes setup clearer for humans, much easier for client libraries, and more consistent with the rest of the integration ecosystem. The patch also hardens token storage with Rails encryption while still keeping a migration bridge for older callers that have not yet been updated.

• MCP now authenticates with a bearer token on /mcp instead of relying only on a secret-bearing URL pattern.
• The profile UI now shows the MCP endpoint as ordinary connection information and the secret token as a separate value, which makes setup much clearer.
• Stored MCP tokens are now encrypted, and the older URL-based auth path remains available as a deprecated compatibility bridge while clients migrate.

Version 0.9.0 is small on the surface, but it matters because it makes Collabique more honest to connected tools. MCP clients make rendering and handling decisions based on the metadata they are given, and earlier template metadata could send slightly misleading signals about what a client was actually going to receive. This patch brings the mime-type descriptions back into line with the real content shape. Nothing flashy happens in the browser, but downstream clients get fewer surprises and fewer awkward special cases.

• Task templates now identify themselves as markdown content, which matches what MCP clients actually receive when they open them.
• Milestone templates also advertise markdown content, keeping the metadata aligned with real payloads.
• Page templates stop claiming a misleading fixed mime type when the underlying page can legitimately resolve to different output formats.

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.