1,000 Stars roadmap — useful, trusted, sustainable
Status: active from 2026-08-10
Last planning audit: 2026-08-17
Baseline: 837 GitHub Stars
Latest weekly snapshot: 839 GitHub Stars at
2026-08-16T20:52:07Z; 161 remainTarget: 1,000 Stars by 2027-06-30
Stretch target: 1,000 Stars by 2027-03-31
Product outcome: a third party reaches a verified Autoware-compatible map from a rosbag without reading the implementation or receiving private setup help.
This roadmap turns the existing product and research work into a sustainable adoption loop. It complements the v0.9 product roadmap, the v1.0 readiness gate, and the evidence-driven SOTA research plans. It does not weaken any accuracy, license, compatibility, or release gate.
The companion 2026–2029 operating plan extends this milestone roadmap through compatibility policy, ownership transfer, succession practice, and a deliberate 2030 continue/narrow/transfer/archive decision. This document remains the source for the 1,000-Star definition and G0–G5 milestone gates.
The 1,000-Star count is a discovery milestone, not the product's purpose. The project succeeds only when people can install it, obtain a useful map, verify the result, recover from failure, and contribute improvements.
1. Definition of success
The growth goal is complete only after all of the following are true:
- GitHub reports at least 1,000 current Stars in two weekly snapshots;
- the v1.0 readiness audit reports
10 / 10complete; - at least three independent users have accepted first-map validations;
- a current stable release is less than 90 days old;
- at least three non-maintainer contributors have had a contribution merged in the preceding 180 days;
- no supported-product P0 issue has waited more than seven days for a public disposition;
- every public performance or compatibility claim links to reproducible evidence and states its limits.
Crossing 1,000 before these quality conditions is a Star milestone, but not completion of this roadmap.
Guardrails
- Do not buy, exchange, automate, or otherwise manufacture Stars.
- Do not mass-message users, forks, issue authors, or unrelated communities.
- Do not make a SOTA, hardware-support, or Autoware-endorsement claim without the corresponding evidence.
- Do not add anonymous product telemetry. Use aggregate GitHub metrics and voluntary, privacy-bounded validation receipts.
- Do not let research artifacts, generated logs, or benchmark datasets enter the supported runtime package or release bundle.
- Do not ship features solely for attention. Every roadmap item must improve activation, trust, distribution, or maintainability.
2. Baseline on 2026-08-10
GitHub REST traffic data covers the preceding 14-day window. Stargazer dates describe Stars that still exist today, so they are useful for trend estimates but are not an exact historical net-growth ledger.
| Signal | Baseline | Meaning |
|---|---|---|
| Current Stars | 837 | 163 remain |
| Current stargazers added in last 30 days | 11 | recent organic pace |
| Current stargazers added in last 90 days | 35 | about 11.8 per 30.4 days |
| Forks / subscribers | 172 / 12 | strong latent usage, weak ongoing project followership |
| Repository views | 870 total / 299 unique | 14-day discovery baseline |
| Repository clones | 2,042 total / 259 unique | totals include likely automation; use uniques cautiously |
| Main v0.9.0 bundle downloads | 8 | GitHub asset count; GHCR pulls are not included |
| Open issues | 29 | 28 were opened before 2026 and need deliberate triage |
Open good first issue tasks |
1 | the contributor queue is not yet self-sustaining |
| Pull requests | 333 total / 324 merged | high maintainer throughput |
| Historical external PRs | 13 submitted / 10 merged | contribution path exists but is quiet |
| External PRs in the last 90 days | 1 | contributor growth is a primary constraint |
| API-visible contributors | 1 | the project still appears maintainer-dependent |
| Independent first-map validations | 0 / 3 | current v1.0 adoption blocker |
| v1.0 readiness | 8 / 10 | distribution and external adoption remain open |
| Repository size | 172,506 KiB | discovery and clone cost need an artifact/history audit |
| GitHub Discussions | disabled | usage questions remain mixed into the issue backlog |
The strongest 14-day referrers were Google (104 unique visitors) and GitHub
(74). tier4.github.io and autowarefoundation.github.io contributed only
six unique visitors combined. Search already finds the project; the larger
opportunity is to make the landing page easier to understand and to earn more
qualified Autoware referrals.
The original research worktree remains an operational risk: it is 229 commits
ahead of origin/develop and still mixes dirty product, research, and generated
work. Separation has nevertheless advanced. At audited revision 9b3db89, the
clean G0 product line contained 31 linear commits on exact public
origin/develop revision 86fa9b6, changed 92 paths, and had no merge commit or
dirty file. The 2026-08-11 planning refresh at 33be15b contains 33 linear
commits and changes 99 paths from the same base, including the complete
fail-closed issue-triage proposal. That line is still local-only. Reviewable
separation is therefore implemented, but source visibility, pull-request
review, fixture hosting, and publication authorization remain open gates rather
than assumed outcomes.
At the current 90-day pace, another 163 Stars would take roughly 14 months, placing the unassisted projection around October–November 2027. The base target requires about 15.2 net new Stars per month, approximately 1.3 times the recent pace. The March stretch target requires about 21 per month.
3. Positioning: win a narrower and more useful job
The project should not present itself as a generic replacement for every LiDAR SLAM framework. FAST-LIO owns a widely cited efficient-LIO position; GLIM owns a versatile, extensible mapping-framework position. Their current GitHub counts are useful context, not goals to imitate.
| Project | Public position | Stars on 2026-08-10 |
|---|---|---|
lidar_slam_ros2 |
rosbag2-to-verified Autoware map authoring | 837 |
koide3/glim |
versatile and extensible 3D mapping framework | 1,727 |
hku-mars/FAST_LIO |
efficient and robust LiDAR-inertial odometry | 5,043 |
The product wedge is:
The shortest trustworthy path from a rosbag2 recording to a verified Autoware-compatible map bundle.
The three primary audiences are:
- Autoware mapping teams that need a loadable point-cloud map and projector metadata, not only a trajectory;
- ROS 2 field-robotics integrators who need a diagnosable offline workflow for their own sensor data;
- researchers and students who need reproducible baselines and evidence contracts without turning research controls into product defaults.
Advanced coloured mapping, tunnel/fog resilience, and SOTA research remain valuable proof and extension tracks. They belong below the first successful map in the information hierarchy and must not obscure the primary job.
4. User-friendly means measured, including against GLIM
GLIM already offers maintained documentation, PPA binary installation, Docker images, broad sensor support, a direct rosbag executor, visual examples, and interactive correction. We should not declare victory from a longer feature list. Once per stable release, run a clean-machine usability scorecard for both public workflows on equivalent supported hardware.
Measure these tasks independently:
| Task | Measurement |
|---|---|
| Discover the supported path | time until the user identifies the correct install/run command |
| Run a fixed demo | commands, download bytes, wall time, active operator time, failure count |
| Inspect an own bag | whether topics, frames, timestamps, and profile choice are explained before execution |
| Produce a downstream artifact | whether the result is a verified Autoware bundle without manual file assembly |
| Understand a failure | whether the public error links directly to one safe recovery action |
| Repeat or upgrade | whether the same command and output contract survive a supported release upgrade |
The six rows now have a versioned
neutral usability scorecard contract. It requires
exact public product identities, one paired clean environment, the same input
per task, task-specific complete measurements, transcript hashes, and an
external first-attempt operator before reporting READY. It never infers an
overall winner. The checked-in index is intentionally NOT_READY with both
product records absent; local feature evidence is not substituted for a paired
GLIM trial. The paired recorder now removes the remaining JSON-editing step:
one command follows product order, derives command totals and outcomes from
direct observations, preserves blanks as not-recorded, validates both
records, and atomically publishes neither or both. It does not create the
still-missing external observation. Pair preparation now also replaces its two
manual public-identity Booleans with one optional GET-only preflight. Both
products' fixed canonical GitHub commit/tag or registry digest and approved
documentation host must resolve before either worksheet can be written; any
identity, redirect, or second-file publication failure leaves no half pair.
Offline preparation remains explicitly NOT_RUN and non-public. This proves
only public input identity, not a completed task or comparative result. The
preflight receipt now persists beside the worksheets and SHA-binds their exact
bytes. The recorder requires that receipt, preserves the untouched source
triplet under preparation/, and the final checker refuses explicit records
without revalidating that archive. This prevents a later JSON rewrite or
record-only handoff from becoming a CLI READY result while still inventing
no observation. The
2026-08-12 local contract evidence
records the enforced protocol and the still-missing public trials.
Only compare overlapping tasks, publish the exact versions and commands, and record where the products intentionally solve different jobs. The desired outcome is not “more user-friendly” as an unsupported slogan. It is:
- one obvious beginner path;
- an installed no-argument terminal home that reduces the first decision to installation check, demo, own bag, or retained sessions without changing automation behavior;
- one bag-optional, read-only doctor that reports stable recovery actions before a user commits time or data to mapping;
- no undocumented manual step before
map_verify: PASS; - a measured first-run completion rate of at least 80% by the tenth independent attempt;
- median active operator time below ten minutes for the fixed demo;
- every own-bag rejection includes a stable reason code and next action.
5. Growth model and leading indicators
Stars are a lagging signal. The working model is:
qualified discovery
-> first verified map
-> confidence in evidence
-> useful public report or contribution
-> recommendation and Stars
The operational north-star metric is independent verified first maps per month. It connects product utility to sustainable discovery more directly than page views or repository activity.
Scorecard
| Dimension | Baseline | 2026-11 target | 2027-06 target |
|---|---|---|---|
| GitHub Stars | 837 | 900 | 1,000 |
| 14-day unique repository visitors | 299 | 375 | 500 |
| 14-day unique Autoware/TIER IV referrals | 6 | 15 | 30 |
| Primary release-bundle downloads per release | 8 | 20 | 50 |
| Accepted independent first maps | 0 | 3 | 10 cumulative |
| External merged contributors, trailing 180 days | 0 | 2 | 5 |
| External PRs, trailing 90 days | 1 | 3 | 6 |
| Untriaged open issues | 16 | 0 | 0 |
| Median first public response to new supported-product issues | not tracked | <= 5 days | <= 72 hours |
| v1.0 readiness | 8 / 10 | 10 / 10 | maintained at 10 / 10 |
The response-time values are internal operating targets, not a contractual support SLA. If maintainer capacity cannot sustain them, reduce concurrent work and document the actual support boundary instead of hiding the delay.
Measurement rules
- Capture Stars, forks, subscribers, unique views/clones, referrers, release downloads, issue age, and contributor counts once each week.
- Keep compact weekly aggregates; do not commit user identities or a raw list of stargazers.
- Review four-week rolling values because release days and automated clones make daily totals noisy.
- Annotate releases, documentation launches, talks, and community posts so an increase can be associated with a real intervention.
- Never interpret clone totals as users; prefer unique clones, verified maps, and release artifacts.
- Re-estimate the target date monthly. Do not weaken quality gates to preserve a calendar forecast.
6. Workstreams
A. First-map activation
- Reduce the README's first screen to one promise, one visual proof, one Docker command, and one own-bag command; move advanced evidence into clear links.
- Exact local follow-up
8a8876a2d26c09cc92ad330b99d1fa217db1bd8dturns the first Quickstart decision into three bounded goals: stable Docker demo, read-only own-bag diagnosis beforestart, or candidate source dry-run. Docker is the explicit default when unsure, while each row states its host write, version, ROS, storage, and time boundary. The README remains below its 220-line budget; 29 entrypoint and 36 integrated docs/product regressions plus strict MkDocs pass. This is a discovery repair, not a release, measurement, promotion, or GLIM parity claim. - Exact follow-up
1e56431161d3dea417d5d800bb1eedc3cdb51907removes the remaining canonical-entry drift: Getting Started no longer asks a first-time visitor to choose among 12 mixed beginner and advanced actions. It shows the same three bounded goals as README and retains seven installed or post-success actions inside a rendered collapsed section. The Docs Home now also calls published v0.9.0 a stable release rather than a release candidate. Thirty focused and 37 integrated regressions plus strict MkDocs pass; no workflow, release identity, telemetry, recruitment, or GitHub state changes. - Keep
lidarslam-map start BAGas the canonical own-bag route and package it in every supported distribution. - The current local product candidate adds
lidarslam-map demo [work_dir]as the packaged public-data route over the existing Docker/source implementation. Its network- and write-free JSON plan exposes dataset identity, attribution, cache/output state, storage, and exact steps; live execution re-hashes the pinned archive and extracted bag members, reuses only receipt-rebuilt PASS output, and prints map, verifier, receipt, review, and diagnosis actions together. Its next local increment adds durable named progress, exact failure actions, anddemo --resumefor terminal post-processing without ever restarting mapping. This is a product repair, not a comparable onboarding row or publication event. - The next local activation increment reduces the source path to
bash scripts/source_quickstart.sh: it detects the installed Humble/Jazzy base, previews all actions without writes, initializes pinned submodules, installs missing base tools and repository-only dependencies, builds only the six repository packages, and runs the verified demo. The README now places the promise, visual proof, Docker command, and own-bag command before the feature inventory. A fail-closed disposable-host probe now verifies the exact public commit and route, measures disk/network/wall time, preserves private logs, and emits the existing bounded trial record. Clean Humble/Jazzy VM rows still require an exact published candidate revision before this can close a comparable source row. - The source install no longer ends at a remembered shell-activation step. Its
printed absolute
lidarslam-maplauncher now activates only the matching aggregate workspace environment for its child process. Fresh Jazzy isolated and merged installs plus a network-disabled Humble merged install selected the maintained RKO-LIO profile and reached the calibration-review dry-run with all ROS variables removed; both distributions passed the complete clean-prefix checker. The 2026-08-12 activation evidence keeps package-manager and complete cold-source claims pending. - The no-install own-bag path now has a one-command Linux host launcher:
bash scripts/docker_map_bag.sh BAG. It validates the bag and fresh output before Docker, exposes a Docker/network/write-free plan, mounts input read-only, disables external networking for the live run, runs as the host UID/GID, and delegates to the same sensor-review, mapping, verification, and session-pagelidarslam-map startcontract used after installation. This removes the prior eight-line mount recipe and its lower-levelrun --guidedfork while preserving explicit calibration review. Image capability is checked before output creation, the run is rebound to an immutable local image ID, and a zero exit cannot claim completion without the session, manifest, and receipt artifacts. Existing public v0.9.0 images correctly fail this new contract until a candidate image is published. - The canonical Autoware map-authoring landing page now follows that same
product contract instead of presenting lower-level shell and Python helpers
as competing beginner paths. It starts with one published fixed-demo route,
one source-candidate route, and one own-bag route; then keeps
doctor,start,run, session evidence, and recovery in task order. A regression test rejects the six retired beginner entrypoints on this page, and the page explicitly separates published v0.9.0 images from the unpublished v0.9.1 candidate. The docs-home primary action now points to this canonical page and labels the older viewer/dogfood quickstart as advanced compatibility. This is a local documentation repair, not a release or onboarding measurement. - The v0.9.1 release handoff now records its reviewed implementation carrier
and complete 2,468-test result instead of the stale 2,432-test snapshot. The
exact Leo Drive follow-up at
92bb524…records 0.139152 m Applanix cross-validation APE, meets the 0.500 m target, and isolates the 2.5 GB rosbag2 FILE decompression view from the source dataset. Four exact-head blockingNO_DATAprofiles remain. The maintainer checklist runs the complete product suite, strict docs, and canonical fixed demo rather than treating the older Autoware dogfood route as first-map evidence. Because the notes file becomes the public release body verbatim, the tag workflow now stops before image publication when the candidate-only banner orRelease decision: HOLDremains. This makes the current HOLD explicit and fail-closed; it does not authorize or perform a release. - The canonical NTU ground-truth benchmark acquisition now exposes a
write- and network-free plan before its multi-gigabyte work. It reports each
remaining phase, pins the official archive byte count and checksum, checks a
conservative peak working set on the selected filesystem, fails before
download when space is insufficient, and recommends an explicit external
--dest. Exact attached-storage implementation8a856f5now closes the remaining path-substitution burden: it discovers the connected unmounted 2 TB SanDisk filesystem without probing it, selects one mount action, and emits--dest-devicepreflight/live commands that preserve requested phases and recheck real free bytes after mounting. The curated bundle now includes both the documented NTU entrypoint and its resolver. This makes missing exact-head release evidence actionable without weakening the four remaining blocking profiles or treating historical runs as current. - The two blocking RTK-SLAM Construction profiles now have the same actionable
acquisition boundary. All four official ROS2 inputs use immutable exact
byte/SHA-256 identities, the checkpoint repository uses a detached pinned
commit, resumable bytes reduce the capacity plan, and text/JSON dry-runs are
network- and write-free. A real normal invocation stopped before side effects
with a root-filesystem shortfall. Exact attached-storage follow-up
0c3f588then found the connected unmounted 2 TB SanDisk partition, selected one authorization-respecting mount action, and emitted copy-ready--dest-devicedry-run/live commands that resolve the actual mount path. It never mounts, probes contents, or treats partition size as verified free space. This removes another preventable user failure; the profiles remainNO_DATAuntil fresh exact-candidate runs exist. - The next release pipeline now turns that repo-independent script into a
direct attested
lidarslam-map-dockerasset. Its exact tag and source commit are embedded deterministically, its default image is the matching immutablev<VERSION>-<distro>tag, and the read-only publication audit requires this seventh asset from v0.9.1 while preserving the historical six-asset v0.9.0 audit. This closes the local clone-free delivery implementation, not the publication or clean-machine trial: no asset, image, tag, or release was created by this work. - The verified-session page now closes the local-success-to-public-learning
gap with Share this verified first map. Its existing-command route,
lidarslam-map support SESSION --first-map, performs no write or network request, revalidates receipt-bound PASS evidence, and prints the copy-ready summary, reviewed JSON attachment, and canonical issue form. Failed sessions receive the privacy-first support ZIP action instead. This reduces the independent-validation handoff without claiming any of the still-missing 0/3 external acceptances. - Exact follow-up
da99c7ef82136449727ef97a58c1a2db4ffd6955repairs the corresponding failure-report path. The issue form no longer tells a FAIL reporter to leave a missing receipt empty and simultaneously requires them to claim that they reviewed an attachment. Its required privacy statement now accepts exactly one reviewed receipt or FAIL/no-receipt/no-file, while PASS still requires the receipt and every privacy checkbox remains required. Thirty-one focused and 38 integrated tests plus strict MkDocs pass. This enables honest product findings; it creates no validation, recruitment, or GitHub write. - Exact follow-up
a0aaadc80b952d92074f45499c29a5103a2ad479removes the remaining command-sharing ambiguity from first-map reports. The public form requests a redacted command shape, keeps executable/options/non-private values, requires literalREDACTEDplaceholders for credentials, private paths, host or user names, and precise locations, and still prohibits map geometry. The read-only handoff now prints four field-by-field completion lines using safe environment hints. Thirty-four docs and 25 support/installed-contract regressions pass without changing the v1 handoff, uploading evidence, creating an issue, or accepting a validation. - Exact follow-up
4b1707cdbc2dc41f3d7b52aa8c598841fc925767applies the same repair to normal bug intake. A startup or preflight failure no longer needs an impossible support ZIP or a false attachment-review claim: it must provide doctor output, state that no session was created, and paste the first actionable finding. Session-backed reports still require one reviewed ZIP, diagnostics remain required, and all four privacy/scope checks remain mandatory. Thirty-two focused and 39 integrated tests plus strict MkDocs pass; no issue, upload, or GitHub write is performed. - Exact follow-up
51496ca576b668d9e7dc0e7fda39ebdc21b7e1c8closes a location-disclosure risk in Autoware issue intake. The form still requires environment, command shape, verifier status, GNSS state, projector summary, observed behavior, and all three privacy attestations, but precise projector coordinates and private paths must useREDACTED. Map bundles, pointcloud/lanelet geometry, bags, raw private logs, and private-place screenshots are prohibited. SUPPORT and canonical map-authoring guidance agree; 33 focused and 40 integrated tests plus strict MkDocs pass. This performs no attachment, issue, acceptance, or GitHub write. - Exact follow-up
940195b75ea6aff648171b120539a9ab01a0248emakes public benchmark intake redaction-first. Public datasets retain canonical identity, source, license, configuration shape, and key metrics; a private or custom bag exposes only redacted sensor/environment/duration metadata. Commands and configuration use literalREDACTEDplaceholders, and three mandatory attestations prohibit bags, maps, trajectories, raw logs/data, local paths, complete custom YAML, and private-site evidence. One reviewedmetrics.jsonor public aggregate report remains optional. Forty-two integrated tests plus strict MkDocs pass; no upload, issue, benchmark execution, acceptance, or GitHub write is performed. - Exact follow-up
6a1dd87e85b966492ebefea84e87a46917885669makes public bug evidence path-free by construction.doctor <bag> --public-jsonprojects local preflight v6 into strict type/count/check/profile/finding-code evidence without bag paths, topic/frame names, local commands, raw data/logs, or free-text messages. Unreadable input returns the same schema with stablebag-preflight-input-error, while the issue form still requires review before sharing. Thirty-one preflight regressions pass with two dependency skips, plus 12 doctor, 21 option-contract, 42 docs/product, 25 support/installed, 331 broad S6 regressions, and strict MkDocs. No upload, issue, network access, or GitHub write is performed. - Exact follow-up
71cbf7e776664d40c59157fbfbad4d5611ceae03makes the safe support route visible at the failure point. Every ready or action-required human bag report keeps the full report local and displays one shell-safe exact-input--public-jsoncommand through both the source script and top-level product wrapper. Thirty-two preflight regressions pass with two dependency skips, plus 42 docs/product, 25 support/installed, 21 option-contract, and 331 broad S6 regressions, with strict MkDocs. No upload, issue, network access, or GitHub write is performed. - Exact follow-up
387a002dc7826be267fe600db906f80460e6f270removes the next own-bag decision burden. A ready product-dispatched report preserves the selected profile and reasons but replaces lower-level scripts and compatible-path alternatives with one shell-safe exact-inputstart. A report with findings withholds start and returns to the exact-inputdoctorafter the first finding. Direct preflight and JSON contracts remain detailed and unchanged. Thirty-two preflight regressions pass with two dependency skips, plus 42 docs/product, 25 support/installed, 21 option-contract, 331 broad S6, changed-codeament_flake8, and strict MkDocs. No mapping, upload, network access, issue, or GitHub write is performed. - Exact follow-up
fc87cf86cabba5f55fec47316c6a9a3a4e4cb90fbounds that one-action path to a compact product card. A ready card is at most 26 lines and shows status, duration/count, input types without topic/frame names, selected profile, check statuses, and onestart; a finding card keeps only the first message/action plus remaining stable codes and exact retry. One shell-safe private--jsoncommand retains complete detail, while direct preflight retains the expert report. Thirty-two preflight regressions pass with two dependency skips, plus 42 docs/product, 25 support/installed, 21 option-contract, 331 broad S6, changed-codeament_flake8, and strict MkDocs. No mapping, upload, network access, issue, or GitHub write is performed. - Exact follow-up
90c508eef4c6ce6868582bda80e684f14223ea4aremoves the next own-bag copy-paste detour. Interactive RKOstartshows calibration once and proceeds to one fail-closed confirmation without presenting a second--yescommand. Non-interactivestart,setup, and dry-run retain the exact reviewed rerun command. Thirty-five sensor-setup, 42 docs/product, 25 support/installed, 21 option-contract, and 331 broad S6 regressions pass, with changed-codeament_flake8and strict MkDocs. No real mapping, upload, network access, issue, or GitHub write is performed. - Exact follow-up
2d0bb84a447e29b940adda4bd432e3d5725c9cc0removes the remaining confirmed-start repetition. A confirmed livestartskips the full READY setup card and enters the existing start/progress card directly; setup-only, dry-run, and unconfirmed non-RKO review retain full input, calibration, and command detail. Thirty-six sensor-setup regressions, exact S3 lifecycle 71 and edit/merge 15, plus 42 docs/product, 25 support/installed, 21 option-contract, and 331 broad S6 regressions pass, with changed-codeament_flake8and strict MkDocs. No real mapping, upload, network access, issue, or GitHub write is performed. - Exact follow-up
8a620e54a121f5ac45913791b40b5239a59f5885unifies terminal success. One VERIFIED or UNVERIFIED card now carries map output, verification, viewer, session index/page, evidence paths, and exactly oneNext; viewer failure makes it the view retry without changing map status, and derived-index failure keeps one completed fallback card. Thirty-seven sensor-setup regressions, exact S3 lifecycle 72 and edit/merge 15, plus 42 docs/product, 25 support/installed, 21 option-contract, and 331 broad S6 regressions pass, with changed-codeament_flake8and strict MkDocs. No real mapping, upload, network access, issue, or GitHub write is performed. - Exact follow-up
14081ea101744b868b80d900bb5a1c42b4ad5046gives failed maps one repair action. The default ACTION REQUIRED card shows the first reason, remaining stable codes, one exactNext, and one detail path; all finding actions, safe retry, inspect alternatives, and evidence paths remain in recovery JSON and session evidence. Thirty-eight sensor-setup regressions, exact S3 lifecycle 73 and edit/merge 15, plus 42 docs/product, 25 support/installed, 21 option-contract, and 331 broad S6 regressions pass, with changed-codeament_flake8and strict MkDocs. No real mapping, upload, network access, issue, or GitHub write is performed. - Exact follow-up
e2043c0f324ba8fb855b3a723cb670acd40cb2adkeeps long stages visibly active without inventing progress. An unchanged non-complete stage prints at most one heartbeat every 30 seconds with its existing label and monotonic elapsed time; durable stage changes alone rewrite session artifacts, and no percentage, ETA, or delegated forward-progress claim is emitted. Thirty-nine sensor-setup regressions, exact S3 lifecycle 74 and edit/merge 15, plus 42 docs/product, 25 support/installed, 21 option-contract, and 331 broad S6 regressions pass, with changed-codeament_flake8, strict MkDocs, and plan validation. This is a mocked monitor-boundary result, not a real long mapping run, clean-host timing result, paired GLIM observation, or parity claim. No upload, network access, issue, or GitHub write is performed. - Original follow-up
6d1249e…made the lower boundary interrupt-safe, while a real ROS trial exposed an outer-dispatcher gap. Correction0301a0d…makes the stable CLI wait forstartand signals the complete isolated runner group. On the exact corrected tip, one Ctrl-C afterworkflow_runningreturned 130 in 1.5 seconds, reaped every descendant, sealedinterrupted / complete, and rendered one ACTION REQUIRED / Next / Details with no traceback or success card. Four schemas and 17 artifact checksums pass, plus 51 CLI/sensor, S3 77, lower runner 48, docs/product 42, support/installed 25, option 21, and broad S6 332 regressions. The controlled public-fixture trial used a 0.5 GiB floor with 1.58 GiB free; the default storage gate remains unsatisfied. This is not a complete map, clean-host result, paired GLIM observation, or parity claim. No upload, network access, issue, or GitHub write is performed. - Follow-up
181b251…separates expected SIGINT/SIGTERM from genuine timeout diagnosis. A second exact-tip ROS trial entered the real offline wait and kept the same 130, descendant-reap, interrupted evidence, and one-action results, while stderr fell from 9,223 to 1,845 bytes (80.00%) with zero false timeout labels or launch-log dumps. Fourteen dogfood, 48 lower-runner, 42 docs/product, 25 installed/support, 21 option-contract, and 332 broad S6 regressions pass; real timeout diagnostics remain unchanged. The same low- storage and controlled-overlay limits apply, and no remote write is performed. - Exact-installed evidence carrier
edff76d…closes that low-storage limit. The top-level command omitted the override, passed the unchanged 7.01 GiB free / 5.00 GiB required preflight, observed live RKO-LIO and graph nodes, and one Ctrl-C returned 130 in 1.43 seconds with every descendant absent. Four schemas and all eight artifacts sealed before this earlier interruption revalidate; one ACTION REQUIRED / Next / Details remains, with no timeout, traceback, success card, ormap.pcd. The controlled mixed overlay still leaves clean-host/package-manager, complete-map quality, paired GLIM, and parity claims pending. No remote write is performed. - Exact implementation
8370ac5…removes the remaining post-stop duplication without classifying exit code alone. Only a sealed manifest whose interrupted status, complete stage, execution/runner codes, and signal error all agree gets one direct-run stop/evidence line; ordinary 130 and inconsistent evidence keep full failure diagnostics. In the exact-installed default- storage ROS trial, one Ctrl-C returned 130 in 1.38 seconds and reaped every descendant. Generic map failure, repeated failed command, generic session error, false timeout, log dump, traceback, and success card all fell to zero; stderr fell 1,971 → 1,200 bytes (39.12%). Four schemas, eight checksums, 49 runner, S3 77 + 15, dogfood 14, docs/product 42, installed/support 25, option 21, and broad S6 332 checks pass. Clean-host and comparison limits remain; no remote write is performed. - Exact implementation and evidence tip
d0e3361…puts all four native bag- reader opens behind one product-onlyrosbag2_storageWARN boundary. It changes only the previously-unset logger during open, restores it afterward, and preserves direct use, explicit expert levels, and every WARN/ERROR. A direct/product real-bag probe returned 0 with identical 5,661-byte stdout; direct stderr retained two storage INFO lines while product stderr was empty. In the exact-installed unchanged-default ROS trial, both live nodes were observed and one Ctrl-C returned 130 in 1.545 seconds with every descendant absent. Six routine storage lines fell to zero and stderr fell 1,200 → 180 bytes (85.00%); one stop/evidence pair and ACTION REQUIRED / Next / Details remain. Four schemas, 18 checksums, preflight 36, runner 49, S3 77 + 15, dogfood 14, docs/product 42, installed/support 25, option 21, and broad S6 332 checks pass. Clean-host and comparison limits remain; no remote write is performed. - Exact implementation
3dcca0c…assigns guidedstartone product-owned terminal story while preserving complete direct expertrun, dogfood, warning/error/timeout, and durable-evidence behavior. The child-only concise boundary removes delegated command, output/YAML/topic/frame, staging, lifecycle, and launch-log internals from guided output. A fresh exact- revision install showed profile/storage before mapping readiness, observed both real nodes, and returned 130 in 1.543 seconds after one Ctrl-C with every descendant absent. Guided stdout fell 3,679 → 1,448 bytes (60.64%) to 23 lines; stderr retains only the stop/evidence pair. Four schemas, 18 checksums, runner 50, S3 77 + 15, sensor setup 42, dogfood 15, docs/product 42, installed/support 25, option 21, and broad S6 332 checks pass. Clean-host and paired-comparison limits remain; no remote write is performed. - Exact implementation
8e67ab7…closes the successful-completion side of the guided UX boundary. An exact-installed 50-second MID360startcompleted in 23.45 seconds withsucceeded / complete / 0 / 0, 7 / 7 receipt PASS, one VERIFIED / Next / Share card, a 4,015,933-bytemap.pcd, 92 tiles, and 124 checksums. Terminal output fell 51 lines / 3,791 bytes → 23 lines / 1,399 bytes (63.10%); all 16 hidden post-process lines remain in checksum-boundmap_workflow.log, while normal failure replays a bounded tail. Baseline and corrected map, Lanelet2, raw, and corrected trajectory bytes match. A second real-node Ctrl-C returned 130 in 1.317 seconds and reaped every descendant. Runner 54, sensor 42, dogfood 15, S3 77 + 15, S2 43 + 43, and broad S6 332 checks pass. Clean-host, public-fixture, external-user, and paired-GLIM limits remain; no remote write is performed. - Exact implementation
cb2218f…labels the verified post-success actionReport:/ Prepare a first-map report instead of implying an automatic share, while retaining the structured compatibility key. A fresh exact install reproduced the 50-second MID360 output in 23.42 seconds with the same map, Lanelet2, raw, and corrected trajectory hashes. Its displayed read-only command emitted 22 lines / 1,279 bytes; four schemas and 124 checksums pass, the complete session path/size/mtime tree is unchanged, no archive is created, andstracerecords no network syscall. This remains local preparation evidence, not an upload, issue, or external first map. - Exact implementation
e15ddab…promotes the safe handoff tolidarslam-map report SESSION. Legacysupport SESSION --first-mapremains byte-identical, but new users see no ZIP-only option inreport --help. A fresh exact install passes the complete product validator; its 22-line / 1,327-byte human output and schema-valid JSON match legacy output, leave the fixture tree unchanged, and make no network syscall understrace. Focused, S3/S6, cohort, plan, G0, strict-doc, and style gates pass. This is a shorter local handoff, not mapping, upload, browser opening, issue creation, or external acceptance. - Measure the current 517 MB demo, then provide a smaller onboarding fixture if download or run time dominates first success. Keep the full surveyed demo as proof rather than silently weakening validation.
- The first Docker machine probes measured 19–24 minute cold paths and 1.77–1.91 GB of workflow RX on Humble and Jazzy. Both product routes passed; the smaller-fixture experiment is now activated, while the full MID-360 route remains the proof path.
- The resulting 50-second MID-360 fixture pilot
produced a byte-reproducible 98,873,952-byte ZIP and a verified local map,
reducing the dataset transfer by 80.879%. It remains unpublished and cannot
replace the full gate. Its
publication review
now reports 13/13
LOCAL_ARTIFACT_PASSchecks and a four-itemAWAITING_PUBLICATION_DECISION: two revisions are not publicly resolvable, the host is unset, and upload is not authorized. - The installed public-data acquisition path now pins size and SHA-256, validates HTTP Range before resume, safely restarts Range-ignoring servers, re-hashes cache hits, and transactionally extracts preflighted ZIP members. The full 517,088,133-byte source passed a read-only identity and member audit. The unpublished fixture has no registry URL yet.
- The
published-fixture audit gate
now binds an authorized readiness review to GitHub immutable-release metadata
or a Zenodo version record, then independently re-hashes the downloaded
artifact. The existing GitHub
v0.9.0release correctly fails the new immutability requirement; no fixture host or upload has been selected. - The runtime-image slimming pilot
reduced Docker's local image-size measurement by 53.6409% on Humble and
59.6698% on Jazzy while retaining the source-free installed CLI and
schema-valid first-map result. Exact gzip OCI exports at clean commit
ff92f09then measured 568,999,756 compressed layer bytes on Humble and 547,456,033 on Jazzy: 53.635066% and 59.674709% below immutable v0.9.0 baselines, so both pass the 25% gate. Follow-up commits repaired the atomic ROS-log link and keyed Docker dependencies on package manifests. Cached exports retained identical canonical image graphs. The full public demo, clean dedicated-VM trials, and attested release-candidate reproduction remain promotion gates; no candidate was pushed. - Add tested sensor recipes for the most requested families, starting from issue evidence rather than an unbounded compatibility matrix.
- Make the final success output show the map path, verifier result, viewer path, run receipt, and exact next command in one screen.
- The current candidate now projects that handoff from
session.json, including the headless--viewer nonepath and a read-onlyShare:command for verified sessions. This is a local product-contract increment; clean-machine timing and external first-map acceptance remain separate gates. - Retained unverified and action-required sessions now print their compact
summary before
Next:in headless history, reducing the return-to-work decision without weakening the external measurement gates.
B. Trust and reproducible proof
- Finish v1.0 only through the existing
10 / 10fail-closed gate. - Publish a small human-readable benchmark scorecard whose rows link to exact datasets, revisions, commands, limitations, and machine-readable evidence.
- Treat the negative SOTA-v5/v6 outcomes as honest research records. Do not put an unresolved SOTA route on the product-release critical path.
- Convert major claims into short visual proof: input, command, output map, verifier result, and measured accuracy or runtime.
- Keep comparison language task-specific. Algorithm accuracy, onboarding, downstream map authoring, GPU requirements, and sensor breadth are different axes.
C. Distribution and discovery
- Complete the current rosdistro dependency path. As of 2026-08-12,
ros/rosdistroPRs #52949 and #52950 remain open with an unanswered question about overlap with the existingndt_omppackage. Both old exact heads also have one failed stale-base rosdep check; this is not caused by the NDT YAML delta, but neither head is green. Resolve that collision through upstream convergence or full isolation before requesting merge, then refresh or replace the generated registration from current rosdistromasterand require every check to pass. A hash-bound upstream patch and complete five-file parent transition now pass exact-base checking plus network-isolated Humble/Jazzy four-package builds. The read-only Draft publication preflight additionally passes 30/30 checks for exact candidate identity, current upstream/fork/branch state, and duplicate PR absence. Its schema-bound handoff now fixes the exact create-only branch, base/head identities, Draft copy, and GET-only verification route only while all 30 checks pass; it grants no push, PR, force-push, ready, or merge authority. Publication still requires an explicit maintainer decision. - Keep the parent v1 live audit aligned with every schema-valid child outcome.
It now preserves package-manager
SOURCE_REF_MISSING,NOT_RUN,RUNNING,FAILED,READY, andBLOCKEDstates in machine and human output. Thus the current authenticated tupleBLOCKED / SOURCE_REF_MISSING / PUBLISHEDremains an actionable 8/10 result instead of being misreported as an invalid audit. Only the exactREADYchild state can close distribution. - Exercise clean install and upgrade on Humble and Jazzy after the packages are available, then publish v1.0 from the same verified contract.
- Produce one sub-three-minute English demo with captions and one concise Japanese companion post. Both point to the same canonical quickstart.
- The local media path now produces a 10.666-second H.264 candidate, four-cue
English WebVTT, exact-revision Japanese/English copy, and a schema-valid
SHA-256 manifest from one versioned contract. It rejects the previously
bundled
v0.2.2copy, retired commands, localn/ametrics, and numerical performance claims before rendering. The candidate remainsNOT_PUBLISHED; public posting still follows same-version artifact/docs audits and a separate external-action decision. - Create durable task pages for “ROS 2 LiDAR SLAM quickstart”, “rosbag2 to Autoware point-cloud map”, and supported sensor recipes. Avoid duplicate SEO pages with no additional operational value.
- Announce only meaningful evidence or releases through the relevant ROS and Autoware community channels. One canonical post plus substantive updates is preferable to repeated promotion.
D. Community and contributor loop
- Review all 29 open issues. Label the supported surface, preserve reusable answers in docs, close resolved or obsolete reports with a reason, and move broad usage discussion only after a suitable public discussion route exists.
- The
2026-08-11 read-only community audit
groups the complete backlog and defines five copy-ready starter tasks. They
are
PREPARED_NOT_PUBLISHED; creating issues or changing labels still needs explicit authorization and a current duplicate check. - The corresponding
29/29 issue disposition proposal
is machine-validated and passes an exact read-only live-drift check. It keeps
two issues open, requests four current reproductions, and proposes 23 reasoned
closures, but remains
PROPOSED_NOT_APPLIED. - The #69 review card no longer relies on a maintainer remembering two dated
facts. Its GET-only linked gate requires exact public Draft/CI state and also
binds latest stable
v0.9.0/0df0c4aas 52 commits behind fixa2368c4, with nov0.9.1tag or release. Any drift suppresses the prepared response; this adds no Issue or release authority. - As of 2026-08-15, the C1 g2o, C2 empty-map, C3 Odometry/TF, and C4 custom
PointCloud2 documentation gaps are implemented and retired without reusing
their IDs. The refreshed C5–C9 generation restores five locally
READY, 30-minute documentation scopes: the Japanese follow-up handoff, live versus optimized pose outputs, mapping/loop/relocalization boundaries, classic IMU readiness, and long-route stop triage. A capture-time read-only audit found only PR #427 and no matching implementation PR; the queue remainsPREPARED_NOT_PUBLISHEDand requires a fresh audit plus a separate community publication decision. - Exact follow-up
e4ce0aa6eb7d53423423a02af65f923472708f44prevents the blocked first-map cohort issue from freezing independent starter preparation. A live authenticated GET-only card still keeps #422 unavailable to contributors, but after duplicate review it now gives maintainers one C5 preview action while C6–C9 remain queued. No local task becomes public, assigned, or claimable, and every issue/label/write authority remains false. - Exact follow-up
0a34e724875d53b8ef74acd8a51fd500ce014ff5removes the next manual publication step. The authenticated live card binds the selected C5 title, sorted labels, heading-free body, task/queue hashes, and body SHA-256 into one schema-valid local handoff. Cross-task or body tampering fails closed; maintainer confirmation and a separate external write remain required, and issue creation stays unauthorized. - Exact follow-up
5dc04198549341b33becdeb2bc058117db9fe78fprevents that review-ready handoff from outrunning its public product base. Local task publication review now requires both PR #427 merged and the canonical queue present with an exact SHA-256 match on publicdevelop. While the Draft is open and the public queue is absent, the one action is post-merge preparation; it cannot recommend issue publication or grant write authority. - Recruit the first three validators through the existing public validation issue and release documentation; do not provide private step-by-step help that would invalidate the evidence.
- Maintain five to ten bounded
good first issuetasks with a fixture, expected output, relevant files, and a check command. - Make the contributor path finish in under 30 minutes for documentation and small CLI changes. Provide focused tests instead of requiring every public dataset.
- Keep contributor-facing product entrypoints synchronized with the product contract. The 2026-08-12 local repair replaces a stale three-entrypoint list with the current four workflows and regression-checks both the canonical commands and focused test route. Its unsourced-shell full gate also auto-selects supported ROS, checks both package suites, and enforces that every product pytest remains registered with CTest; the current local result is 2,050 passed across the two suites.
- Enable GitHub Discussions only after categories, moderation expectations, support boundaries, and a weekly triage slot are ready.
- Invite sustained contributors into review and roadmap discussion before
expanding merge rights under
GOVERNANCE.md.
E. Releaseable architecture and repository hygiene
- Split the 229-commit local delta into product, research, and generated
evidence inventories. Integrate reviewable product slices from a clean
origin/developbase instead of publishing the whole development branch. - Keep runtime code, bounded test fixtures, and durable research conclusions in Git. Keep bags, build logs, raw replay outputs, generated maps, and repeated benchmark artifacts outside the repository or in release evidence storage.
- Audit the 172,506 KiB repository history and release assets before deciding whether history migration is justified. Do not rewrite public history merely to improve a vanity size number.
- Maintain one product release candidate, one community task, and at most one exploratory research candidate in progress at once.
- Keep container verification and publication as separate authority domains.
Pull requests and manual dispatches build and smoke-test with a contents-read
token only; moving convenience tags may change only on a
developpush, and immutable matrix-candidate publication uses the separate default-branchrepository_dispatchgate. That gate requires exact-head green CI, a maintain/admin repository role, literal E2 digest-only approval, and a protectedcandidate-imagesenvironment with self-review prevented and deployment restricted todevelop; its package-write job can publish untagged digests but cannot create or move a tag. A shared schema-backed checker audits the complete live environment inventory and exact policy with GET requests only. Its status-specific operator handoff makes the required settings URL, reviewer/self-review/develop-only checklist, independent review, and read-only recheck copy-ready without performing a write. Gate availability is not E2 authorization. - Budget normal maintainer effort at approximately 60% product/reliability, 20% distribution/community, and 20% research. Research can use spare capacity but cannot delay a failed product, support, or release gate.
F. Sustainable communication
- Ship a compact monthly “what became easier” update, not a raw commit list.
- Show one before/after workflow, one evidence result, known limitations, and a contributor credit in each release note.
- Create case studies only with user permission and privacy-safe artifacts.
- Credit external reports, documentation, fixes, and benchmark submissions, not only code.
7. Phases and Star checkpoints
Star counts are forecast checkpoints, not phase-exit gates. Quality outcomes control progression.
| Phase | Window | Quality exit | Star checkpoint |
|---|---|---|---|
| G0 — release hygiene | 2026-08-10 to 2026-09-30 | clean product integration path, weekly metrics, all open issues triaged, public v0.9 first-map baseline measured | 860 |
| G1 — v1 activation | 2026-10-01 to 2026-11-30 | v1 audit 10/10, three accepted external first maps, canonical guided path in packaged products | 900 |
| G2 — proof and launch | 2026-12-01 to 2027-02-28 | stable v1 release, public UX/benchmark scorecard, demo video, at least two recent external contributors | 950 |
| G3 — ecosystem | 2027-03-01 to 2027-06-30 | ten cumulative first maps, five recent external contributors, maintained sensor recipes and support targets | 1,000 |
| G4 — sustain | 2027-07-01 to 2027-09-30 | 90-day post-milestone health review, current release, no regression in activation or contributor metrics | maintain >= 1,000 |
| G5 — institutionalize | 2027-10-01 to 2027-12-31 | two repeatable release cycles, one non-maintainer review owner, documented support capacity, and no single private artifact on the release path | maintain >= 1,000 |
If the March stretch target is reached, do not skip G3 quality work. Move directly into the sustainability review.
Long-range dependency map
The phases are not independent feature buckets. The durable path to 1,000 Stars has one evidence-gated dependency chain:
smaller runtime image + bounded onboarding fixture
-> comparable Humble/Jazzy Docker and source trials
-> public validator cohort + package-manager proof
-> v1.0 readiness 10 / 10
-> canonical proof launch
-> maintained sensor and contributor ecosystem
-> 1,000-Star milestone + 90-day sustainability audit
-> repeatable release and review ownership beyond one maintainer
Issue triage, weekly aggregate measurement, release maintenance, and bounded research run beside this chain rather than after it. An external rosdistro delay must not stop onboarding repair or validator preparation. Conversely, a research result, traffic spike, or early Star checkpoint cannot bypass a failed activation, distribution, or adoption gate.
| Horizon | Product and trust | Adoption and community | Distribution and communication | Outcome checkpoint |
|---|---|---|---|---|
| 2026 Aug–Sep — G0 | reduce and measure the cold first-map path; preserve full-gate parity | triage the backlog and prepare bounded validator tasks | establish comparable Humble/Jazzy Docker/source evidence | reviewable product line and 860-Star forecast checkpoint |
| 2026 Oct–Nov — G1 | close the 10/10 v1 audit from real package and first-map evidence | accept three independent first maps; keep five to ten bounded contribution tasks | finish package-manager proof and prepare the canonical v1 landing path | verified activation and 900-Star forecast checkpoint |
| 2026 Dec–2027 Feb — G2 | publish a current stable v1 release and reproducible UX/benchmark scorecard | retain at least two recent external contributors and publish reusable user findings | release one short English demo and Japanese companion through relevant channels | proof-led launch and 950-Star base checkpoint; 1,000 stretch only if quality gates already pass |
| 2027 Mar–Jun — G3 | maintain release freshness, claim evidence, and supported sensor recipes | reach ten cumulative first maps and five recent external contributors | grow durable Autoware/ROS task pages and qualified referrals | 1,000 Stars in two weekly snapshots, with all completion conditions still passing |
| 2027 Jul–Sep — G4 | prevent activation, reliability, and upgrade regressions | verify that support and review load remain maintainable | publish a 90-day health review instead of immediately expanding scope | sustain at least 1,000 Stars and a healthy project for 90 days |
| 2027 Oct–Dec — G5 | rehearse two releases from public inputs and documented gates | transfer ownership of one review area and keep the starter queue healthy | publish only maintained proof and a year-end health report | remain useful and releaseable after the milestone campaign ends |
Every six weeks, select the largest measured constraint in the discovery-to- first-map-to-contribution funnel. Start no more than one product/release slice, one community slice, and one bounded research slice at once. If the calendar and a quality gate conflict, revise the forecast rather than the gate.
8. First 90 days
Sprint 1 — separate what can safely ship (weeks 1–2)
- Inventory the 229 unpublished commits and dirty files into product, research, evidence, and generated-output groups.
- Start a clean product integration line from
origin/developand bring over only the guided CLI, product contract, packaging, and directly related tests in reviewable slices. - keep
log-*, raw bags, maps, and replay evidence outside the source tree; add narrow ignore rules only after confirming every target is generated. - Run strict docs, supported package tests, release-bundle rehearsal, and the fixed Docker first-map path from the exact candidate revision.
Exit: a clean, reviewable candidate exists; no research result or generated artifact is required to install or use it.
Sprint 2 — measure and repair first success (weeks 3–4)
- Run the public v0.9 Docker and source paths on clean Humble and Jazzy machines.
- Record download size, wall time, active operator time, commands, peak disk, failure reason, verifier result, and receipt status with the comparable onboarding trial contract.
- Test
--guidedwith representative valid and invalid bag metadata. - Fix the largest observed activation blocker before changing the landing page or creating promotional material.
Exit: the project has a reproducible onboarding baseline and no undocumented manual step on the fixed demo.
Sprint 3 — close the two v1 blockers (weeks 5–8)
- With explicit publication approval, submit the prepared required NDT APIs
upstream as a Draft only after the strict 30/30 read-only preflight reports
READY_FOR_DRAFT_PRand emits the exact create-only handoff; abort if its branch/base/candidate identity drifts. GET-only verify the resulting Draft, replace the reply packet's URL placeholder with that verified PR, answer the two openndt_omp_ros2rosdistro reviews with the collision analysis, and rerun the review/check-aware readiness audit after every external state change. If upstream declines, fully isolate the fork. Generate the selected replacement from current rosdistromasterand require all checks to pass; do not merge overlapping Debian payloads or a red exact head merely to shorten installation. - Execute package-manager clean-install and upgrade evidence when the required repositories contain the packages.
- Run a public first-map validation cohort. Treat every failed attempt as a product finding, resolve it publicly, and rerun without live guidance.
- Require the complete v1 audit before tagging v1.0.
Exit: distribution is reproducible and three independent users have reached a verified map, or the exact remaining external blocker is publicly recorded.
Sprint 4 — publish proof, not promises (weeks 9–12)
- Restructure the README around the measured first-map route.
- Publish the short demo, UX scorecard, benchmark summary, limitations, and v1 release evidence from one canonical landing page.
- Prepare five bounded contributor tasks from onboarding findings and the old issue backlog.
- Announce the release through a small number of relevant channels and review qualified traffic, validation, support load, and Stars after two and four weeks.
Exit: a new visitor can understand the job, see proof, try it, report a result, and find a contribution without maintainer guidance.
9. Decision rules
- If four-week Star growth is below 12 and qualified traffic is also flat, improve distribution and the clarity of the product wedge.
- If traffic rises but first-map receipts do not, stop promotion and repair onboarding.
- If first maps rise but Stars do not, improve the proof summary and the post-success invitation; do not add unrelated features.
- If support load exceeds the response target for two weeks, reduce launch activity and close documentation or diagnosis gaps before enabling another channel.
- If external contributors cannot run focused checks, invest in fixtures and
development setup before creating more
good first issuelabels. - If an exploratory SOTA route fails its preregistered gate, retain the honest result, run only the authorized bounded diagnostic, and remove the route from the product critical path.
- If a Star checkpoint is missed while activation and contribution improve, keep the quality plan and revise the forecast. If Stars rise while those signals decline, treat the growth as non-durable.
10. Immediate next development decision
The next project-wide sprint is G0 release hygiene and product integration,
not another broad algorithm expansion. Its first local deliverable, the P1
reliability fix for issue #69, now passes through bce5a9d: all five classic
scanmatcher VoxelGrid stages fail closed on unsafe integer layouts, 11 boundary
tests pass, valid-cloud PCL output is unchanged, and one real component rejects
the unsafe frame before publishing a map then publishes map and pose for a
later safe frame. The component test passed ten consecutive runs and the full
10-suite scanmatcher CTest passed on both Humble/PCL 1.12 and Jazzy/PCL 1.14. The
evidence record keeps
the public issue open until a reviewed public revision, supported public CI,
and carrying release exist. The S1 review now additionally commits the movement
baseline only after a map update succeeds: an unsafe asynchronous update cannot
consume the threshold needed by the next safe scan, and worker exceptions are
contained without terminating the component. The current v44
research route remains limited to its already-authorized bounded failure-profile
work and cannot block this sprint.
The immediate public-operations dependency is now explicit rather than a
repeated audit loop. When local and public Draft heads differ, the G0 dashboard
checks their local ancestry and emits one exact, schema-bound non-force branch
handoff. It binds the canonical GitHub repository URL, PR branch, public head,
local tip, separate exact-tip authority, and post-update GET-only audit while
keeping push, force-push, and writes false and printing no push command. Missing
history is fetched only from the canonical repository URL, never from an
arbitrary checkout-specific origin. This makes the next maintainer decision
copy-ready without turning a local plan into publication authority.
The branch action now also carries a canonical PR-description refresh because
the public body can drift independently from the branch. Its exact body and
SHA-256 are generated from one clean desired head and the current whole-PR,
P2, v1, onboarding, and independent-validation counts. Updating that body is a
separate exact-tip decision after branch verification; the checker prints no
edit command, requires Draft state to remain, and grants no review, mark-ready,
merge, release, or outreach authority. Even an exact green head is held before
review when the observed body digest is stale.
The body now makes the large Draft navigable without another lookup: validated
P0–P2 start/end commits become three exact GitHub compare links, and validated
S1–S7 metadata becomes a compact focus/path/check/publication-gate table.
Contiguous
lineage, whole-PR commit composition, P2 path composition, safe Markdown
labels, and no-write authority are checked before rendering. The desired-tip
compare link is intentionally useful only after the ordered branch update.
Exact follow-up 4404f877263157d09ae6c451dae55f5ddbbd03af also turns the
public-product transition into one user-facing read. The
--include-public-transition alias evaluates Draft → protected environment →
published release together, while its schema-bound handoff distinguishes audit
required, external publication required, blocked audit, and a genuinely
published identity ready for a fresh matrix packet. It rejects unsafe or
mismatched version identity and forbids reuse of old mixed-version measurements.
The live observation exposes the actual order: fast-forward Draft update review
first, then the absent candidate-images environment, then the absent v0.9.1
tag/Release/images. It performs and authorizes no external action.
The 2026-08-10 G0 activation decision selects the missing clean Docker/source onboarding baseline as the first measured blocker. Broad promotion remains behind the four-row trial and repair gate.
The immediate bounded G0 multi-stage runtime-image pilot has passed both its
local Docker-size proxy and exact compressed-layer gate on both supported
distributions. Its
evidence record
keeps the image and fixture reductions separate. Promotion is still paused
until the full public demo and clean comparable-VM evidence pass from the
reviewed candidate; the final attested release build must reproduce the
compressed gate. The atomic ROS-log link and Docker dependency-cache boundary
have passed exact-revision follow-ups. The 50-second fixture has also passed a
non-publishing local review. The source route is now public at exact commit
549ef03017c776f23fc968881b346aa685356274; the active implementation is the
dedicated Humble/Jazzy Docker/source matrix, including confirmation of both
repairs, not a public image retag.
The source side of that matrix now has a local disposable-host executor with a
read-only plan, public-identity preflight, fixed 250 ms disk sampling, isolated
RX measurement, timeout cleanup, receipt verification, and privacy-bounded
record generation. The immutable public-identity prerequisite now passes at
549ef030; the source route has since produced valid Humble and Jazzy PASS
records, but the evidence gate remains open because those runtime-image trials
did not observe human active time or a cold dependency-install baseline. They
also belong to product 0.9.1, while the frozen Docker rows remain 0.9.0;
the matrix exposes that cross-version evidence but refuses to compare it.
That executor now separates public route readiness from VM execution. A
network-read-only --public-preflight requires the exact six maintained source
packages, explicit package selection, repository-only dependency helper,
tests-disabled build, canonical beginner page, and matching VERSION from the
same immutable commit. The quickstart independently checks colcon list before
rosdep/build and fails inventory drift with a stable code. The former base
3f4dd70 correctly reported NOT_READY; exact public candidate 549ef030 now
reports READY for 0.9.1 without writes. The observer never substitutes a
private checkout.
The local technical prerequisite beneath those source rows now passes on both
distributions. Fixed, network-disabled Humble and Jazzy images built all six
maintained packages from the read-only candidate in 302 and 273 seconds,
respectively; the source/install package inventories match, the absolute
fresh-terminal real-bag route and complete installed contract pass, and the
prefix remains free of Python cache writes. The run also found and closed a
package-content leak that copied development __pycache__ plus a runtime
bytecode-write path. This is deliberately recorded as an all-source overlay
proof, not a comparable onboarding row: system dependencies were already in
the images and the run lacked disposable-host timing. The
evidence record
keeps those limits explicit.
The installed CLI now also has a local, TTY-only no-argument home for the common
intents: installation check, fixed demo, own rosbag2, and retained sessions. It
delegates to the existing versioned commands, prints the exact command first,
requires an explicit yes before demo writes, and leaves non-interactive
no-argument behavior at exit 2. This directly reduces command-discovery time
in the GLIM usability scorecard without inventing another mapping workflow;
clean-machine timing still belongs to the four-row onboarding trial.
The 2026-08-12 evidence record
binds its source, installed, TTY, safety, documentation, and regression checks.
The local GLIM-parity system-doctor increment now extends doctor without
duplicating bag preflight. With no bag it verifies the curated product surface,
matching install, supported ROS environment, bag reader, and demo storage,
returning path-free JSON and stable recovery actions without network or writes.
With a bag it retains the existing input/profile inspection. The
2026-08-12 system-doctor evidence
keeps the real PPA/package-manager advantage and public clean-machine
comparison pending.
Exact implementation 402c23765fe125a2f42d7fd245d2a1c972a1ab34 moves the
existing Odometry/TF support card into that same bag doctor. A bounded scan now
checks one deterministic
Odometry topic against all recorded TF topics, accepts a dynamic multi-hop
path, and separates invalid frames, no path, static-only evidence, and reader
failure. Findings stay visible beside a compatible maintained mapping path and
do not pretend to prove live freshness, timing, calibration, or accuracy. The
bounded evidence record
keeps those claim and mutation limits explicit; no GitHub issue was changed.
The follow-up preflight v6 increment addresses the still-open Issue #64 timing burden without changing scan matching. For the selected PointCloud2 topic it replays recorded TF availability in bag order, reports clouds seen before all required dynamic edges, and measures every positive future-TF gap against the limiting path edge. It deliberately does not silence warnings, raise a timeout, or substitute stale TF. The timing evidence record keeps live scheduling, DDS, clock, buffer-history, interpolation, and map quality claims open for runtime validation.
A read-only 2026-08-16 issue review found the same old file-edit handoff in
#95,
#98,
#103,
#106,
#111, and
#115: people using
Ouster, Velodyne, RoboSense, simulated, or other PointCloud2 inputs were asked
which launch/YAML files to fork before the product could inspect their bag.
Exact implementation 6950764154dfe0a2159f701d8d01cd55ce5907af replaces that
discovery burden with one bounded message across the TTY home, system doctor,
README, canonical map-authoring page, Japanese quickstart, and release notes:
run doctor, then start; do not guess remaps, frames, transforms, or tracked
file edits. Unsafe inputs still stop before mapping with a stable reason code,
and PointCloud2 detection is explicitly not a vendor-support or accuracy
claim. The complete maintained Python gate passes 2,469 tests with 13 known
skips, strict MkDocs and changed-file Jazzy ament_flake8 pass, and the
implementation-carrier candidate bundle remains 261 files.
A second read-only 2026-08-16 issue review found a recurring burden after a run
does finish: users describe maps that rotate, spiral, oscillate, drift, stop
early, look sparse, or fail to appear in
#89,
#92,
#93,
#94,
#96,
#100,
#101,
#104,
#105, and
#124. Exact
implementation ee453532a70d2d4b82a6c50c65f19b22d76c239f extends the existing
retained-run inspect command with five bounded, user-reported symptom codes.
It orders sensor, timestamp, calibration, TF, runtime, map-save, and viewer
checks and returns shell-safe product commands without editing parameters,
starting mapping, uploading evidence, or claiming an automatic root cause or
accuracy result. Exact validation carrier
9f8a2058a3c702f69d159079568ced8433ee3377 passes 2,474 maintained Python
tests with 13 known skips, strict MkDocs, changed-file Jazzy ament_flake8,
and a byte-reproducible 261-file candidate bundle. This closes one local
support-navigation gap; it does not prove that any reported map was repaired.
The next issue-driven handoff check found that this bounded symptom was lost
again when an operator ran support: maintainers received generic diagnosis
state but not the fixed visual symptom that prompted the report. Exact
implementation 0d102e016717d2def3db3a99525755837461f759 carries only the
five-code enum and USER_REPORTED_NOT_AUTOMATICALLY_DIAGNOSED into the
privacy-bounded JSON and issue body. Symptom titles, checks, commands, free
text, paths, maps, bags, and logs remain excluded; malformed codes, mismatches,
and automatic-cause claims become invalid diagnosis evidence. The focused 56
tests, strict MkDocs, changed-file Jazzy ament_flake8, and complete 2,482-test
maintained gate pass. This reduces issue clarification round trips without
claiming that the symptom is a diagnosed cause or that a map was repaired.
The next activation repair closes the largest locally reproduced fixed-demo
rejection gap: low storage no longer leaves the operator to calculate a
shortage, replace <dir>, or reconstruct prior options. Both system doctor and
demo plans now expose exact additional_bytes_required; human output rounds
up, system JSON remains path-free, and demo recovery retains the complete
shell-quoted command. The 8 GiB safety floor is unchanged. This improves the
local path but does not replace the still-pending public paired observation.
An unconfigured-terminal audit then exposed a smaller but real decision gap in
that same surface: five valid blockers produced five equal-looking recovery
instructions. Exact implementation
a83bbfeaea8196a19513c7a26772d500fe8419b8 keeps every stable finding and its
machine recovery, but adds one schema-bound top-level next_action and one
human Do this now card selected in dependency order. Rerunning doctor
reprioritizes the remaining blockers. The exact observed source-checkout run
selected source-build-required, retained four follow-up checks, and performed
no network access or write. This is a reduction in first-decision burden, not a
new doctor surface or comparative usability result.
This local UX increment is complete in the reviewed candidate; the remaining GLIM-parity work is measurement, not another overlapping doctor surface. The next action is a neutral paired scorecard on exact public identities, using the six fixed tasks and an external first-attempt operator after the product release/image gate opens. Until then, local feature checks must not be written as a comparative usability claim. The pair command can now GET-verify those exact identities and documentation atomically before handoff, so the external operator no longer has to make a manual public-resolvability assertion. The same handoff now carries its content-bound preparation archive through recording and final validation rather than relying on maintainer memory.
The existing GLIM comparison harness now also fails closed on reference-cache reuse. Its key binds bag/config/runtime/options and both cache implementations, while a schema-backed manifest binds the validated TUM bytes. Legacy path/topic-only files, changed inputs, and contradictory artifacts are misses. This removes a stale-reference integrity risk in the current measurement surface; it does not add a new doctor, substitute a fresh GLIM run, or satisfy the still-pending paired usability scorecard.
The beginner entry now also has a short Japanese quickstart linked from the README and Docs home. It keeps only the canonical doctor, Docker demo, source helper, own-bag, success, and recovery decisions; a regression binds those commands and safety boundaries to the release bundle. The page states that PPA/package-manager installation remains unavailable instead of translating a future promise into a current path. The 2026-08-12 local evidence keeps publication and Japanese first-user timing pending.
The matrix decision is now machine-checked rather than inferred from a table.
The no-argument checker now loads an explicit schema-backed evidence index
instead of falsely reporting zero rows when paths are omitted. Current tracked
evidence reports BLOCKED: all four outcomes are present and all four are
product PASS, but zero rows are comparable because human measurements are
still missing, the historical rows do not retain their exact privacy-bounded
first-map validation receipts, and the Docker/source product versions are not
aligned. G0 cannot advance the activation gate until the rows share one
product version and at least one clean Docker row plus one clean source row
has both complete measurements and a SHA-bound, schema-valid retained receipt.
The
stricter target remains all four rows comparable. A source row is not valid
until its exact revision is publicly resolvable, and a shortened-fixture row
must bind the published ZIP checksum rather than a private local copy.
The parallel G0 community slice is also bounded. The live read-only audit found
one current good first issue and prepared five additional tasks from the old
support backlog. The task bodies, 30-minute estimates, files, checks, and
non-goals are recorded locally; no GitHub issue or label has been changed.
Source publication and community publication are separate decisions.
Those five tasks now have a schema-backed local queue and a contributor-facing
inspector. Its fixed profiles reject arbitrary commands, verify exact allowed
paths and labels, mark a task stale when its known implementation gap changes,
and retain PREPARED_NOT_PUBLISHED plus no-write authority in machine output.
A 2026-08-12 read-only duplicate audit found one open PR (#427) and zero
task-matching open PRs. The 2026-08-15 drift refresh now correctly retires
C1–C4 after their cards were implemented. A second 2026-08-15 read-only audit
then replenishes the ordered generation as C5–C9, with all five exact gap
markers absent and no matching implementation PR. Publication still requires
a fresh duplicate check and a separate maintainer decision; local readiness
does not mean an issue exists, is assigned, or is advertised.
The live queue no longer lets the closed #422 cohort gate suppress unrelated
maintainer preparation. Exact follow-up e4ce0aa… keeps the contributor action
at WAIT_FOR_READY_PUBLISHED_STARTER, retains #422 and its six blockers, and
selects one duplicate-free local C5 preview for the maintainer. Potential pull
request duplicates still take precedence over every publication preview, and
the preview performs no issue or label mutation. This keeps the community
slice moving without recruiting anyone into unpublished product instructions.
The following 0a34e72… handoff also prevents a maintainer from manually
recombining a live duplicate decision with stale task bytes: title, labels,
body, and three digests now travel together. It provides no GitHub mutation
command and cannot convert local review readiness into publication authority.
Follow-up 5dc0419… additionally binds that handoff to the public product
base. Its GET-only gate distinguishes an open/unmerged Draft, a closed-unmerged
PR, a missing queue, queue drift, and the sole READY state: merged PR #427
plus a canonical queue match on public develop. Current live state is
WAITING_FOR_PRODUCT_MERGE with public queue ABSENT, so C5 remains a
post-merge preparation artifact rather than a publishable issue.
The
clean-candidate audit
and
external-action packet
led to public Draft PR #427. Exact public route baseline 0c67387 contains
the complete reviewed source path and has a network-read-only READY result.
G0 remains HOLD: the matrix is 4/4 present and 0/4 comparable, v1 is 8/10,
and the existing v0.9.0 tag prevents version reuse.
The candidate-session command now also has one read-only --check-readiness
mode instead of another overlapping doctor surface. The same exact run URL,
row, destination, filesystem, human-measurement mode, and isolation
acknowledgement produce stable host findings plus one shell-safe next command.
It distinguishes a runnable but non-comparable row from a blocked host before
any download, Docker build, APT/source mutation, evidence write, or trial. This
reduces scorecard command discovery and setup failures; it does not replace the
still-missing neutral paired GLIM trial or comparable G0 evidence.
The historical 207-path follow-up from the frozen comparison base has since been expanded into the current 349-path exact dependency-ordered publication slice plan. Its checker gives every path one review owner across runtime safety, first-map foundation, map lifecycle, source onboarding, distribution, product-shell integration, and publication control. The plan itself remains local-authority only even though its reviewed carrier is public; further PR updates require a clean exact candidate and complete gates.
The later whole-PR coverage audit closes a review-boundary gap between the original 116-path clean-candidate audit and that follow-up plan. The machine gate now composes the initial audit, the exact two-commit / 11-path CI bridge, and all seven follow-up slices into the final 396-path PR inventory. Missing phase paths, changed fixed SHA/digest, an unapproved bridge path, non-linear history, or an unsafe review record fails closed before the G0 dashboard can advance. This makes a very large Draft reviewable without treating a green local plan as push, merge, release, or community authority.
The same checker now renders one bounded --overview card before reviewers
drill into the seven exact --slice cards. It shows the three contiguous
commit ranges, 396-path union, overlap/missing/extra results, slice sizes,
dependencies, verification counts, and publication gates without pasting the
complete 349-path follow-up inventory into the PR summary. Human and JSON
forms stay local-only, execute no displayed check, and cannot submit a review
or authorize a push, ready transition, or merge. This targets the current
review bottleneck—an otherwise verified but very large Draft—without adding
another product surface.
The overview and slice cards now derive a review budget from the same exact Git ranges: textual additions/deletions, binary paths, and up to three largest textual deltas. The seven slice budgets must compose exactly to the follow-up budget, every numstat inventory must match its path digest, and malformed or stale Git output fails closed. Exact slice cards name binary media rather than hiding it behind a total. These numbers tell a human where to begin; they are not a risk score, submitted review, correctness claim, or merge authority.
The G0 dashboard now audits that prerequisite directly through bounded GitHub
GETs. It binds local HEAD to Draft PR #427, the canonical branches, mergeable
state, and the latest exact-head check runs. Draft review and the separate
merge decision are selected before any candidate-images administration;
green CI never grants merge, environment, E2, E3, or E4 authority.
The shared read-only API layer reuses an explicit token or the existing
gh auth login without exposing credentials, and attaches authorization only
to exact https://api.github.com GET requests. Wrong hosts, schemes, ports,
userinfo, and write methods fail closed, reducing anonymous-rate-limit false
blockers without adding remote-write authority.
When that exact Draft is green, the dashboard now carries a schema-bound review
handoff: exact head, 396-path / three-phase / seven-slice coverage, overview,
slice template, and a fixed overview → P0/P1/P2 → S1–S7 sequence. It refuses
the handoff when the worktree is dirty and selects read-only status inspection
instead. It also requires the public PR body to match the canonical clean-tip
description digest; stale scope text gets a separately authorized, exact-body,
keep-Draft refresh handoff before review. Neither path executes checks, edits a
PR, submits a review, marks ready, merges, or performs a write.
That exact body also carries three clickable phase diffs and seven bounded
focus/path/check/gate rows, all rebuilt from the validated local overview
rather than copied from prose. A disconnected range, stale count, injected
link label, dirty tip,
or write-authority claim fails before reviewer navigation is emitted.
The same packet now turns seven technical slices into four capability lanes:
runtime safety, operator UX, distribution, and integration/publication. Two
reviewers is an advisory capacity target, never a merge gate; the contract
stores no personal identity and grants no reviewer-request, review, ready, or
merge authority. This gives a potential contributor a bounded way to choose a
useful review area without inventing or collecting a maintainer roster.
An append-only local ledger now closes the next evidence gap. It records only
lane, slice, exact in-scope path, bounded finding category/detail, and a human-
reported PASS or BLOCKED outcome. It stores no reviewer identity or timestamp,
must live outside the repository to avoid changing its own reviewed SHA, keeps
superseded blocker events as history, and refuses stale dependencies. Local
completion remains evidence for a later decision, not a submitted GitHub
review or ready/merge authority.
The seven review cards also carry self-contained, cache-free verification:
ROS-dependent checks source Humble/Jazzy explicitly, package test roots remain
in separate pytest processes, and recognized direct remote-write CLI forms fail
plan validation. Exact follow-up 0633c2a604489538e0f087c02385e7c6467540c3
extends that boundary to the S6 docs/product-CLI command after exact execution
from an unsourced shell exposed two rosbag2_py import failures; the repaired
displayed command now passes all 42 tests and removing its prelude fails
validation.
Evidence carrier 72a8c9e77eba33c1578a3cd9c8afe8fbe6933e33
passes 2,488 maintained Python tests and a byte-identical 261-file candidate
bundle rehearsal without granting publication authority.
The later RTK-SLAM attached-storage synchronization passes 2,506 maintained
Python tests and retains the exact 314-path plan. Clean evidence carrier
3a38154e also passes the canonical two-build rehearsal: both reverified
264-file bundles are byte-identical, with a retained archive size of
11,948,788 bytes and SHA-256
46b20d1eecaf6ab665c17816db42e937e9cb50c88a8dc4340beda4f2e670cf27.
That result replaces the older bundle as local evidence, not as a published or
reusable exact-final-head release artifact.
The later NTU attached-storage increment expands the current plan to 317 paths,
adds a shared read-only resolver and the formerly omitted documented NTU helper
to the curated bundle, and reports the exact 49,209,878,965-byte requirement
and root shortfall before any mount, write, or download. Its own exact-head
validation carrier b01b251 passes 2,517 maintained Python tests and a
byte-identical, twice-reverified 267-file bundle rehearsal: 11,959,011 bytes,
SHA-256
f963391bf76f67e27828bf0c8eadada484ac8b8b9481e5f904fcec72e1c64bad.
That evidence is regenerated rather than inferred from the earlier RTK carrier
and grants no mount or publication authority.
The latest local slice also binds the rendered Getting Started bytes, route fragments, product version, and Pages workflow to one exact source revision. Its read-only audit keeps the independent cohort closed while the deployed manifest is absent or stale; a plausible URL alone is no longer launch evidence.
The release-mode observer packet now derives the release commit and both ROS
distribution image digests from one schema-valid published-release audit
rather than four manually typed values. Its generated Docker preflight repeats
the live tag-commit and digest comparison. This contract is locally validated
at exact tip 289f7675a242b00f342528483cde3e5f602a11fc. The v0.9.0 identity passes that
check but lacks the source quickstart contract, while v0.9.1 remains
unpublished, so neither state creates a comparable same-version row.
After G0, the next priority is the independent first-map cohort. It is both the remaining v1 evidence and the fastest honest way to discover whether the project is genuinely easier for a new user than its alternatives.
The public tracking issue does not bypass that sequence. The live contributor
card binds #422 to the cohort evaluator and keeps it out of the recommended
starter set until the state is exactly READY_FOR_NEXT_ATTEMPT. In the current
WAITING_FOR_PUBLIC_GATES state, the next work is comparable Docker/source
evidence plus canonical public-documentation provenance and immutable runtime
identity—not recruiting a user into stale deployed instructions. The checked
JSON card is a no-write decision aid; issue edits, Pages deployment, and
community outreach remain separate authority gates.
11. Long-term operating cadence
The roadmap is operated as a recurring system, not a one-time launch list. Each review ends with one explicit constraint, one owner, one evidence artifact, and one next review date.
| Cadence | Required review | Durable output |
|---|---|---|
| Weekly | capture aggregate growth; label or disposition new issues; inspect support load and blocked reviews | one privacy-bounded growth snapshot and a short decision annotation |
| Every two weeks | inspect one clean first-map attempt or onboarding finding; review the ready contributor queue | one accepted result, one repaired blocker, or one explicit no-change decision |
| Monthly | update the Star forecast, release age, v1 gate, external contribution count, and “what became easier” summary | one compact public progress note after the underlying evidence is public |
| Every six weeks | select the largest measured discovery-to-first-map-to-contribution constraint | one bounded experiment with success and stop criteria |
| Quarterly | rerun supported clean-install/upgrade checks; audit claims, dependencies, licenses, stale issues, and maintainer load | one health review with the next quarter's WIP allocation |
| At 1,000 Stars | start the 90-day sustain audit instead of opening a larger feature campaign | G4 health report followed by the G5 ownership review |
Capacity and WIP policy
Normal maintainer capacity remains approximately 60% product and reliability, 20% distribution and community, and 20% bounded research. The split is reviewed quarterly, but the following limits do not change merely because capacity rises:
- at most one product/release slice, one community slice, and one exploratory research slice may be active at once;
- at most two starter contributions may wait for substantive maintainer review;
- a supported-product P0, a failed release gate, or a growing support queue takes capacity from research first;
- promotional work stops when onboarding or review capacity is failing;
- no stable release may depend on a private bag, unpublished image, local-only revision, or maintainer-memory-only procedure.
The project reduces scope before reducing evidence. A smaller maintained sensor matrix, fewer simultaneous experiments, or a later date is preferable to an unreviewable release and a stalled contributor queue.
12. Star runway and checkpoint budget
The baseline has 163 Stars remaining. These scenarios are forecasts, not quotas and not permission to manufacture engagement.
| Scenario | Net pace | Approximate crossing date | Operating response |
|---|---|---|---|
| Recent organic pace | 11.8 per month | October–November 2027 | keep quality work; improve qualified distribution only after activation passes |
| Base plan | 15.2 per month | by 2027-06-30 | deliver G0–G3 in order and review the forecast monthly |
| Stretch plan | about 21 per month | by 2027-03-31 | accept only if v1, first-map, contributor, and release gates are already healthy |
The phase checkpoints divide the base-plan delta into visible planning units:
| Phase | Start to checkpoint | Net change | Leading outcome that must improve first |
|---|---|---|---|
| G0 | 837 to 860 | +23 | clean public candidate, comparable onboarding evidence, triaged support surface |
| G1 | 860 to 900 | +40 | v1 audit 10/10 and three independent verified first maps |
| G2 | 900 to 950 | +50 | current stable release, proof-led launch, and recent external contributors |
| G3 | 950 to 1,000 | +50 | maintained recipes, ten cumulative first maps, and durable qualified referrals |
Missing a Star checkpoint does not invalidate a phase whose activation and community outcomes are improving. It triggers a new forecast. Hitting a Star checkpoint does not advance a phase whose quality exit is incomplete.
13. Constraint experiments
Only one experiment in each funnel stage may be promoted at a time. Every experiment needs a pre-intervention baseline, a bounded cost, and a stop rule.
| Funnel stage | First long-term experiment | Success signal | Stop or redirect signal |
|---|---|---|---|
| Discovery | one canonical rosbag2-to-Autoware landing page and proof-led README | qualified Autoware/ROS referrals and release-bundle downloads rise over four weeks | traffic stays flat after indexing and one relevant announcement; revisit positioning rather than duplicate pages |
| Activation | published 50-second fixture beside the unchanged full proof route | comparable first-map trials improve active time and completion without weakening verification | users still fail before execution or fixture/public-source identity is not reproducible |
| Trust | public UX and benchmark scorecard with exact revisions and limitations | external first-map reports and evidence-linked citations increase | claims need private context or scorecard rows cannot be independently reproduced |
| Contribution | five bounded starter tasks and a focused-check contributor path | at least three non-maintainer completions with median prepared-environment time at most 30 minutes | two consecutive tasks exceed 45 minutes because of setup or review bottlenecks |
| Referral | one short English demo, one Japanese companion, and consented case studies | qualified referrals, validations, and Stars rise together | views rise while receipts and useful reports stay flat; stop promotion and repair activation |
An experiment is not repeated merely because a social post underperformed. Repeat only after the underlying product, audience, or distribution condition has materially changed.
14. Risk register and post-milestone ownership
| Risk | Early signal | Mitigation and owner outcome |
|---|---|---|
| Local-only source or fixture blocks reproducibility | a trial cannot name a public immutable revision or checksum | keep G0 closed; obtain separate source and artifact publication decisions |
| Maintainer concentration | releases, reviews, and support stop when one person is unavailable | by G5, transfer one bounded review area and rehearse two checklist-driven release cycles |
| Old support backlog hides current product defects | unlabeled or unanswered supported-path issues remain open | complete reasoned triage, convert reusable answers to docs, and track response aggregates weekly |
| External rosdistro timing slips | package-manager gate remains unchanged across reviews | continue source/Docker activation work; never pretend source proof is binary-package proof |
| Promotion outruns support | traffic rises while receipts, response time, or review throughput worsen | pause announcements and fix diagnosis, docs, or maintainer capacity |
| Research consumes the release path | an exploratory candidate becomes a prerequisite for onboarding | enforce the 20% budget and remove failed routes from the product critical path |
| Unsupported claims damage trust | a comparison omits versions, limits, or reproducible evidence | fail the release/communication review and publish a correction before further promotion |
| Privacy-bearing evidence leaks | a proposed receipt contains maps, paths, identities, or exact locations | reject the artifact and retain only the reviewed aggregate or privacy-bounded receipt |
After 1,000 Stars, growth work changes from acquisition to retention and ownership. G4 proves that activation, release freshness, response load, and contribution do not regress for 90 days. G5 then proves that two release cycles and at least one review domain can operate from public artifacts and written contracts without relying on one maintainer's private state. Only after those audits should the project consider a broader sensor matrix, a larger governance surface, or a new headline research claim.
The 2026–2029 operating plan continues this policy through G6–G9: versioned compatibility, evidence-backed ecosystem depth, release/triage resilience, and a 2029 strategic renewal decision. Its quarterly template turns the horizon into a recurring evidence and ownership review.
15. Baseline reproduction
The 2026-08-10 snapshot was taken from the authenticated GitHub REST API and the local readiness audit. Maintainers can refresh the same aggregate sources without collecting private product telemetry:
python3 scripts/collect_growth_snapshot.py \
--output docs/evidence/growth/$(date -u +%F).json
gh api repos/rsasaki0109/lidar_slam_ros2
gh api repos/rsasaki0109/lidar_slam_ros2/traffic/views
gh api repos/rsasaki0109/lidar_slam_ros2/traffic/clones
gh api repos/rsasaki0109/lidar_slam_ros2/traffic/popular/referrers
gh api 'repos/rsasaki0109/lidar_slam_ros2/releases?per_page=20'
python3 scripts/check_v1_readiness.py --json
Repository and pull-request aggregates were cross-checked against
origin/develop and the GitHub pulls endpoint. The collector now encodes the
weekly aggregation, privacy boundary, and JSON schema; the individual endpoint
commands remain only as a maintainer audit aid.