moooon
Motir
Vibe the project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.
- Vibe Project
- Open Source
- AI Agent
- AI Loop
- 5
- solicitações
- 4
- votos
- 472
- planejadas
- 4.448
- entregues
- PLANNING BUG — a decision REJECTED "run it and go negative", then placed the refusal on the DISPATCH path, which is not the path that spends the money
- PLANNING BUG — a DECISION work item promised its implementers "no further questions" while one of its own answers ("what the user sees") had no owning subtask, and its single implementing card was sized before the entitlement it would have to store
- PLANNING BUG — Story 1775 decided repo OWNERSHIP by "what the user HAS", committing the product to an `Administration: write` App escalation nobody priced (and leaving hosted-agent write access unplanned)
- PLANNING BUG — MOTIR-1867 premised on a read path that was never planned: the substrate STORES the hostname the approval screen needs and exposes no way to read it. The design's own Planning flag 1 warned of exactly this and was read as discharged
- The starter template ships CI that NEVER RUNS THE UNIT TESTS — `vitest` is a script with no job, so every project Motir creates inherits an unverified unit layer
- Roadmap auto-drill never fires on an ONBOARDED project — the planning-origin cluster makes every root level two nodes
- Planning bug — MOTIR-669 carried `type: deploy` / `executor: human` while its own body said "One PR + the publish itself"; no gate in the per-card checklist ever checks type against the card's OWN deliverables
- Planning bug — MOTIR-1755 was authored on an unverified TENANT state, and the MCP gives the planner no way to verify one
- Planning bug — the repo step was never planned for any project, because 9.3 modelled hosted/BYOK as project LANES instead of per-item execution
- (motir-core) `main` is RED — MOTIR-1920's `fleetConfig` test pins `classifyRunner` to `unknown`, but MOTIR-1923 had already shipped the `motir_fleet` rule; every open PR inherits the failure
- The Vitest COVERAGE gate under-reports cliDeviceService.ts in the merged full-suite run (87.8%) while its own suite covers it 96.34% — and it flips pass/fail by TIME OF DAY, not by diff
- MAIN IS STILL RED — MOTIR-1950 and MOTIR-1951 fixed the same time bomb two incompatible ways: the clock is pinned to JULY in `beforeEach`, but `CURRENT_PERIOD` is computed from the REAL clock at module load
- MAIN IS RED AGAIN — two independently-merged fixes for the SAME wall-clock bug (MOTIR-1950 + MOTIR-1951) compose into it: a module-level CURRENT_PERIOD is evaluated before beforeEach pins the clock
- The acceptance-video LANE still runs on every PR — MOTIR-1937 scoped only the publish; scope the lane itself to the PR that owns the spec
- (motir-core) `main` is RED — MOTIR-1950 and MOTIR-1951 fixed the same CI time bomb two different ways; both merged, and the combination re-breaks it (a semantic merge conflict two green PRs could not catch)
- (motir-core) CI time bomb — ciAllowanceService's dispatch-gate tests meter into a hardcoded JULY 2026 period while the gate reads `new Date()`, so they broke for EVERY PR on 1 Aug (and 5 of the 6 now pass vacuously)
- MAIN IS RED — the zero-balance refusal test is WALL-CLOCK dependent: it meters into a hardcoded JULY_2026 while the gate reads the CURRENT period, so it turned red at 2026-08-01T00:00 UTC
- PLANNING BUG — a boundary-contract PAIR was authored against the ADR's own §5.2 (name, not role), so the consumer half shipped the WRONG field and the producer would have 422'd every fresh-project approve
- PLANNING BUG — the CI-cost model was priced, metered and ENFORCED against GitHub-hosted runners without ever asking who owns the compute, so the compute itself was an unowned deliverable
- PLANNING BUG — Story 1775 planned "ONE repo per project", contradicting a recorded decision AND the product's own planner rules; the multi-repo dispatch consequence was left unowned. Second occurrence of the collapse-to-one-repo class