Needs you

Records waiting for your review and open questions. What the agent wrote comes first, then the oldest.

Nothing matches the filter.

• booping:rule/0001A lesson is a ruleacceptednot acceptedWhat a run teaches is recorded as a rule with targets and a brief; only the brief reaches the targeted step, the body is read on demand.
• booping:rule/0004Open questions are settled in grooming, not in developacceptednot acceptedGrooming hunts for open questions and settles them with the user before ready-for-dev; develop stops only for force majeure.
• booping:rule/0006Every prompt artefact passes the information-architecture checkacceptednot acceptedBefore a prompt-bearing artefact is saved, every block passes four checks — scoping, duplication, configurability, hierarchy — and prose that only restates or motivates is cut.
• booping:rule/0007References a plan invalidates are cleaned up in the same sprintacceptednot acceptedWhen a plan deletes or renames something others reference, the cleanup is a milestone task of the same sprint with its own DoD, never a follow-up sweep.
• booping:rule/0008Generated content is scoped to its audienceacceptednot acceptedUser-facing output — release notes, user docs, changelogs — includes only what that audience touches; the audience filter is specced into the task's DoD.
• booping:rule/0009An agent briefing bounds what the agent returnsacceptednot acceptedEvery agent briefing states the exact shape of the agent's reply, limited to what the orchestrator needs; groom bounds it in the task so develop's briefings inherit it.
• booping:rule/0010The content of a user-facing output is locked in groomingacceptednot acceptedWhen a plan defines a user-facing output or log format, its exact content — fields, truncation, trailers — is settled with the user in grooming, not iterated in develop.
• booping:rule/0030Planning shows the values in play and every departure from themacceptednot acceptedA plan names the values that drive its choices and flags where it departs from a value or rule, so the user sees what works and can refine the values.
• booping:rule/0031Corrections are logged as they happenacceptednot acceptedWhen the user corrects the driver, it logs the correction verbatim as a file under the vault's corrections/, so retro starts from a ready list of what is not yet handled.
• booping:rule/0032Decisions are asked in proseacceptednot acceptedAn approval, or any decision the user must understand the context to make, is asked in prose, one at a time with compact context and a counter; a multiple-choice tool only for mechanical picks.
• booping:rule/0033Decisions are listed for acceptanceacceptednot acceptedBefore the user accepts anything, the agent lists every decision it takes as settled, one numbered line each, marking its own proposals; an unanswered item is never accepted.
• booping:rule/0034A specs review tests each record against its typeacceptednot acceptedA review of the specs puts every record to the type tests of the format guide and lists each failure — the type it fits or deletion — for the user to accept.
• booping:rule/0035Items of one class are groomed together, never in parallelacceptednot acceptedThe manager grooms items of the same class in one plan, or one after another with the earlier plan in the next brief — never in parallel, where each builds its own copy of the mechanism.
• booping:rule/0036An ADR is accepted after a briefacceptednot acceptedAn ADR is drafted proposed and accepted only after the owner was shown its brief and given a window to object; the answer sets the review level with its evidence.
• booping:rule/0037Open items hold only what outlives the sessionacceptednot acceptedAn open item is filed only for work for later or a question that waits for the owner; session instructions, gate answers, policies and decisions are never items.
• booping:rule/0038Ids in chat carry their titleacceptednot acceptedEvery id said in chat — an open item, an ADR, a rule, a plan — is followed by its short title; newly filed items are listed one per line with their title.
• booping:rule/0039Experiments run in stagesacceptednot acceptedAn experiment, eval or benchmark matrix runs a cheap screen, then a shortlist, then significance for finalists only, each stage sized before launch.
• booping:rule/0040The ADR scorer judges its prompt aloneacceptednot acceptedThe adr-scorer runs only its body render and judges a draft ADR from the pasted parts alone; nothing it was not shown exists for it.
• adr/0001Specs are a core feature in three tiersaccepted1 question for younot acceptedBooping ships the specs format and its own specs; a global tier in the home dir and a project tier in the repo add their records, cross-tier refs go by namespace.
• adr/0002Procedures are playbooks behind one skillacceptednot acceptedEvery booping procedure ships as a playbook driven by the single /playbook skill; a new skill is written only for a surface /playbook cannot drive.
• adr/0003Bodies render at skill load, with no build stageacceptednot acceptedSkill and agent bodies are rendered from templates at load time with full project context; the generated-file build stage is retired.
• adr/0004Config is a three-tier deep merge with no schema gateaccepted1 question for younot acceptedConfig merges core, global and project tiers, later winning and lists replacing; any key loads in any tier, and playbook keys live in the core file under core.{name}_playbook.
• adr/0006Each playbook owns its state machine; no shared lifecycleacceptednot acceptedEvery artifact moves only through its own playbook's states machine, written solely by playbook-transition; playbooks hand off at a status, not through a shared lifecycle.
• adr/0007Run-state persistence is an authored tier, and confirmation is a statusacceptednot acceptedA playbook's state machine is authored at one of three tiers — ephemeral, minimal, rich — never derived from the graph; a confirmation that must persist is a status transition, not a flag.
• adr/0008Retro and code review are separate tracks joined by plan frontmatteracceptednot acceptedA plan ends at develop's done and never moves again; retro and code review keep their own artifacts and machines and join the plan through retro and code_reviews keys.
• adr/0009A plan is a directory whose index.md is both plan and run artifactacceptednot acceptedA plan lives in plans/{slug}/; index.md is the plan document and the machine's artifact at once, and run sidecars sit beside it — no separate plan.md and no _runs/ workdir.
• adr/0010A milestone is a file handed to the worker by pathacceptednot acceptedEach milestone is its own file in its own directory with status and feedback beside it; develop hands a worker that file's path, never a slice of the plan body.
• adr/0011A step is inline, assisted or detached, set by one detached fieldacceptednot acceptedThe runner performs most steps itself; heavy reads go to a configured researcher that is resumed, not respawned; only a step that must not enter the runner's context is detached.
• adr/0014External agents and surfaces wire in through config; core names no external toolacceptednot acceptedAn external worker or review surface is a plain agent registered in config and steered by a targeted rule; core ships no wrapper for it and no playbook names it.
• adr/0015A playbook run stops for review at one gateacceptednot acceptedCore playbooks take user decisions in-step and stop for approval once — groom at present, retro at synthesize, migrate before applying, develop only to confirm the branch.
• adr/0016Groom's cross-review is a detached step gated by one config keysupersedednot acceptedA second model reviews the drafted plan once, in its own detached step, only when core.groom_playbook.cross_review_agent names an agent; null skips the step.
• adr/0017Vault migrations ship with the plugin, keyed by a frontmatter idacceptednot acceptedMigrations live in the plugin's migrations/ directory; the id in migration.md frontmatter is the only authority, and the .booping marker's latest_migration is the applied watermark.
• adr/0018Migrations apply strictly in sequence, one commit each, after one gateacceptednot acceptedMigrate asks once over the whole pending set, then applies each migration in id order through a fresh sub-agent, advancing the watermark and committing before the next; a failure stops the run.
• adr/0019The task tracker is a best-effort mirror of the vaultacceptednot acceptedThe vault stays authoritative; tracker hooks run in a separate CLI, absorb the tracker's failures with a warning, and booping-tracker sync reconciles by hand.
• adr/0020CLI behaviour is tested by a contract corpus, not by internal unit testsacceptednot acceptedEach CLI subcommand is specified by language-neutral cases run through bin/booping; unit tests cover only algorithmic hotspots, and prose is owned by snapshots and mdcheck.
• adr/0021Prompt behaviour is checked by per-step eval suites, advisory and outside CIacceptednot acceptedEach playbook step can carry a promptfoo suite with a deterministic smoke tier and a judged regress tier; runs are proposed, not launched by steps, and post an advisory PR comment.
• adr/0022Develop groups milestones per worker by story points, not by countacceptednot acceptedDevelop packs milestones per worker greedily within one wave under a max_sp cap of 15 instead of max_milestones_per_agent, and sp ≥ 5 is a hard groom gate.
• adr/0024The specs playbook is a guide, not a menu of actionsacceptednot acceptedOne specs playbook explains every record type and principle plus the user's typical scenarios, and the model works out from the dialogue what to do.
• adr/0025Open items are a stored index; closed ones are filtered outacceptednot acceptedEvery gap between specs and code, open question or conflict is an open item stored in the vault and listed by an explicit command; closed items stay and are filtered.
• adr/0026Corrections are logged where they happenacceptednot acceptedEach time the user corrects the model in groom, develop or code-review, a short entry with a link back to the dialogue goes into the run's corrections sidecar — the feed retro and learn read.
• adr/0029Each project publishes its specs site on GitLab Pages, under one indexacceptednot acceptedA project whose vault is in its repo builds its specs site in CI to Pages; an index at the group's Pages root lists them, rebuilt on a schedule from the projects that carry a topic.
• adr/0030Groom drafts the whole plan in one staged passacceptednot acceptedGroom is the plan template plus research then draft (V3a), no self-review step, without the 16 rules the model follows unprompted; the draft is one file.
• adr/0031A script cuts the drafted plan into milestone filesacceptednot acceptedThe script `booping plan split` cuts the one-file plan on its milestone headings, byte for byte, into index.md and the milestone files; a model splits only what the script flags.
• adr/0032The owner reviews specs on the site and hands the review to an agentacceptednot acceptedA review panel beside each record collects comments and a reviewed mark in the browser; an Outbox page shows and copies everything for the agent, which edits the records.
• adr/0033Playbooks consult the specs through a subagentsupersedednot acceptedA read-only subagent tells playbooks what the specs already decide, contradict or leave open.
• adr/0034Every playbook carries a base guidance on the specsacceptednot acceptedEvery playbook knows what the specs are, the values, and that it reads and writes them through a subagent, applying them where they raise quality; no per-playbook scenarios.
• adr/0035Groom has no separate review stepacceptednot acceptedA fresh Opus review lifts plan quality but adds about 10 minutes a plan (4–5 at best); the one-pass draft already meets the goal, so groom has no review step.
• adr/0036Autonomy is settled in proseacceptednot acceptedA run is autonomous because the user or its launch prompt says so, not because a config key does; there is no core.autonomy.
• adr/0037Journal entries are vault files built from existing primitivesacceptednot acceptedA correction or an agent decision is one vault file with frontmatter, made by create, moved by frontmatter-update and sliced by query; an item's question is its clarify status; no journal command.
• adr/0038Milestone shape is an mdcheck schemaacceptednot acceptedGroom checks each milestone file with mdcheck against a schema in the groom playbook; `booping plan check` and its code go, and mdcheck becomes a required dependency.
• adr/0041The ADR scorer reads the specs guide and the tier's record inventoryaccepted1 question for youThe adr-scorer gets the specs guide excerpt, the tier's value/rule/ADR inventory and the project's primitives, on Opus without tools, and answers route, overlaps, alt_score and missing.
• conflict/0001Plans run to the end ↔ Adjustable controlresolvednot acceptedAn agent that carries a plan to the end on its own pulls against a human who can review deeply and take control back; the run's autonomy mode settles which applies.
• conflict/0002Effective human review ↔ Plans run to the end ↔ Quality at a rational costresolvednot acceptedMore review checkpoints make review effective but cost run time and stops; core playbooks stop for review once, and groom runs no separate review step.
• idea/0001Groom offers past plans and retros as context before planningopen1 question for younot acceptedBefore planning, groom has a cheap researcher list past plans and retros related to the request, and reads the ones the user picks in depth.
• idea/0002Learn prefers guidance to validatorsopen1 question for younot acceptedLearn should propose guidance that steers a step away from an issue, and propose a validator or sub-agent check only for critical cases.
• idea/0003A faster groom without losing qualityacceptednot acceptedTry several groom playbook variants and keep the one that runs faster with no loss in plan quality.
• idea/0004Trim template fields that do not helpopen1 question for younot acceptedDrop the business-goal logic from grooming and replace the retro action table's Owner column with "when to do it".
• idea/0005Booping as a web service with thin skillsopen1 question for younot acceptedA web service owns playbook management, artefacts and execution; skills become thin clients, a tracker such as Linear is a driver, and a sandbox runs the workers.
• idea/0006Merged OSS PRs as benchmark tasksopen1 question for younot acceptedRe-create small merged PRs from OSS repos as booping plans and score groom and develop by the repo's own tests.
• idea/0007Claude wires a worker agent into booping on requestopen1 question for younot acceptedThe user asks Claude Code to add a native agent or a CLI-backed agent to a playbook, and Claude writes the agent, the config entry and the targeted rule.
• idea/0008Plans draft ADRs for their real forksopen1 question for younot acceptedWhere a plan meets a real design fork, groom writes an ADR draft with the alternatives and its choice, and offers it to the owner for review unless the run is autonomous.
• idea/0009Groom depth scales with the taskopennot acceptedA small, already-decided request takes a light path to develop instead of a full groom, and groom runs its deeper work only when the task or the user asks for it.
• reference/0001Audiencelivenot acceptedBooping is read by three roles — users, advanced users and contributors — each coming for different things at a different depth, in a different voice.
• reference/0002Glossarylivenot acceptedThe canonical names for booping's concepts — one term per concept, never a synonym, used across records, docs and step bodies.
• reference/0003Documentation surfaceslivenot acceptedBooping's markdown documentation surfaces, each with its audience and the depth ceiling past which content belongs elsewhere; executed or generated markdown is not a surface.
• reference/0004Develop model comparison, April 2026livenot acceptedOne develop diff each from Claude Opus 4.7, Minimax 2.7 and GLM 5.1 scored 9.7, 7.2 and 6.4 of 10; only Opus produced a correct, plan-compliant diff.
• reference/0005Bench finding — develop follows the plan's code sketch over a lessonlivenot acceptedIn claude-booping-bench, /develop copied the casing of the plan's code sketch instead of a loaded naming lesson in 3 of 3 reps (judgment 0.2).
• reference/0006Groom cost — playbook versus the old skilllive1 question for younot acceptedOn one measured request the playbook groom took 2.4× the wall time, 5.2× the main-thread API calls and 3.0× the output tokens of the old /groom skill.
• reference/0007Groom benchmark 2026-10 — variants, rule ablation, plan splitlivenot acceptedWhat the October 2026 groom benchmark measured, what the model does without being told, what it cost and where the data lives.
• reference/0008Postmortem: the budget gate slipped into the core unaskedlivenot acceptedOn 2026-10-15 a usage-limit gate the owner never asked for reached the core through a one-line mention, a package approval and autonomous runs; removed on 2026-10-17.
• reference/0009Prose or code probes 2026-10livenot acceptedThree cheap probes on 2026-10-18 — which rule wording makes a fresh model pick prose, an existing primitive or a new CLI correctly, and how sibling items should be groomed.
• reference/0010Postmortem: mechanisms built without a readerlivenot acceptedBetween 2026-10-15 and 2026-10-18 booping grew a config key and three journal CLIs that nothing needed; removed on 2026-10-18, with the rule wording and the ADR guide that let them in.
• reference/0011Postmortem: CLI commands removed under live runslive1 question for younot acceptedOn 2026-10-17/18 booping removed the budget, correction and defaults commands while autonomous runs in another project still called them, and those runs failed.
• rule/0002What is not in the source is marked, not inventedacceptednot acceptedA record or artefact states only what its source says; an open point is marked [clarify] or "not named in the source", never filled in by the agent.
• rule/0003The compact artefact is reviewed before the detailacceptednot acceptedWhere a human reviews, a run first produces a compact artefact the human can read and reorder, and builds the expensive detail only on the reviewed one.
• rule/0005Every step ends by naming the next oneacceptednot acceptedA playbook step or a run that hands back to the user ends by naming the next step and how to call it; a premature call says what is missing.
• rule/0012Every diff is reviewed in Plannotator, never in chatretirednot acceptedIn this project the code-review human step always runs through the plannotator-reviewer agent; a missing agent or a dead surface stops the run, never falls back to chat.
• rule/0013Snapshot baselines are accepted by the user, never by a runacceptednot acceptedA run never runs just snapshots-accept or writes the committed playbook reports; it leaves the drift uncommitted and names it in its final report for the user to accept.
• rule/0015Code review covers code files onlyacceptednot acceptedA code review surfaces findings on code files only; documentation, plans and other prose in the diff pass unreviewed.
• rule/0017Structured data is rendered from config, never restated in proseacceptednot acceptedStatuses, queues, agent ids, globs and other structured values live in config or query specs and are rendered into bodies; prose never copies a literal.
• rule/0018Project specifics stay out of the coreacceptednot acceptedCore skills and playbooks stay stack-agnostic; whatever is specific to a project is written into that project's tier, never into the core or a user-level scope by a run.
• rule/0019The driver owns the vault and git; workers touch only repo codeacceptednot acceptedThe driver owns the vault, run state and commits; workers edit only repo code, never git history; a small fix goes to the session already holding its context.
• rule/0020Project shaping of an agent or skill is a targeted recordacceptednot acceptedA project adjusts a core agent or skill through a targeted rule (agent:<id>, skill:<name>), never through a separate extension file.
• rule/0022Commits are conventional with a scopeacceptednot acceptedCommit messages follow Conventional Commits with a scope, such as feat(booping) or fix(groom).
• rule/0023The README Statuses section follows the states blocksaccepted1 question for younot acceptedThe README's Statuses section is a hand-kept narrative over each playbook's states block; a change to a states block revisits it in the same change.
• rule/0024A new procedure is a playbook, not a skillacceptednot acceptedAnything procedural is added as a playbook driven by /playbook; a new skill is added only for a surface /playbook cannot drive.
• rule/0025Who reads the result decides prose or codeacceptednot acceptedA command, key or check exists when code reads its result or it supplies a fact the model cannot see; the rest is prose, the default when unsure.
• rule/0026Step bodies are fetched on demand, not pasted into spawn promptsacceptednot acceptedA step's body is fetched when the step runs rather than pasted into a spawn prompt, so a run's context grows with its graph, not with the sum of its step bodies.
• rule/0027A hermetic render repeats byte for byteacceptednot acceptedWith macros stubbed and the config merge pinned to core and project levels, a render is identical on any machine.
• rule/0028Vault artefacts are plain markdown with YAML frontmatteracceptednot acceptedEvery artefact a run writes into the project vault is plain markdown with YAML frontmatter, readable in Obsidian.
• rule/0029Graph and render problems are reported in band, never as crashesacceptednot acceptedA graph or render problem surfaces as a STOP or Note notice in the rendered output at exit 0, never as a crash.
• rule/0030A prompt rule earns its place by a measured missacceptednot acceptedAn instruction enters a prompt or a targeted rule only after a minimal probe shows the model missing it; evals and benchmarks run only when the owner agrees.
• rule/0031Judgement runs on Opus; cheaper models only for routine with a known outputacceptednot acceptedEvery step, agent or fallback that decides — drafts, reviews, verifies a DoD, writes tests — runs on Opus; the researcher on Sonnet high; else only mechanical steps.
• rule/0032The booping CLI holds only generic primitivesacceptednot acceptedA booping CLI command is a primitive any playbook can use; behaviour of one playbook's domain is that playbook's script, run through its hooks.
• rule/0033Private sources stay in vault/notesacceptednot acceptedThis repo is public; another project's data, local paths and raw experiment inputs are written only under the gitignored vault/notes/, and tracked records name them without linking.
• runbook/0001Cut a plugin releaselivenot acceptedA release is a release/X.Y.Z branch bumping plugin.json and CHANGELOG.md, merged by PR into master, then tagged vX.Y.Z with a GitHub release on the merge commit.
• runbook/0002Run the eval suites and read the PR commentlive[unknown]not acceptedEvals run locally on subscription auth via just smoke/regress/eval; results land as one sticky advisory PR comment, never a gate.
• runbook/0003Accept new snapshot and contract baselineslivenot acceptedAfter an intentional change, the user reads the snapshot or txtar drift and accepts it; a run or a worker never accepts a baseline itself.
• story/0001Playbook driverdonenot acceptedThe /playbook skill discovers a procedure across the core, global and project levels and drives it to completion.
• story/0002Run state machinesdonenot acceptedA run's state lives in per-playbook states: machines that only the booping CLI advances.
• story/0003Layered configurationdonenot acceptedConfig is a deep merge over the core, global and project levels, and any mapping in it can be a query spec or a template tree.
• story/0004Targeted rulesdonenot acceptedAn accepted rule's brief is injected into exactly the playbooks, steps, agents or skills its targets: list names.
• story/0005Plan and review templatesdonenot acceptedGroom and code-review offer plan and review templates the user authored in the Project Vault or at the global level.
• story/0006User playbooksdonenot acceptedPlaybooks the user authors at the global level or in the Project Vault are discovered and run beside the core ones.
• story/0007External agentsdonenot acceptedAgents the plugin does not ship are wired into playbook agent slots through config and shaped per project by targeted rules.
• story/0008Template pipelinedonenot acceptedSkill and agent bodies render in one runtime stage from src/templates/ with full project context, reproducibly when pinned.
• story/0009Quality gatesdonenot acceptedjust ci runs lint, typecheck, pytest, snapshots, mdcheck and e2e in order, holding the plugin's behaviour.
• story/0010pytest-txtardonenot acceptedThe e2e corpus's case format and sandboxed runner ship as a standalone pytest plugin on PyPI.
• story/0011Eval suitesdonenot acceptedPromptfoo suites beside each step guard its contract in a deterministic and an llm-rubric tier.
• story/0012Migration shippingdonenot acceptedThe plugin ships Project Vault migrations, and every render surface is gated on a vault's applied watermark.
• story/0013Documentation sitedone1 question for younot acceptedThe public MkDocs reference builds strictly and publishes to gh-pages on push to master.
• story/0014Project setupdonenot acceptedThe setup playbook takes a repo from any state to a working booping project and re-runs without changing what is already set up.
• story/0015Project Vault migrationsdonenot acceptedThe migrate playbook brings an existing Project Vault current with the plugin on one up-front approval, with one commit per migration.
• story/0016Groomdonenot acceptedGroom shapes a feature, bug or refactor into a specified, estimated plan the user approved, ending at ready-for-dev.
• story/0017Developdonenot acceptedDevelop executes a groomed plan one milestone group at a time through a worker agent and closes it at done or fail.
• story/0018Retrodonenot acceptedRetro mines a finished sprint's session logs, diff and the user's feedback into a standalone retrospective.
• story/0019Learndonenot acceptedLearn turns retrospective findings the user confirmed into rule records in the project specs tier or CLAUDE.md entries.
• story/0020Session metricsdonenot acceptedA plan carries measured active minutes, tokens and models computed from Claude Code session logs.
• story/0021Code reviewdonenot acceptedThe code-review playbook reviews a confirmed scope, collects the human verdict and applies only approved fixes.
• story/0022Task trackerdonenot acceptedThe booping-tracker CLI carries every interaction with an issue tracker, and groom mirrors its run status and questions onto the tracker issue.
• story/0023Project managerdonenot acceptedOne manager the user talks to files every request as an item and carries it through groom, develop, review and merge, with a status computed from the vault.
• story/0024Specs review with the ownerdonenot acceptedThe system reviews the owner's specs, fixes what is plainly stale, and brings the owner only the decisions that are theirs, one at a time and kept across restarts.
• story/0025Own integration on top of boopingdonenot acceptedAn advanced user wires their own triggers, schedules, tracker flows and usage guards on top of booping's surfaces; the core ships none of them.
• story/0026Specs first, then codedonenot acceptedA decision made in the specs becomes tracked work the code follows, closed with its plan; code that ran ahead of the specs becomes work for the specs.
• value/0001Curated self-learningnot acceptedThe system gets better from its own runs, but only through the user and when the user wants it: a lesson becomes a rule after the user takes it, not after every run.
• value/0002Minimal effective contextnot acceptedA step gets only what it needs.
• value/0003Single sourcenot acceptedEach fact, decision and piece of structured data lives in one place and is referenced or rendered from there; a decision is kept together with its reason.
• value/0004Analysable historynot acceptedPlans, runs and their outcomes are kept across every project, so the history can be analysed: practices taken over from one project to another, benchmarks, quality comparison, problem analysis.
• value/0005Stack-agnostic core1 question for younot acceptedThe core knows nothing about a stack or a project; specifics live in the global and the project tiers.
• value/0006A framework for playbooksnot acceptedBooping is a framework a user digitises their own processes with — config, templates, primitives, the CLI, playbooks and evals for their steps.
• value/0007Plans run to the endnot acceptedThe agent carries a plan through to the end on its own unless force majeure stops it.
• value/0008Effective human reviewnot acceptedEvery step where a human takes part is convenient and effective for that human.
• value/0009Adjustable controlnot acceptedThe human can review the system deeply, or give the agent more freedom to act inside the values and boundaries.
• value/0010Proven to worknot acceptedWe know the system works as it should and can guarantee it high enough to call it reliable.
• value/0011Everything in one placenot acceptedEverything is plain files, easy to look at from one place — for example Obsidian; symlinks back to the project repos keep it together.
• value/0012Quality at a rational costnot acceptedBooping is a work tool for professionals, so the quality of the result matters.
• value/0013Guides to the goalnot acceptedThe system is clear to the user and leads them to the goal by the hand, while letting a professional step aside and get there their own way.
• value/0014Comfort for non-technical usersnot acceptedHow comfortable booping is for people without a strong technical background is not optimised for; they are not its audience.
• value/0015Deterministic where code reads itnot acceptedWhat code reads, and every fact outside the model's view, is produced by code; what only a model or a human reads stays prose with a fixed format until code starts to read it.
• value/0016Specs live with the worknot acceptedSpecs are updated as the work happens and applied wherever they raise the quality of a result; they never go stale or depend on the user remembering them.
• value/0017Launching and guarding runs is userlandnot acceptedWhen and how development runs start — triggers, schedules, tracker and messenger integrations — and guarding usage limits are the user's, not booping's; booping offers an integration surface at most.
• value/0018A core set for development and self-learningnot acceptedOn top of the framework booping ships core playbooks for development, self-learning among them; they are its dogfooding, built only from mechanics a user playbook gets too.
• value/0019Projects are built along a roadmapnot acceptedWork decomposes into plans and sprints, so a project is written along its roadmap, sprint by sprint, with a manager carrying the work through.