forked from
anil.recoil.org/monopam
Monorepo management for opam overlays
Wire.bool→Wire.bit rename; cfdp/ltp adopt wire; dune fmt
- CCSDS packages (aos, clcw, fsr, sdls, space-packet, tc, tm, uslp):
Wire.bool renamed to Wire.bit upstream; mechanical migration.
- ocaml-cfdp: adopt wire library for PDU header codec.
- ocaml-ltp: adopt wire library for segment header codec.
- ocaml-cop1: simplify interop test error formatting.
- dune fmt: reformat irmin, pus, scitt, crypto, tc/uslp 3D specs.
- monopam: add TODO.md tracking cram coverage gaps.
+104
+104
TODO.md
+104
TODO.md
···
1
+
# Monopam TODO
2
+
3
+
Active work only. Completed items move out of this file and into the git
4
+
history. Guiding principle: **no surprise.** Every `--help`, every error
5
+
hint, every generated file should describe the tool as shipped.
6
+
7
+
## Pending
8
+
9
+
### Cram coverage gaps
10
+
11
+
Happy-path coverage is missing for six commands. `push` has the most
12
+
extensive test fixture; its inverse `pull` has zero positive coverage,
13
+
and that kind of asymmetry is exactly where bidirectional bugs hide.
14
+
15
+
- [ ] **`init.t`** — fresh directory, run `monopam init --handle ...`,
16
+
verify: the resolved root is printed, CLAUDE.md is generated and
17
+
contains no `monopam sync`, dune-project and root.opam are
18
+
regenerated, the ✓ success line with `Next:` hint is present.
19
+
20
+
- [ ] **`status.t`** — workspace with one synced subtree, run
21
+
`monopam status`, verify the actionable table renders and the
22
+
summary line reports 1 total / 1 synced / 0 dirty.
23
+
24
+
- [ ] **`pull.t`** — round-trip of `push.t`. Add an upstream with
25
+
commit A to the monorepo, then create commit B directly in the
26
+
upstream, then `monopam pull`, verify the monorepo tree now
27
+
contains B's changes and the ✓/`Next:` output is present.
28
+
29
+
- [ ] **`diff.t`** — two assertions on the same workspace: (a) mono has
30
+
a new local commit → `monopam diff` lists it as outgoing;
31
+
(b) upstream has a new commit → `monopam diff --incoming` lists
32
+
it. Exercises the bidirectional sync reader.
33
+
34
+
- [ ] **`remove.t`** — add then remove a subtree, verify the subtree
35
+
directory is gone, sources.toml no longer has the entry, and
36
+
`--dry-run` previews the same operation without touching disk.
37
+
38
+
- [ ] **`clean.t`** — smoke test: create a monorepo with an empty
39
+
commit (no tree change), run `monopam clean --dry-run`, verify
40
+
it reports the empty commit as prunable without touching the
41
+
repo.
42
+
43
+
### Workflow not yet supported
44
+
45
+
- [ ] **Multiple local (partial) monorepos sharing one upstream
46
+
monorepo.** Two flavors of the same workflow:
47
+
48
+
*Cross-developer.* Alice and Bob each clone a subset of the
49
+
same upstream monorepo, work on disjoint or overlapping
50
+
subtrees, and push back. The upstream is the merge point.
51
+
52
+
*Single-developer, multiple apps.* One developer has a global
53
+
monorepo hosting shared libraries plus N product apps on the
54
+
same machine, each its own partial monorepo. The apps all
55
+
consume libraries from the global monorepo, and a fix in a
56
+
library should flow up to the global monorepo and back down to
57
+
every app that uses it. Today there is no story for this beyond
58
+
"edit in the global monorepo and pull from every app
59
+
individually".
60
+
61
+
Both flavors need:
62
+
1. A way for `monopam add` to take an upstream monorepo URL
63
+
plus a list of subtrees to materialize locally (partial
64
+
view).
65
+
2. `pull` / `push` that only touch the materialized subtrees,
66
+
never the absent ones, so the upstream's unrelated content
67
+
is preserved as-is on the local side.
68
+
3. Tree-containment checks on push so one local monorepo
69
+
doesn't clobber another's work.
70
+
4. A cram fixture with three git repos (upstream + two partial
71
+
locals) exercising the full "alice pushes A, bob pulls, bob
72
+
pushes B, alice pulls" cycle, and a second fixture with one
73
+
global monorepo + two apps that both depend on a shared
74
+
library.
75
+
76
+
- [ ] **Nested monorepos (`mono = true`) end-to-end coverage.** The
77
+
README describes closed-source + open-source layering: a
78
+
private outer monorepo contains an open inner monorepo as a
79
+
`mono = true` subtree, plus private-only subtrees at the outer
80
+
level. `push` should recurse depth-first (inner first, then
81
+
outer); `pull` should follow the same order. Each layer has
82
+
its own opam-repo overlay — public metadata for the open
83
+
layer, private for the outer. Needs:
84
+
1. A cram fixture with three git repos: open-upstream,
85
+
open-mono (includes open-upstream as a normal subtree),
86
+
product (includes open-mono as `mono = true` plus a
87
+
private subtree).
88
+
2. Assertions that editing in `product/open-mono/<pkg>/`
89
+
pushes depth-first — first to the open-mono remote, then
90
+
to the product remote — and pulling the reverse.
91
+
3. Assertions that the product opam-repo references the open
92
+
opam-repo as a base without duplicating its entries.
93
+
4. Negative case: pushing a private subtree from the product
94
+
layer must not leak to the open-mono layer.
95
+
This is the distinctive layering story from the README and
96
+
has no cram coverage at all today.
97
+
98
+
### Deferred
99
+
100
+
- **Verse collaboration cram tests** (`verse pull`, `verse diff`,
101
+
`verse fork`, `verse cherry-pick`, `verse members`, `verse status`).
102
+
Needs a two-workspace fixture — one collaborator plus one local —
103
+
and a shared registry. Worth doing but should land as its own pass
104
+
with a dedicated helper for the two-party setup.