Skip to content

concept.md

Latest commit

 

History

History
1153 lines (841 loc) · 29.3 KB

concept.md

File metadata and controls

1153 lines (841 loc) · 29.3 KB
Raw

Plainweave: Local-first requirements and verification authority for Weft

PRECURSOR CONCEPT (2026-06-04, renamed from Charter). This document is the requirements-down product concept of the Charter precursor — "what must be true, how do we know." It is superseded by the Plainweave reframe, which inverts the member to code-up ("permission for code to exist"; every code entity must trace to a requirement) and repositions it around the accreted, code-grounded intent corpus. Read the current canon first: design/2026-06-18-plainweave-permission-to-exist.md and MODULE-MAP.md. Much of the model below (requirements, trace links, verification, baselines, the SQLite store, the MCP surface) carries forward as the foundation; its framing and center of gravity do not. Plainweave is gap-named and not in the launch cutover — see the design.

1. Product intent

Plainweave is a local-first, agent-native requirements and verification authority for the Weft federation.

Plainweave answers:

What must be true, how do we know it is true, what code or work claims to satisfy it, and what requirements are impacted by this change?

Plainweave is not an enterprise ALM clone. It is a lightweight, repo-local requirements system intended for developers and coding agents who need more structure than tasks and epics, but less ceremony than DOORS, Polarion, Jama, or Codebeamer.

Plainweave fits between product truth, code identity, work state, and governance:

Plainweave owns obligations.
Loomweave owns code identity and structure.
Filigree owns work state and issue lifecycle.
Wardline owns trust-boundary analysis.
Legis owns git/CI governance and attestations.

The authoritative federation roster and per-member authority split are owned by the Weft hub at ~/weft/doctrine.md. The split above mirrors it; if they ever disagree, the hub wins.

The primary design goal is to make requirements traceability cheap enough that agents can maintain it during ordinary development.

2. Authority boundary

2.1 Plainweave owns

Plainweave is authoritative for:

  • requirements;
  • requirement versions;
  • requirement decomposition;
  • acceptance criteria;
  • verification methods;
  • verification evidence records;
  • requirement baselines;
  • requirement-to-requirement links;
  • requirement-to-test links;
  • requirement-to-code-entity links;
  • requirement-to-issue links;
  • satisfaction status;
  • requirement impact analysis;
  • stale trace detection;
  • local requirements dossiers exposed over MCP.

2.2 Plainweave does not own

Plainweave does not own:

  • source-code identity, call graphs, or structural code relationships;
  • task assignment, claims, issue state, or sprint planning;
  • static security or trust-boundary analysis;
  • commit refusal, CI policy enforcement, or human sign-off;
  • external ALM authority when Plainweave is operating as an adapter.

Those remain owned by Loomweave, Filigree, Wardline, Legis, or an external ALM system.

3. Operating model

Plainweave follows the Weft federation model (the federation axiom and composition law are authoritative in ~/weft/doctrine.md; what follows is Plainweave's restatement of it):

Each tool owns one kind of truth.
Each tool remains useful alone.
When peers are present, facts compose.
No tool silently assumes another tool's authority.
Missing peers degrade honestly.

Plainweave can be installed by itself, but its highest value appears when paired with Loomweave and Legis.

3.1 Standalone mode

Plainweave can operate without other Weft tools.

In standalone mode it provides:

  • requirements database;
  • baselines;
  • verification records;
  • manual trace links;
  • CLI and MCP access;
  • markdown or JSON import/export;
  • impact reports limited to changed files and manually declared links.

3.2 Federated mode

When peers are installed, Plainweave gains richer capabilities:

Peer Combination capability
Loomweave Requirement links can bind to Stable Entity Identity rather than fragile file paths. Impact analysis can include touched entities, callers, callees, subsystems, and rename-resilient traces.
Filigree Requirements can be connected to work items, defects, implementation tasks, review tasks, and verification tasks.
Wardline Trust findings can be mapped to security or safety requirements. Requirement satisfaction can depend on absence, presence, or disposition of specific Wardline findings.
Legis Requirement and verification state can participate in commit preflight, policy decisions, override trails, sign-offs, and CI gates.

4. Core concepts

4.1 Requirement

A requirement is a versioned statement of something that must be true.

Example:

id: REQ-AUTH-017
title: Reject expired bearer tokens
type: security
criticality: high
status: approved
statement: >
  The API shall reject bearer tokens whose expiry time is earlier than the
  request evaluation time.
rationale: >
  Expired credentials must not grant access to protected resources.

A requirement may be high-level, decomposed, implementation-level, security-focused, safety-focused, interface-focused, operational, or non-functional.

4.2 Acceptance criterion

An acceptance criterion is a concrete condition that clarifies when a requirement is satisfied.

Example:

id: AC-AUTH-017-1
requirement: REQ-AUTH-017
statement: >
  A request with an expired token receives HTTP 401 and does not call the
  protected handler.

Acceptance criteria are optional for small projects but recommended for approved requirements.

4.3 Verification

A verification record describes how satisfaction is shown.

Verification methods:

  • test;
  • analysis;
  • inspection;
  • demonstration;
  • review;
  • external evidence;
  • manual attestation.

Example:

id: VER-AUTH-017-1
requirement: REQ-AUTH-017
method: test
evidence_ref: tests/test_auth.py::test_expired_token_rejected
status: passing
freshness: current
last_verified_commit: abc123

4.4 Trace link

A trace link connects a requirement to another requirement, acceptance criterion, verification record, code entity, issue, evidence item, or external reference.

Trace relations include:

  • decomposes;
  • refines;
  • constrains;
  • satisfies;
  • verifies;
  • implements;
  • tests;
  • depends_on;
  • supersedes;
  • conflicts_with;
  • mitigates;
  • derived_from;
  • documented_by.

Trace links carry authority metadata:

authority: human_accepted | agent_proposed | imported | inferred | test_derived
confidence: 0.0-1.0
freshness: current | stale | unknown

Agent-proposed links must be distinguishable from accepted links.

4.5 Baseline

A baseline is a named snapshot of approved requirements and their versions.

Baselines answer:

  • what requirements were in force at a point in time;
  • which requirements changed since the baseline;
  • which verification records are stale against the baseline;
  • whether a release can claim conformance to a baseline.

Example:

id: BASELINE-1.0
title: Release 1.0 approved requirements
created_at: 2026-06-04T10:00:00+10:00
includes:
  - REQ-AUTH-017@3
  - REQ-LOG-004@1
  - REQ-API-012@2

4.6 Dossier

A dossier is a single, agent-facing summary of what is known about a requirement.

A requirement dossier includes:

  • current statement;
  • status;
  • version;
  • parent and child requirements;
  • acceptance criteria;
  • verification methods and freshness;
  • linked code entities;
  • linked Filigree issues;
  • linked Wardline findings;
  • relevant Legis attestations;
  • open gaps;
  • suggested next actions.

5. Model architecture

5.1 System components

Plainweave consists of five main components:

plainweave-cli
  Human and script interface.

plainweave-store
  Local SQLite storage, migrations, baseline snapshots, event log.

plainweave-core
  Requirement model, trace model, verification model, impact engine.

plainweave-mcp
  Agent-facing MCP server exposing structured tools.

plainweave-federation
  Optional adapters for Loomweave, Filigree, Wardline, Legis, and external ALM.

5.2 Local storage

Each project gets a repo-local directory:

.plainweave/
  plainweave.db
  plainweave.yaml
  baselines/
  exports/
  context.md
  events.jsonl

The default store is SQLite.

Storage requirements:

  • no mandatory cloud service;
  • no mandatory account;
  • deterministic local operation;
  • schema migrations;
  • append-only event stream for audit and agent resumption;
  • export to JSONL and Markdown;
  • import from Markdown, CSV, JSON, and simple YAML;
  • safe degraded operation when peers are absent.

5.3 Data model

Core tables:

requirements
  id
  stable_id
  version
  title
  statement
  rationale
  type
  criticality
  status
  owner
  source
  created_at
  updated_at
  superseded_by

acceptance_criteria
  id
  requirement_id
  requirement_version
  statement
  status

verification_records
  id
  requirement_id
  requirement_version
  method
  evidence_ref
  evidence_type
  status
  freshness
  last_verified_at
  last_verified_commit
  verifier
  notes

trace_links
  id
  from_kind
  from_id
  to_kind
  to_id
  relation
  authority
  confidence
  freshness
  created_by
  created_at
  accepted_by
  accepted_at

baselines
  id
  title
  description
  created_at
  created_by

baseline_members
  baseline_id
  requirement_id
  requirement_version

events
  id
  timestamp
  actor
  event_type
  subject_kind
  subject_id
  before_json
  after_json

5.4 Identity model

Plainweave has two levels of identity:

  1. Plainweave-native requirement identity.
  2. Federated code identity supplied by Loomweave.

Requirement IDs are human-readable and durable:

REQ-AUTH-017
REQ-SEC-004
REQ-API-012

Requirement versions are immutable once approved.

Code-entity links should prefer Loomweave SEI when available:

to_kind: loomweave_entity
to_id: sei:01HX...
relation: satisfies

When Loomweave is unavailable, Plainweave may link to files, symbols, or line ranges, but these links must be marked as fragile.

5.5 Event model

Every mutation emits an event.

Examples:

requirement.created
requirement.updated
requirement.approved
requirement.superseded
criterion.added
verification.recorded
verification.marked_stale
trace.proposed
trace.accepted
trace.rejected
baseline.created
import.completed

Events enable:

  • agent session resumption;
  • change summaries;
  • audit trails;
  • generated context;
  • future synchronisation or federation.

6. Feature set

6.1 Requirements authoring

Plainweave must support creating, editing, approving, superseding, and deprecating requirements.

Required features:

  • create requirement;
  • edit draft requirement;
  • approve requirement;
  • supersede requirement;
  • deprecate requirement;
  • assign type and criticality;
  • add rationale;
  • add source reference;
  • add acceptance criteria;
  • view requirement history;
  • compare requirement versions.

CLI examples:

plainweave add "Reject expired bearer tokens" --type security --criticality high
plainweave approve REQ-AUTH-017
plainweave supersede REQ-AUTH-017 --statement-file req.md
plainweave show REQ-AUTH-017
plainweave history REQ-AUTH-017

6.2 Traceability

Plainweave must support explicit trace links between requirements, code, tests, issues, evidence, and external references.

Required features:

  • link requirement to requirement;
  • link requirement to acceptance criterion;
  • link requirement to test;
  • link requirement to Loomweave entity;
  • link requirement to Filigree issue;
  • link requirement to Wardline finding;
  • link requirement to external URL or imported ALM object;
  • propose trace links from agent analysis;
  • accept or reject proposed trace links;
  • mark links stale;
  • show forward and backward trace.

CLI examples:

plainweave link REQ-AUTH-017 --test tests/test_auth.py::test_expired_token_rejected
plainweave link REQ-AUTH-017 --entity auth.validate_token
plainweave trace REQ-AUTH-017
plainweave accept-link LINK-42

6.3 Verification

Plainweave must distinguish requirement existence from requirement satisfaction.

Required features:

  • define verification method;
  • attach verification evidence;
  • record passing, failing, missing, stale, waived, or unknown verification state;
  • bind verification to commit;
  • mark verification stale when linked code or requirement changes;
  • list unverified approved requirements;
  • list stale verification records;
  • support verification by test, analysis, inspection, demonstration, review, or external evidence.

CLI examples:

plainweave verify REQ-AUTH-017 --method test --evidence tests/test_auth.py::test_expired_token_rejected
plainweave verification stale
plainweave verification missing
plainweave verify-run --from-junit test-results.xml

6.4 Baselines

Plainweave must support requirement baselines.

Required features:

  • create named baseline;
  • include approved requirements in baseline;
  • compare current requirements to baseline;
  • show changed requirements since baseline;
  • show verification state against baseline;
  • export baseline;
  • lock baseline against mutation.

CLI examples:

plainweave baseline create release-1.0
plainweave baseline diff release-1.0
plainweave baseline verify release-1.0

6.5 Impact analysis

Plainweave must provide impact analysis for requirements and diffs.

Required features:

  • identify requirements touched by pending git diff;
  • identify requirements touched by commit range;
  • identify requirements linked to changed entities;
  • identify requirements near changed entities through Loomweave neighbourhoods;
  • identify stale verification caused by code changes;
  • identify requirements changed without linked work;
  • identify code touched without requirements when policy expects traceability;
  • produce agent-readable impact report.

CLI examples:

plainweave impact
plainweave impact --since main
plainweave impact --requirement REQ-AUTH-017

Example output:

Requirement impact for pending diff

In this change:
  REQ-AUTH-017
    touched entity: auth.validate_token
    verification: stale
    evidence: tests/test_auth.py::test_expired_token_rejected not run on current commit

Around this change:
  REQ-AUTH-014
    caller chain depends on modified entity
    verification: current

Gaps:
  REQ-AUTH-017 has no accepted trace to implementation after rename.

6.6 Agent context

Plainweave must generate compact context for agents.

Required features:

  • project requirement summary;
  • open verification gaps;
  • requirements touched by active work;
  • changed requirements since last session;
  • unresolved proposed links;
  • stale verification records;
  • baseline status.

Generated file:

.plainweave/context.md

This file is regenerated after mutations and may be injected into agent sessions by install hooks.

6.7 MCP tools

Plainweave must expose MCP tools for consult-mode and action-mode agents.

Initial MCP tool set:

requirement_get(id)
requirement_search(query, status?, type?, criticality?)
requirement_create(...)
requirement_update(...)
requirement_approve(id)
requirement_supersede(id, ...)
requirement_deprecate(id)

trace_link_create(...)
trace_link_propose(...)
trace_link_accept(id)
trace_link_reject(id)
trace_for(id)
trace_gaps(scope?)

verification_record(...)
verification_status(requirement_id)
verification_missing(scope?)
verification_stale(scope?)
verification_import_junit(path)

baseline_create(name)
baseline_diff(name)
baseline_status(name)

impact_pending_diff()
impact_commit_range(base, head)
dossier_requirement(id)
session_context()

Action tools that mutate state must accept an actor parameter or infer actor from the MCP session.

6.8 Imports and exports

Plainweave must not trap users.

Required import formats:

  • Markdown;
  • YAML;
  • JSON;
  • CSV;
  • simple table import.

Desirable import adapters:

  • DOORS Next via OSLC or exported CSV;
  • Polarion export;
  • Jama export;
  • Jira/Confluence pages;
  • GitHub Issues labels;
  • existing project markdown.

Required export formats:

  • Markdown;
  • JSONL;
  • CSV;
  • SARIF-adjacent evidence summary where useful;
  • static HTML report.

6.9 External ALM adapter mode

Plainweave may operate in adapter mode where an external system remains the requirements authority.

In adapter mode:

  • external requirement IDs remain canonical;
  • Plainweave caches requirement metadata;
  • Plainweave stores local trace links and verification facts unless the external system supports writing them;
  • Plainweave marks imported facts with source and freshness;
  • Plainweave never pretends imported stale data is current;
  • Plainweave can produce local impact reports over imported requirements.

Supported external systems are post-v1.0 scope.

7. Federation requirements

7.1 Loomweave integration

When Loomweave is present, Plainweave must:

  • resolve entity names to SEI;
  • link requirements to SEI;
  • request affected entities for pending diff;
  • request neighbourhoods around touched entities;
  • survive rename and move events through Loomweave identity;
  • degrade honestly if SEI capability is absent.

Plainweave must not mint or reinterpret SEI.

7.2 Filigree integration

When Filigree is present, Plainweave must:

  • link requirements to issues;
  • show open work for a requirement;
  • create implementation or verification tasks from requirement gaps;
  • attach requirement impact to issue context;
  • expose requirement gaps as candidate work;
  • avoid taking ownership of issue lifecycle.

Example:

plainweave gap create-work REQ-AUTH-017 --type verification

7.3 Wardline integration

When Wardline is present, Plainweave must:

  • link Wardline findings to security or trust requirements;
  • show Wardline findings in requirement dossiers;
  • mark a requirement unsatisfied if an active finding violates a linked acceptance criterion;
  • allow Wardline findings to generate proposed requirement links;
  • avoid duplicating Wardline analysis authority.

Example:

REQ-SEC-004 requires external request bodies to be validated before persistence.
Wardline finding PY-WL-101 violates REQ-SEC-004.

7.4 Legis integration

When Legis is present, Plainweave must:

  • contribute requirement impact to commit preflight;
  • provide verification freshness facts;
  • provide baseline conformance facts;
  • provide traceability gaps;
  • allow Legis to enforce policies using Plainweave facts;
  • receive governance attestations or sign-off references from Legis;
  • avoid deciding whether a commit may proceed.

Example Chill-mode contribution:

Requirements:
  WARN  REQ-AUTH-017 touched; verification stale.
  INFO  REQ-AUTH-014 nearby through caller chain; verification current.

Example Structured-mode contribution:

BLOCK  Safety-critical requirement REQ-SAFE-003 touched without fresh verification.

8. Policy model

Plainweave itself should not be a general policy engine. It should expose facts that Legis can govern.

However, Plainweave should support local advisory rules:

rules:
  require_verification_for_approved: true
  require_acceptance_criteria_for_high_criticality: true
  mark_verification_stale_on_requirement_change: true
  mark_verification_stale_on_linked_entity_change: true
  require_human_acceptance_for_agent_links: true

Rules produce Plainweave findings, not commit decisions.

Commit decisions belong to Legis.

9. User workflows

9.1 Lightweight solo workflow

plainweave init
plainweave add "Users can reset their password" --type functional
plainweave approve REQ-USER-001
plainweave link REQ-USER-001 --entity users.reset_password
plainweave verify REQ-USER-001 --method test --evidence tests/test_password_reset.py
plainweave impact

9.2 Agent-driven implementation workflow

  1. Agent starts session.
  2. Filigree provides active issue context.
  3. Plainweave provides linked requirements.
  4. Loomweave identifies affected entities.
  5. Agent modifies code.
  6. Wardline scans trust boundaries.
  7. Plainweave marks verification stale or records new evidence.
  8. Legis preflight reports commit-boundary obligations.

9.3 Requirement change workflow

  1. Requirement is updated in draft.
  2. Agent requests impact analysis.
  3. Plainweave lists affected child requirements, entities, tests, issues, and verification records.
  4. Filigree tasks are created for required updates.
  5. Baseline diff shows what changed.
  6. Legis may require sign-off if protected requirements are affected.

9.4 DOORS-lite import workflow

  1. User imports CSV or exported requirements.
  2. Plainweave creates imported requirements.
  3. Agent proposes links to Loomweave entities and tests.
  4. Human accepts high-confidence links.
  5. Plainweave creates baseline.
  6. Future diffs can report requirement impact.

10. CLI surface

Minimum CLI:

plainweave init
plainweave install
plainweave doctor

plainweave add
plainweave edit
plainweave approve
plainweave supersede
plainweave deprecate
plainweave show
plainweave search
plainweave history

plainweave criterion add
plainweave criterion list

plainweave link
plainweave unlink
plainweave trace
plainweave gaps
plainweave accept-link
plainweave reject-link

plainweave verify
plainweave verification status
plainweave verification missing
plainweave verification stale
plainweave verify-run

plainweave baseline create
plainweave baseline list
plainweave baseline diff
plainweave baseline verify
plainweave baseline export

plainweave impact
plainweave dossier
plainweave context
plainweave export
plainweave import
plainweave mcp

11. Configuration

Project config lives at:

plainweave.yaml

Example:

project:
  key: AUTH
  requirement_prefix: REQ

storage:
  path: .plainweave/plainweave.db

federation:
  loomweave: auto
  filigree: auto
  wardline: auto
  legis: auto

verification:
  stale_on_requirement_change: true
  stale_on_linked_entity_change: true
  require_current_for_criticality:
    - high
    - safety
    - security

traceability:
  allow_agent_proposed_links: true
  require_human_acceptance_for:
    - safety
    - security
    - high

baselines:
  require_approved_only: true

12. Requirements

Functional requirements

FR-1: Requirement management

Plainweave shall allow users and agents to create, update, approve, supersede, deprecate, search, and view requirements.

FR-2: Requirement versioning

Plainweave shall preserve immutable approved requirement versions.

FR-3: Acceptance criteria

Plainweave shall support one or more acceptance criteria per requirement.

FR-4: Verification records

Plainweave shall support verification records linked to requirements and requirement versions.

FR-5: Verification freshness

Plainweave shall mark verification records stale when linked requirements or linked implementation entities change.

FR-6: Trace links

Plainweave shall support typed trace links between requirements, acceptance criteria, verification records, tests, code entities, issues, findings, external references, and baselines.

FR-7: Agent-proposed trace links

Plainweave shall allow agents to propose trace links without treating them as accepted truth.

FR-8: Trace acceptance

Plainweave shall allow proposed trace links to be accepted or rejected.

FR-9: Baselines

Plainweave shall support named baselines of approved requirement versions.

FR-10: Baseline comparison

Plainweave shall compare the current requirement set to a baseline.

FR-11: Impact analysis

Plainweave shall report requirements affected by a pending diff or commit range.

FR-12: Requirement dossier

Plainweave shall provide a single structured dossier for a requirement.

FR-13: Session context

Plainweave shall generate an agent-readable project context summary.

FR-14: CLI

Plainweave shall provide a CLI for all core operations.

FR-15: MCP server

Plainweave shall expose core operations through an MCP-over-stdio server.

FR-16: Import

Plainweave shall import requirements from at least Markdown, CSV, YAML, and JSON.

FR-17: Export

Plainweave shall export requirements, traces, baselines, and verification records to Markdown, CSV, JSONL, and static report formats.

FR-18: Loomweave federation

When Loomweave is present, Plainweave shall link requirements to Loomweave SEI rather than only files or line ranges.

FR-19: Filigree federation

When Filigree is present, Plainweave shall link requirements to issues and create work items from gaps.

FR-20: Wardline federation

When Wardline is present, Plainweave shall link trust findings to requirements and expose those findings in requirement dossiers.

FR-21: Legis federation

When Legis is present, Plainweave shall provide requirement impact, verification freshness, baseline status, and traceability gap facts to Legis preflight and enforcement surfaces.

Non-functional requirements

NFR-1: Local-first

Plainweave shall operate without a cloud service or account.

NFR-2: Deterministic core

Plainweave’s core model and impact calculations shall be deterministic.

NFR-3: Agent-safe output

All CLI commands used by agents shall support structured JSON output.

NFR-4: Human-readable output

Plainweave shall also provide concise human-readable CLI output.

NFR-5: Low dependency weight

The base install shall have minimal dependencies.

NFR-6: No hidden authority

Plainweave shall not silently make governance decisions, infer code identity, or mutate peer-owned state without explicit integration contracts.

NFR-7: Freshness honesty

Imported, inferred, stale, or agent-proposed facts shall be labelled as such.

NFR-8: Auditability

All mutations shall produce event records.

NFR-9: Graceful degradation

Plainweave shall remain useful when Loomweave, Filigree, Wardline, or Legis are absent.

NFR-10: Repository portability

A project’s Plainweave state shall live in a repo-local .plainweave/ directory.

NFR-11: Performance

Plainweave shall support thousands of requirements and trace links on ordinary developer hardware.

NFR-12: Safety against false certainty

Plainweave shall distinguish accepted traceability from proposed or inferred traceability.

13. MVP scope

MVP must include

  • local SQLite store;
  • plainweave init;
  • create/edit/approve/deprecate requirements;
  • requirement versions;
  • acceptance criteria;
  • manual trace links;
  • verification records;
  • stale verification detection for requirement changes;
  • baselines;
  • plainweave impact over manually linked files/tests;
  • JSON output for agent use;
  • MCP server with read/query/dossier tools;
  • import/export to Markdown and JSON;
  • generated .plainweave/context.md.

MVP should include

  • Loomweave entity links if Loomweave is installed;
  • Filigree issue links if Filigree is installed;
  • agent-proposed trace links;
  • baseline diff;
  • pending-diff impact report.

MVP may defer

  • external DOORS/Polarion/Jama import adapters;
  • full OSLC support;
  • rich web UI;
  • multi-user sync;
  • cryptographic attestations;
  • deep test runner integration;
  • automatic semantic requirement extraction;
  • complex policy grammar.

14. v1.0 scope

v1.0 should include:

  • robust requirement lifecycle;
  • accepted/proposed/rejected trace links;
  • requirement dossiers over MCP;
  • Loomweave federation using SEI;
  • Filigree federation for requirement-linked work;
  • Legis preflight contribution;
  • Wardline finding links;
  • baseline creation and comparison;
  • verification freshness against requirement and linked entity changes;
  • import/export;
  • session context generation;
  • documented integration contracts.

15. Post-v1.0 scope

Post-v1.0 candidates:

  • DOORS Next OSLC adapter;
  • Polarion adapter;
  • Jama adapter;
  • Codebeamer adapter;
  • GitHub Issues import/export;
  • Confluence/Jira import;
  • generated trace-matrix reports;
  • static HTML dashboard;
  • Graph visualisation;
  • richer requirement quality checks;
  • LLM-assisted requirement decomposition;
  • LLM-assisted test suggestion;
  • requirement coverage heatmaps;
  • safety case or assurance case support.

16. Product positioning

Plainweave is for users who have outgrown tasks and epics, but do not want enterprise ALM ceremony.

Use Plainweave when:

  • requirements need to be explicit;
  • verification matters;
  • agents need structured obligations;
  • change impact should include requirements;
  • traceability should survive refactors;
  • a lightweight local-first workflow is enough.

Do not use Plainweave when:

  • the organisation requires a certified enterprise ALM system;
  • requirements must be centrally managed across many teams;
  • role-based access control is mandatory;
  • external auditors require an approved system of record;
  • requirements contain sensitive information that cannot live in local repo storage.

17. One-sentence description

Plainweave is a local-first requirements and verification authority for agentic development: it records what must be true, links it to code and work, tracks how it is verified, and tells agents what obligations a change touches.