FEATURE SPEC¶
Questions or comments?
Post them as a comment on the tracking issue -- requires a GitHub account with access to this repo.
Collaborative Charter & Goal Planning¶
Novaworks AI | Super Agent orchestration (nova-superagent-agent) + x_novaw_platform
Parent Feature Set: ../concept.md.
Major Change History¶
| Version | Date | Author / Notes |
|---|---|---|
| 1 | 2026-08-10 | Eswar Vandanapu — Initial draft, derived from row 2 of the parent concept.md's Feature index. |
Problem Statement¶
Once a Task Force is assembled (Feature 1), it has nowhere to actually agree on what the initiative is trying to do. Today that means a shared doc or spreadsheet passed around by hand, with no real-time awareness of who's editing what — sections get overwritten, people work from stale copies, and there's no clear moment when the group can say "this plan is agreed" before real execution work starts.
Use Cases¶
Use Case 1: Two Task Force members — a Manager and an HR Operations practitioner — are both trying to shape the same section of an upskilling initiative's charter at the same time. Today they'd be doing this in a shared Google Doc with no platform-native awareness of each other's edits, which matters because one of them routinely finds their changes overwritten or has to manually reconcile two diverging copies.
Use Case 2: A Project Owner doesn't want to start from a blank page and asks Super Agent to generate a first-draft charter before the Task Force starts editing. Today there's no such starting point at all — every charter begins empty — which matters because a generated starting draft is exactly the kind of head start this Feature Set exists to provide.
Use Case 3: A Project Owner believes the Task Force has converged on a plan and wants to move into execution. Today there's no way to signal that a charter is "done" versus still being worked on, which matters because Feature 3 needs an unambiguous, agreed charter before it can responsibly generate real tasks from it.
Scope¶
- When a Task Force first opens a Project's charter (created in Feature 1), the Project Owner chooses a starting point: a blank charter, a saved template, or a Super-Agent-generated first draft. The generation itself is Feature 4's job — this Feature only presents whichever starting point was chosen into the collaborative editor.
- Multiple Task Force members can open and edit the same charter draft at the same time, seeing each other's cursors and edits in real time, without either party's changes being silently overwritten. This reuses the CRDT-based collaborative-authoring engine built for the Native Policy Editor in
specs-advisor— that engine is confirmed scoped to KB/policy content only today, and generalizing it to a project-charter document type is a stated dependency already logged on that spec's own Dependencies/Related Features section, not a hopeful reuse. - The Project Owner can finalize the charter — an explicit human action, never autonomous — which locks it as "agreed" and makes the Project eligible for Feature 3's task generation.
- This Feature does not generate charter content autonomously. The only AI-adjacent behavior is presenting an optional Feature-4-generated starting draft; every word past that point is human-edited, the same non-autonomous stance the reused Policy Editor engine takes toward its own content.
Out of Scope¶
- Generating a starting charter draft from Novaworks' knowledge or a template — see ../project-templates-knowledge-assisted-generation/spec.md (not yet drafted).
- Generating or distributing execution tasks from the finalized charter — see ../agent-assisted-task-generation-distribution/spec.md.
- On-demand agent review and suggested changes to the charter or plan — see ../agent-assisted-plan-review-refinement/spec.md (not yet drafted); that's a separate, agent-initiated-on-request capability, not part of this Feature's human collaborative-editing surface.
- Reconciling or replanning a charter once execution has already started — see ../project-reconciliation-replanning/spec.md (not yet drafted).
- Creating the Project or assembling the Task Force itself — see ../project-creation-task-force-assembly/spec.md.
Value¶
This is the one governed place a Task Force actually agrees on what an initiative is trying to do, closing the multi-week coordination lag the parent concept.md's business case names — and it's the gate every downstream Feature in this set depends on: nothing gets executed against a plan the Task Force never actually finalized.
Delivery¶
UX Description¶
A charter workspace opened from within a Project, on the same real-time multi-cursor collaborative-editing paradigm as the Native Policy Editor — primarily a desktop/ServiceNow-portal surface given the editing-heavy nature of the work.
Key User Flows¶
- Project Owner opens a newly created Project's charter for the first time → chooses to start blank, from a saved template, or by asking Super Agent to generate a first draft → lands in the collaborative editor with that starting content.
- Multiple Task Force members open the same charter → each sees the others' live cursors and edits → the group iterates together without overwriting each other's changes.
- Task Force converges on a plan → Project Owner clicks "Finalize Charter" → the charter locks as agreed, every Task Force member is notified, and the Project becomes eligible for Feature 3's task generation.
- A Task Force member tries to edit a charter that's already been finalized → the editor makes clear it's locked and who finalized it, rather than silently allowing further edits to an "agreed" plan.
Human Override & Fallback Strategy¶
- Only the Project Owner can finalize a charter — no autonomous locking, and no other role can perform this action today (see Open Questions on whether that should widen).
- If the real-time collaborative-edit relay is unavailable (it runs via the Nova Advisor Agent's WebSocket layer per the reused engine's own design, so its uptime is a dependency outside this Feature Set's control), the editor should degrade to single-editor access rather than blocking the charter entirely — the exact degraded behavior isn't defined by the reused engine's own spec either, so this Feature inherits that open item (see Open Questions).
- A Feature-4-generated starting draft is presented once and is then fully human-editable; there is no autonomous re-generation or silent content change after that point.
AI Feedback Loop¶
Not applicable — this Feature's own surface is human collaborative editing, not AI-generated output. Feedback on the quality of an optional generated starting draft (accept, edit heavily, regenerate) belongs to Feature 4, which owns the generation; this Feature only presents whatever draft Feature 4 produced.
Acceptance Criteria¶
- A Task Force member opening a Project's charter for the first time can choose to start from a blank charter, a saved template, or a Super-Agent-generated first draft.
- Two or more Task Force members can open and edit the same charter draft at the same time and see each other's cursors and edits in real time, without either party's changes being silently overwritten.
- Only the Project Owner can finalize a charter; finalizing locks it as "agreed" and makes the Project eligible for Feature 3's task generation.
- Every Task Force member is notified when the charter they've been collaborating on is finalized.
- A charter that hasn't been finalized cannot be used to generate execution tasks — Feature 3 blocks until an agreed charter exists.
Dependencies / Related Features¶
- project-creation-task-force-assembly (Feature 1): a Project and its Task Force must exist before this Feature applies.
- project-templates-knowledge-assisted-generation (Feature 4, not yet drafted): owns generating a starting draft; this Feature only presents it into the collaborative editor.
- agent-assisted-task-generation-distribution (Feature 3): consumes this Feature's finalized/agreed charter to generate execution tasks.
- agent-assisted-plan-review-refinement (Feature 5, not yet drafted): a separate, on-demand agent review layered on top of whatever charter state exists — not part of this Feature's human editing surface.
- project-reconciliation-replanning (Feature 6, not yet drafted): owns reopening/replanning a finalized charter once execution has started.
- specs-advisor: nova-policy-advisor / native-policy-editor-collaborative-authoring: this Feature's collaborative editing depends on that engine generalizing beyond KB/policy content to a project-charter document type — already logged as a dependency on that spec's own Dependencies/Related Features section.
Risks¶
| Risk | Severity | Mitigation |
|---|---|---|
| The reused CRDT relay runs via the Nova Advisor Agent's WebSocket layer, so this Feature's real-time collaboration availability is tied to that agent's uptime — a dependency outside this Feature Set's control | Medium | Confirm with specs-advisor whether a degraded, non-real-time editing fallback is possible rather than blocking charter access entirely during an outage. |
| Generalizing a KB-article-scoped editor to a new document type may surface data-model or versioning assumptions specific to KB articles that don't map cleanly to a Project charter | Medium | Resolve with specs-advisor at Construction time before this Feature depends on it, per the tracked dependency above. |
Open Questions¶
- Can Task Force members other than the Project Owner also finalize the charter, or is that authority Project-Owner-only?
- Once a charter is finalized, what's the mechanism to reopen it for edits — this Feature's job, or Feature 6's replanning capability?
- What does this editor do if the collaborative-edit relay is temporarily unavailable — degrade to single-editor access, or block entirely? Not defined by the reused engine's own spec either.
- Figma / Claude Design artifact for the charter workspace is not yet available.
For internal engineering review only.
Novaworks AI | Confidential