Milestones
List view
Open and unassigned, available for future work. Browser-native GraphForge/WASM proposal #495 was closed as not planned by maintainer decision on 2026-09-09. No WASM implementation commitment remains. Keep this unused milestone open for reassignment.
No due dateOpen and unassigned, available for future work. Browser-native GraphForge/WASM proposal #495 was closed as not planned by maintainer decision on 2026-09-09. No WASM implementation commitment remains. Keep this unused milestone open for reassignment.
No due date•0/1 issues closedShip and prove a transport-neutral peer-extension platform over the published gf-api without moving extension behavior into GraphForge Core. In scope: - extension contract, Core delete/boundary CI, and third-party author documentation; - gf-datasets loader/registry infrastructure, reference content, and separate Python/Node packages; - a local-first genealogy reference extension; - an optional queued-authority MCP/HTTP extension as a peer package. Out of scope: - v0.5.0 publication; - MCP, HTTP, authentication, authorization, or server lifecycle in Core; - distributed or multiple storage authorities; - an extension marketplace or UI. Close when milestone tracker #222 and every milestone issue are closed, Core remains buildable with extensions removed, extensions depend only on public APIs, applicable package and clean-install acceptance passes, and the documentation proves the third-party extension path. Excluded from v0.6.0 by explicit maintainer instruction. Scheduled after M12 publication as M14. Retain #222 and all existing acceptance criteria; no release-blocking dependency is added.
No due date•1/19 issues closedValidate user value and guide responsible promotion after M12/#1095 verifies final v0.6.0 publication. Canonical close gate: #1210. Native work: #1211 independent external-user pilots and critical-friction resolution; #1212 approved targeted promotion and measured adoption decision. Use M12's verified positioning, claims, documentation and clean first-use evidence. Observe at least three independent external technical users across two relevant tasks; document successes, failures, interventions and continued-use intent. Fix verified critical blockers before broader promotion. Use a finite, explicitly approved channel plan and observation window; report actual outcomes and support burden without treating downloads/stars as adoption proof. A documented pause/narrow decision is valid where evidence does not support expansion. Close after both child outcomes, critical-finding dispositions and a sanitized expand/narrow/pause readout are complete. Actual outreach requires explicit authorization; participant attribution/testimonials require consent. No mandatory telemetry, new hosted analytics, paid advertising commitment, fabricated users, broad production-maturity promise or pre-v1 backward-compatibility requirement. This milestone follows publication and never blocks M12. M14 peer extensions remain separate and M15 remains available. Planning may happen early, but pilot/public-promotion execution waits for verified public artifacts. Preserve normal issue/PR gates and the three-change WIP limit. ## Analyst experience and product-group coordination — 2026-09-17 The maintainer added a bounded post-release seed collection of existing datasets and evidence-linked information extraction, owned by CurateLabs/graphforge-nextjs#33 and consumed by #1210. Its delivery depends on verified Core publication and Hub readiness, not all peer extensions. Coordinate content and application work through [GraphForge Product Map](https://github.com/orgs/CurateLabs/projects/2); implementation stays in owning repositories. #1211 observes nontechnical analysts assisted by agents alongside technical users. Dataset licensing, source/Artifact/claim lineage, extraction review, useful questions, reproducible examples and fresh discovery/open evidence are required; seed content is not adoption proof. Planning may proceed early; extraction execution and public delivery follow release.
No due date•0/3 issues closed## Purpose Ship GraphForge v0.6.0 as one coordinated Rust, Python, npm, CLI, agent-skills, documentation, and GitHub Release surface without consuming the final version during release rehearsal or recovery. ## Canonical version contract - The canonical cross-ecosystem prerelease identifier is SemVer `0.6.0-rc.N`, beginning with `0.6.0-rc.1`. - Git tags and GitHub prereleases use the corresponding `v0.6.0-rc.N` form. - Cargo/crates.io, npm packages, CLI, skills, manifests, provenance, checksums, filenames, and release evidence use `0.6.0-rc.N` without the Git-only `v` prefix. - PyPI uses the required PEP 440 normalized projection `0.6.0rcN`; release evidence must prove it maps to the same canonical `0.6.0-rc.N` identity. - Noncanonical cross-ecosystem spellings such as `0.6.0rc1`, `0.6.0-rc1`, or `0.6.0-RC.1` must be rejected outside explicitly defined ecosystem normalization boundaries. - Release automation and CI must parse and validate the structured version; substring replacement or loosely matched version text is not sufficient. ## Release-candidate policy - The first public candidate is `v0.6.0-rc.1`. - Release-process or artifact defects produce `rc.2`, `rc.3`, and so on. They do **not** consume `v0.6.0` or force an artificial `v0.6.1` corrective release. - Every candidate is immutable. Never move a tag, replace published bytes, or reuse an RC version. - All ecosystem versions advance together under the unified-release contract; no registry-specific version drift. - The final `v0.6.0` identity is created only after one candidate passes the complete coordinated publication, clean-install, reopen, registry-observation, checksum, provenance, and documentation gates. ## In scope - v0.6.0 release scope and compatibility freeze - canonical SemVer prerelease validation and ecosystem-specific projections - release-candidate version alignment across Cargo/crates.io, PyPI, npm native/main/CLI/skills, and GitHub - exact-SHA Binding RC, offline rehearsal, publication recovery, and retained evidence - prerelease publication and clean-environment verification - final v0.6.0 promotion, release notes, docs, and post-publication verification ## Out of scope - unrelated post-v0.6 features - silently repairing or overwriting an immutable RC - publishing only one ecosystem ahead of the coordinated surface - treating a registry-normalized spelling as a second release identity ## Close criteria 1. All milestone issues are closed or explicitly moved with documented rationale. 2. CI rejects noncanonical prerelease forms and proves every registry projection resolves to one canonical `0.6.0-rc.N` identity. 3. At least one immutable `v0.6.0-rc.N` candidate has been published and verified across every supported registry and clean consumer surface. 4. The selected candidate has complete exact-SHA evidence, provenance, checksums, recovery disposition, and release notes. 5. Coordinated final `v0.6.0` artifacts are published and publicly observed across crates.io, PyPI, npm packages, GitHub Release, and docs. 6. Final clean-environment install, native load, CLI/skills execution, project reopen, and checksum/provenance verification pass. 7. The milestone is closed only after public release verification—not merely after tagging or the first registry upload. ## Approved release scope and order M3 architecture maintenance, M5 billion-edge scale/hardened interchange, M10 benchmarks, and M11 Core Analyst UX (#1347) must meet their acceptance outcomes before final candidate readiness and publication within this milestone. The maintainer explicitly included all those programs and excluded peer extensions and WASM. Full M5 acceptance is required; the previous RC-before-M5 disposition is withdrawn. #1095 is the canonical RC/final-publication tracker. Its native readiness blocker proves the integrated candidate and all included prerequisites. M14 peer extensions follow the release and do not block it. Browser WASM #495 is not planned; M15 is available for assignment. Ordinary implementation PR gates remain distinct from exact-SHA publication evidence. One release milestone owns version/channel implementation (#858), candidate readiness (#1096), and coordinated RC/final publication (#1095). Readiness is an internal prerequisite, not a separate milestone. #1095 is the final milestone close gate. #1095 is natively blocked by #1096, whose native dependencies cover all included work. Community readiness additionally requires #1208 (positioning, claims and limitations) and #1209 (clean first-use journey) through #1096. #1095 verifies final public links/examples. M13/#1210 owns post-release pilots and evidence-led promotion; it does not block M12. Backward compatibility and migration machinery are out of scope before v1.0.0; public material must state that clearly. Scope change (2026-09-16): local workspace job observability was removed from v0.6.0 and its milestone dissolved. #886 and #922 shipped and remain closed as completed; #887, #888, #889 and their tranches are closed as not planned. Analyst UX was inserted before the release; subsequent milestones were advanced by one to preserve sequencing. Observability is no longer a readiness prerequisite for this milestone. ## Analyst experience and product-group coordination — 2026-09-17 Coordinate Core, XYG, graphforge-vscode and graphforge-nextjs through [GraphForge Product Map](https://github.com/orgs/CurateLabs/projects/2), keeping implementation issues and release gates in their owning repositories. #1208 owns the comprehensive RC user-guide refactor; #1209 owns urgent first-use ergonomics and qualified editor/agent/notebook paths. Candidate artifacts enable preparatory integration; public install verification follows publication, without circular publication prerequisites. The core audience remains nontechnical analysts with agents even when the initial v0.6.0 path is more technical.
No due date•14/22 issues closed## Purpose Deliver the core GraphForge analyst experience for exploring evidence-rich projects, focusing a corpus into research context, developing independent research, comparing it with parent knowledge, and selectively proposing supported discoveries back upstream. ## In scope - Analyst-facing Project, Source, Artifact, Slice, Branch, Version, Fork, Assertion, Canonical, Lineage, and Proposal concepts. - The primary journey: Explore → Focus → Branch → Analyze → Compare → Propose → Integrate. - Project entry points and discovery by text, source, entity, relationship, document/story, event, location, ontology/type, linguistic property, traversal, structured query, and existing branch. - Explicit Slice boundaries, inclusion rationale, and expansion/contraction before branching. - Persistent Branch workspaces with inherited/local/upstream/accepted state, immutable versions, and visible origin. - Evidence, extraction, assertion, interpretation, and hypothesis distinctions; provenance-preserving competing and canonical assertions. - Bidirectional lineage from evidence through processing and derived knowledge, including source-replacement impact. - Graph-semantic comparison; selective, evidence-contextual proposals and acceptance that retain authorship and research lineage. - Project metadata, ontology context and local branch extensions needed for discovery and analytical context. ## Out of scope - Exposing software-development ceremony (commits, staging, HEAD, rebasing, or pull requests) in the analyst UX. - Destructive source replacement, silently flattening competing interpretations, or disconnected copies of the underlying project data. - Hosted/server-only architecture, distributed execution, or a foreign-runtime behavior engine. ## Close criteria Close only when assigned work has deterministic evidence that an analyst can complete the primary journey on the Rust-owned GraphForge surface and its thin bindings: navigate from project evidence to a bounded Slice; branch without losing origin; create and inspect immutable versions; distinguish evidence, extraction, assertions, interpretations, and canonical status; traverse provenance and dependency lineage; compare semantic changes; and selectively propose and accept changes without erasing authorship or provenance. The experience must use the analyst vocabulary defined here and preserve the Project/Branch/Fork distinction. This milestone is a v0.6.0 prerequisite. M12 owns release readiness and publication after M3, M5, M10, and M11 meet their respective acceptance outcomes. ## Canonical implementation gate #1347 is the canonical close gate; #1346 integrates the two maintainer specifications and their acceptance map. All native implementation children of #1347 must satisfy their outcomes. #1347 natively blocks release readiness #1096. M11 includes explicit upstream updates/conflict review, Forks, research-aware interchange, and retained Version dependencies as specified in the integrated docs. Core owns Rust/Python/Node/CLI behavior and the consumer UX contract. Associated projects such as XYG and graphforge-nextjs, applications, and peer extensions own their UI, rendering, hosting, authentication, and access enforcement; they are not Core dependencies or Core close-gate implementations. Confirmed semantics: explicit suppression changes the active Branch graph; canonical/epistemic filters stay explicit. Retained Versions pin graph, ontology, and local Artifact dependencies; external-only evidence limitations and history deletion are explicit. ## Analyst experience and product-group coordination — 2026-09-17 The complete research vocabulary is not a prerequisite for first use. #1399 records the core audience of nontechnical analysts assisted by agents alongside a technical entry path, expected VS Code/agent/Jupyter journeys, and stage-specific comprehension questions. #1358 proves Core answers; associated repositories own presentation and #1209/#1211 own first-use/pilot observations. Cross-repository coordination: [GraphForge Product Map](https://github.com/orgs/CurateLabs/projects/2).
No due date•3/14 issues closedComplete canonical #952 and its existing native benchmark infrastructure, GDC suites, and semantic-parity outcomes before v0.6.0 release preparation. Use OVHC-AGENCY under local-linux-cgroups-v2. Consume the same #900/#745 Graph500 ladder used by M5; do not repeat expensive host runs solely for another tracker. All existing #952 acceptance criteria remain in force. Closed component issues alone do not prove the program is complete. M5 and this milestone both precede M12 readiness and M12 publication.
No due date•17/18 issues closedProve GraphForge can persist and operate on at least 1,000,000,000 live edges end to end while preserving embedded Rust ownership, and harden three public interchange surfaces: resumable data ingest, portable project packaging/promotion, and streaming result export. In scope: first-fail scale ladder; bounded UUID membership checks; resumable staged Arrow/Parquet ingest; sharded/streamed CSR; portable project v2 with one semantic identity across inspectable expanded and deterministic bundled forms; bounded integrity/compatibility verification; atomic import; ontology/component/settings/artifact and deterministic graph/data-subset export; optional digest-pinned OCI publication/pull with explicit integrity/authenticity separation; streaming query-result export; Python, Node, and CLI parity; final generate/import → publish → reopen/recount → adjacency → 1/2-hop query → bundle → verify → clean import → reopen/query/fingerprint certification. The final scale proof must separately disclose official Graph500 SCALE26/edgefactor-16 input attempts and post-policy live persisted counts. The product gate is >=1,000,000,000 live persisted edges. Target host envelope: <=128 GiB peak RSS, <=1 TiB local NVMe, <=24 hours, with first-fail evidence at lower rungs. Expanded/bundled equivalence, selective packaging, and OCI promotion require deterministic representative-scale conformance; they do not require duplicating the billion-edge payload or uploading it to a hosted registry. Out of scope: distributed execution, server-only architecture, GPU requirements, foreign runtime engines, domain-specific dataset loaders, universal maximum-size claims, a GraphForge registry/server, mandatory cloud publication, graph merge semantics, and committing project data/exports to Git. Close only when the canonical tracker and every milestone issue are closed with deterministic evidence on the final integrated tree. Included in v0.6.0: complete canonical #735 and every assigned acceptance outcome, including #745 S26 certification on OVHC-AGENCY, before M12 readiness and M12 publication. No prerelease exception waives this scope. Plan of record and closing issue for the ingest-throughput workstream (#1387 / #1456): #1478 (rev 12, 2026-09-19). It belongs to this milestone but does not close it; the canonical tracker remains #735.
No due date•117/134 issues closed