Hewbers / Features & roadmap

What's running. What's next.

Original Goobers workflows now run natively in Hew with controlled services and real local Git. Explore the working paths, their limits and the remaining work towards end-to-end Goobers parity.

01 / Supported profiles

What each profile supports.

Native local runs use controlled model and provider services with real Git. Implementation and merge review each run in their own selected local profile, not together in one instance. Installed, remote and broader profiles retain their own limits. None is a supported release yet.

Working paths, implemented support and remaining coverage
ProfileImplemented boundaryStill to demonstrate

Authored local

The unchanged DSL 2 starter and original implementation workflow execute natively, including configured implementers, independent review, repair passes and release. Deterministic configured policy selects one runner for all tasks and pins each run's original choices. The manual-only starter refuses work at its open-PR limit; after the normal provider refresh, the same request can admit one no-work run and release its reservation. Merge review runs in a separate selected local GitHub profile with a PR-specific lease and its original hourly schedule.

Broaden configuration and live-service coverage rather than assuming every authored profile works. Resource-aware kits and parallel graphs remain separate optional profiles.

Authored execution kits

Reviewed source supports checkout and installed authored delivery, verified package identity and an explicit resource-aware profile. The full original inventory governs advisory or mandatory ceilings; the owner checks results, gates and recovery.

Run native installed and checkout scenarios. Coding packages, credentials, agentic/reviewer work, parallel graphs and remote/image/cluster kits remain unsupported. Declared resources are not measured capacity or operating-system enforcement.

Local parallel workflows

Bounded flat graph cases execute natively. Read-only branches use distinct committed workspaces and join only on complete success. Artifacts retain branch identity; root repasses remain bounded.

No writable merge, nested or branch gates, general retries, kit/quantity/remote combinations or worktree retirement. Unknown interrupted execution is quarantined. Recovery does not automatically rerun completed work.

Offline workflow migration

Migration and scalar suites pass after the YAML mapping repair. Optional commands review one 1.4-to-2.0 or 2.0-to-3.0 change and publish only to a new file. DSL 2 source also runs unchanged.

Extend installed operator and broader YAML/CLI coverage. New output can change comments and formatting. No arbitrary YAML support, in-place rewrite or automatic multi-version upgrade is claimed.

Installed coding

Native roles build, and installed author, verifier, review, adapter and operator support exists. Installed coding explicitly rejects kit activation.

Run the original starter, implementation and merge-review workflows from an installed package. Controlled local runs do not establish installed operation or live accounts.

Trusted remote scratch

The native worker builds. Literal-command worker, private API/TLS, durable results and independent owner completion/release are connected in source. Off by default.

Clear namespace prerequisites and exercise the complete component chain. Image, real Kubernetes and distributed actor messaging remain separate work.

Service host checks

Full file synchronization, atomic replacement and directory synchronization have host checks, including both packages. Daemon writes no longer invoke whole-host synchronization. Native original workflows also exercise scoped restart and release paths.

Broaden installed operation and filesystem coverage. Historical timeout causes remain separate from current workflow results. No general reliability claim follows.

02 / Features

Coding workflows and the runtime behind them.

These features connect the coding work to the runtime that manages it.

30 of 30 features shown

Hewbers features: purpose, progress and next steps
CapabilityWhat it enablesWhere it stands
Workflow

Issue-to-change workflows

Take approved, ready work through implementation and independent review to a checked pull request.

The original eleven-task workflow runs natively through claim, context, configured implementation, independent review, exact-head push, original local CI, pull request, provider CI and claim release. These are controlled local runs with real Git. Success leaves the issue open and in review for separate merge review.

Next: Exercise live model and provider accounts and installed original workflows. Implementation success does not merge its PR; the separate merge-review workflow has its own review and head, base and CI checks.

Workflow

Scheduled implementation

Check for approved work on the original implementation workflow's twice-daily schedule, without duplicating a busy run.

The original 8:17 a.m. and 8:17 p.m. schedule now runs through serve in host-local time. A native timer and separate provider-readiness actor keep evaluating while work is active, using the same admission transaction and claim owner. Busy, readiness and quota refusals consume that occurrence; completion does not queue a delayed duplicate. Provider CI repair still finishes within the existing worker deadline.

Next: Keep this scoped to the selected original implementation. Merge review has its own hourly schedule in a separate selected local profile, not a demonstrated combined instance. Explicit instance time-zone settings and arbitrary scheduled workflows remain ahead. The init starter stays manual-only; its open-PR limit and provider refresh still apply.

Workflow

Independent code review

Keep the author and reviewer separate, and attach approval to the code that was reviewed.

Reviewer, local CI and provider CI failures now drive actual repair passes on the same PR with distinct heads. An advanced base is merged, independently re-reviewed and repushed before local CI. Provider CI failures go to remediation without approval.

Next: Broaden live-service coverage while preserving revision-specific decisions. Renewed rejection needs human attention; a merge conflict needs remediation.

Workflow

PR review, merge and closeout

Review an eligible PR independently, merge only its approved head and close linked issues.

The unchanged original merge-review workflow owns a PR-specific lease, not an issue claim. Its reviewer receives PR, base and linked-issue context with separate credentials. Fresh approval, head, base, policy, label and CI checks precede exact-head squash merge. Delete the branch only if it still points at the reviewed head. Closeout marks linked issues Done, preserves unrelated labels, closes them and confirms the exact merge comment. Advisory and advisory-overlap paths only comment. A non-passing final verdict cannot authorize a merge.

Next: Broaden fork workspaces and full Tutor generation separately. Moved bases are conservatively refused. Live accounts and installed original workflows remain ahead.

Workflow

Reuse trusted reviews

Avoid repeating an independent review when its trusted result still applies.

Reuse a standing verdict only when its authenticated author, reviewed head and base, current acknowledgement and source run still match. Rebuild the current run's gates and publication authority; a cached pass does not skip scope, election, head or CI checks. Changed pins or acknowledgements, resolved named blockers and malformed comments trigger a fresh review. Unrelated sibling changes do not invalidate a matching verdict. Set --no-verdict-cache on the configured gather-sibling-context command, including daemon startup, to force a fresh review.

Next: Broaden supported profiles and live-provider coverage. General reruns and instruction addenda remain separate work.

Runtime

Reuse sibling file data

Avoid repeated file reads without caching mutable PR state or granting claim, review or merge authority.

In the ordinary native merge-review profile, gather-sibling-context caches selected and eligible sibling file paths and line totals by PR and current head. Every gather refreshes open inventory and live metadata. Provider, API endpoint, owner and repository isolate the memo; closed or absent entries are pruned. Changed heads and missing entries fetch fresh files. On the configured gather command, --no-cache neither reads nor publishes the file memo; --no-verdict-cache independently forces fresh review. Both flags work in either order. Unreadable or invalid memos warn and fetch fresh; memo publication failures only warn. Provider and ownership errors remain errors. Post-merge may read matching-head entries without writing them; deferred preclaim still reads files fresh.

Next: Broaden live-provider coverage. Standing verdicts, completed reports and their readback remain independent of the memo. Goobers cache-file migration and a distributed cache service remain unsupported.

Runtime

Recover stale review comments

Keep fresh review moving without repeating a comment change or accepting a stale verdict.

Mark a cleared managed failure stale on its original review comment. After interruption, settle the original target and exact comment body before checking the head and acknowledgement again. Definite provider failures remain visible; uncertain effects keep their ownership fences. Merge readback selects the newest trusted publication bound to the run before parsing it, so an older malformed comment cannot stall a fresh review. Malformed or superseded current content cannot authorise a merge.

Next: Extend general rerun and comment-driven instruction support separately. A stale marker is not permission to merge or to replay completed model work.

Workflow

Review Tutor changes by their content

Let persona and automated gate-only changes land through review while sending structural, skill and validation changes to people.

The selected original merge-review profile classifies Tutor PRs from the complete file list, immutable content and actual merge base. Persona and automated gate-only changes can follow normal independent review, direct merge or queue admission. Selection, direct merge and queue admission each enforce the policy, including late changes and reused verdicts. Missing or malformed inputs cannot grant permission to land. Typed workflow comparison preserves supported repository aliases and unit-suffixed YAML strings without admitting unsupported migration shapes.

Next: Implement full Tutor generation and holdout execution separately. Fork workspaces and broader original DSL 3 admission remain unsupported.

Workflow

Follow queued merges to closeout

Use the required provider queue and finish an accepted merge without enqueueing it again.

The original merge-review workflow uses GitHub's queue when required, not a direct merge request. Enqueue is tied to the exact reviewed head. Verify the actual merge against a separately authenticated target-branch tip; the PR's recorded base is not its current tip. Accepted enqueue and reconciliation tracking survive a later forbidden read. When access returns, a new counted run completes closeout once, without enqueueing again or rewriting the original run. Carry the merge proof through deferred closeout; refuse branch deletion if the reviewed head moved.

Next: Broaden live-provider and installed coverage. Controlled local cases do not demonstrate full-length provider queue waits or every reconciliation combination.

Workflow

Close PRs no longer needed

Close objectively moot, duplicate or superseded PRs without merging code or granting the model arbitrary closure authority.

An actual independent non-passing managed review can close a PR on four observed grounds: an empty diff; all directed issues already closed; an earlier managed PR sharing a directed issue; or an earlier managed PR with identical paths, statuses and patch text. Passing and advisory reviews cannot authorize this closure. Close the PR, then publish the explanation: no merge, native review, branch deletion or issue closure. Retain an accepted close if the comment later fails. Recovery checks the actual admitted review and complete close/comment history before any mutation.

Next: Broaden live and installed coverage. Objective closure is not the PR-remediation workflow. Fork workspaces and full Tutor generation remain ahead.

Workflow

Review large changes within clear limits

Keep oversized PRs reviewable without treating a missing or stale label as permission to merge.

Scope-gated PRs stay reviewable in the original merge-review profile. File and line gates apply at the configured threshold; drift warns only above its file threshold. Shrinking the change or recording an acknowledgement can release the gate. Both gathered and published gate decisions must allow merging, and the current acknowledgement must still match. A definite label-removal refusal is a warning, not a second veto; a missing label is not approval. Status retains action-specific warnings. Uncertain label or comment changes keep their ownership fences rather than repeating work. Independent review, election, head and CI checks still apply.

Next: Broaden supported profiles and live-provider coverage. Arbitrary DSL 3 original merge-review profiles remain unsupported; acknowledgement handling does not grant new merge authority.

Runtime

Restore the right remediation state

Reassess existing remediation after code or base changes without losing the repair work that remains.

The controller keeps structured cause and generation rules. Head changes can heal a record; eligible base changes use the current repository target-branch tip, not historical PR metadata. Restore needs-remediation before clearing a healed merge-escalated label. Demoted PRs missing that lane regain it unless human or escalation parks intervene. Recheck eligibility before an unconsumed transition; interrupted effects do not repeat and definite failures stay readable. Publication, election and postmerge receive repository-read access only, with no new write, branch-delete or merge grants.

Next: Execute the full PR-remediation workflow and produce new repeat-fail state separately. Healing existing records does not implement those paths. Full original PR-remediation execution has source implementation only; it is not yet running natively or released.

Workflow

Route human PR feedback

Route fresh human feedback back to the same PR without approving or completing a repair.

Use [goobers, pr-comment-watch] in an admitted Workflow task. GitHub and Gitea use the configured token's identity. A human comment newer than the bot's comment adds goobers:needs-remediation to that PR, clears needs-human, merge-escalated or configured human parks, and preserves unrelated labels. Default exclusions skip already-routed, landing, sibling-ordering and opted-out PRs. Configure the base, head prefixes, PR limit, exclusions and result file. Results remain unapproved; status and errors use the owner's normalized result. Settled replay returns the recorded outcome without another mutation or live credential lookup.

Next: This is an explicit task, not an automatic background scanner. Azure DevOps, GitHub App identity support and arbitrary original-daemon workflow admission remain unsupported. Routing does not execute the full PR-remediation workflow.

Workflow

Coordinate overlapping PRs

Choose which overlapping managed PR can merge, without turning review defects into approval or making siblings wait on each other.

The controller applies the original first-in, first-out policy and keeps the raw independent review separate. Even a clean pass needs election. Only an eligible winner can turn ordering-only findings into a passing verdict; substantive defects or no eligible lander retain failure and escalation when the work is still needed. Ordering-only nonwinners park on predecessors using the original goobers:blocked-on-sibling label and comment format. Repository, branch, head, base, membership and exclusions are checked again before publication and merge. Status and trace show the elected PR, overlap group, parked predecessors and accepted unparks.

Next: Extend non-default coordination policies separately. FIFO orders sibling PRs; it does not replace provider merge queues or establish distributed actor execution.

Workflow

Workflows you can author

Describe stages, gates and repository handoffs rather than hard-coding every workflow.

The unchanged Goobers DSL 2 starter and original implementation workflow now load and run through normal service commands. Configured implementers and independent reviewers execute as authored tasks, with bounded repair passes, gates, recorded results and release.

Next: Broaden supported workflows and agent/reviewer kit combinations without assuming arbitrary configuration support. Resource-aware graph and kit execution cannot be combined. Live models and installed original workflows remain separate work.

Runtime

Verified workflow delivery

Deliver the exact workflow and stage inputs without changing who can run the task or accept its result.

Reviewed source supports sequential deterministic kits from a checkout or an explicitly enabled installed authored package. Package identity, original policy and resource declarations stay bound to the run. The existing worker executes checked inputs; the owner verifies results, artifacts, gates and recovery. Native execution remains unproved.

Next: Run the installed and checkout scenarios with genuine programs. Resource shortfalls are advisory for a self-only inventory; any non-self entry makes ceilings mandatory. Coding, credential-bearing, agentic/reviewer, remote and parallel-kit combinations remain unsupported.

Workflow

Parallel branches and repeat passes

Run independent checks together, then continue only with the right branch results.

Bounded flat graph cases now execute natively. The local profile starts two to eight read-only, one-task branches in distinct committed workspaces. Joins require every branch to succeed; results and artifacts retain branch identity. Root-task repasses remain bounded.

Next: Broaden recovery coverage, not the supported graph shape. No writable branch merge, nested graph or general task retry is supported. Unknown interrupted worker execution is quarantined, not automatically resumed. Recovery does not automatically rerun completed work. Read-only checks are not an operating-system sandbox; worktree retirement remains unfinished.

Workflow

Explicit workflow upgrades

Review a workflow version change without overwriting the original or changing a live run.

The YAML mapping failure is repaired, and the migration and scalar suites pass. Offline fix and workflow-check commands keep each upgrade explicit: 1.4 to 2.0, or 2.0 to 3.0, writing only to a new destination. DSL 2 workflows can also load and run unchanged; an upgrade is not required just to execute them.

Next: Extend installed operator and broader YAML/CLI coverage. Passing these cases does not establish arbitrary YAML or configuration support. Output may change comments and formatting; no in-place rewrite or automatic multi-version upgrade is claimed.

Runtime

Runner selection and policy

Send a task to a runner that has the right tools and permissions, without changing its policy midway through a run.

Reviewed source applies configured operating-system, capability and restriction requirements to deterministic authored workflows before work starts. One runner must meet every task's needs. The original workflow, policy and full inventory stay pinned to the run; valid changed configuration can govern new runs after restart without rewriting existing ones.

Next: Broaden native startup, refusal and changed-configuration coverage beyond the original workflows. Configured floors remain qualitative: CPU, memory and disk quantities belong to the separate explicit kit resource profile, not new gaggle minimums. The original configured implementer and reviewer runs do not establish every runner-policy or remote profile.

Runtime

Ownership and recovery

Recover interrupted work without duplicating an external action or taking over another run's task.

Native runs now exercise restart around base updates, retained review decisions, terminal completion and claim release. Each admission keeps its own synchronization evidence, while older result-only history remains readable. A concurrent journal-read race in status is fixed.

Next: Broaden interruption coverage. General failure retries, backoff, salvage and arbitrary mid-command resumption remain unfinished.

Runtime

Recover without repeating a merge

Recover interrupted review and closeout without duplicating a merge, comment or consumed model invocation.

Lost acknowledgements recover the actual merge commit or closeout comment without sending the mutation again. A definite merge refusal finishes failed and releases the PR lease. If a later read is forbidden, an uncertain merge stays uncertain and ownership remains held until it can be checked. Proven completed context or reviewer failures finish failed and release. Recovery does not rerun consumed model work to replace missing or malformed completion output.

Next: Broaden live-provider and installed recovery coverage. Uncertain effects must not become invented refusal, release or permission to repeat work.

Runtime

Resume after a blocker clears

Unpark eligible PRs and request another selection without repeating label changes or forgetting earlier results.

Blocker closure, merge or valid demotion can clear a park. After a merge, publish a displaced sibling's remediation handoff and label before unparking it. Lost label acknowledgements recover the accepted change without repeating it. Restart preserves the completed reconciliation result; a reopened blocker keeps its label. A definite unpark refusal can follow the workflow's continue-on-error path, retaining earlier accepted removals through completion and release. Invalid or contradictory results still refuse. Only a verified managed park requests another selection, with a one-hour deadline and normal readiness, quota, capacity and epoch checks.

Next: Broaden interruption and live-provider coverage without extending the priority deadline or treating uncertain effects as permission to mutate. Full PR-remediation execution and webhooks remain ahead.

Operations

Repository providers

Work with repositories and backlogs through a consistent provider interface.

Gitea and GitHub paths exist. Native controlled-service cases exercise CI polling, pagination and branch publication. Explicit authorization refusal follows authored abort and release; a lost acknowledgement, transport error or malformed creation response remains uncertain.

Next: Exercise live provider accounts and broader credentials. Uncertain creation is not permission to create again. Azure DevOps and general retry/backoff remain ahead.

Operations

Operator visibility and control

Understand a run, stop unsafe work and recover deliberately when it cannot continue.

Normal status and trace commands expose native workflow progress, decisions and release. A concurrent status-read race is fixed. Authored abort and release execute on explicit provider refusal; this does not complete the public control API. Remote views distinguish submission, accepted results, completion and release.

Next: Add durable approvals, reasoned overrides and explicit stage reruns. Authenticate each decision, have the run owner accept it once and reacquire valid claims before continuing. Preserve pauses across restart until a decision arrives. These controls are planned, not delivered by the local workflow results.

Runtime

Portable and remote execution

Move a defined stage to another runner without losing its inputs, limits or result.

The trusted scratch-worker source now connects verified delivery, Job and Pod identity, scoped start, bounded literal commands and durable results. The owner separately checks termination, completion and exact claim release. The native worker builds, but this path stays off by default; remote execution is not established.

Next: Run the full component scenario once namespace prerequisites are available. Check image and real Kubernetes behaviour separately. Remote coding, agentic tasks, distributed actor messaging and broader resources remain future work.

Operations

Scoped credentials

Give each stage only the access it needs, for only as long as it needs it.

Local credential source resolves configured access under expiring, revocable grants. The remote scratch worker now has a separate scoped start-and-result credential in source; it cannot authorize completion or release.

Next: Execute both native handoffs. Provider-side token minting and general remote task credentials remain unfinished.

Workflow

Controlled follow-on work

Continue work, respond to review comments or delegate a smaller task without expanding the original authority.

An experimental command-line path records one bounded successor from a finished local workflow, without starting it. Goobers' continuation command also records admission without executing stages. Dependency admission is connected; delegation and human-comment-driven repair remain unfinished.

Next: After durable human controls, connect human PR comments to a repair brief, same-branch changes and review. Confirm the exact published head before clearing labels or reporting success; retain progress budgets across runs and restart. This path is planned. Comment polling can delay late feedback; immediate capture is not guaranteed. Exercise existing successor admission and recovery natively as a separate check.

Workflow

Workflow history and simulation

Inspect recorded handoffs and explore possible workflow paths without changing a run.

Two experimental command-line tools are implemented in source: recorded-handoff graphs and hypothetical task, gate and retry paths. Native execution and learning remain unfinished.

Next: Run both tools natively, then add measured observations and explanations. Keep hypothetical outcomes separate from recorded history.

Operations

A self-hosted system you can operate

Install the runner, understand its behaviour and upgrade or restore it without losing control of active work.

The runtime is merged into the default branch and native components build. Original workflows execute through the normal service in controlled local runs. Relocatable packaging covers authored and coding profiles, with optional authored kits and offline migration. A supported native release remains ahead.

Next: Prove the installed original workflows, then upgrade, restore and rollback. Broaden live model, MCP and provider credential coverage. Local native success does not establish a complete operated release.

Operations

Service startup and shutdown

Respond to new work and shut down cleanly without losing recorded state or leaving owned processes behind.

Normal service startup, original workflow runs and scoped restart paths execute natively. New runs appear only after their request and initial journal are complete. Interrupted admission reuses the same request and reservation. Daemon writes synchronize the staging file and parent directory around atomic replacement rather than forcing whole-host writeback.

Next: Broaden installed startup, shutdown and filesystem coverage without weakening timing or durability. Scoped local results do not establish general reliability or explain every historical timeout.

03 / The Goobers relationship

Bringing Goobers workflows to Hew.

Goobers is the starting point: a self-hosted platform for coding workflows with defined roles, controlled execution and human handoffs. Hewbers is a parity implementation in progress, written in Hew rather than a wrapper around Go.

Match the workflow

Preserve the contracts people rely on: what a stage receives, what it produces, how review works and who may approve the next action.

Respect execution profiles

Local and engine-backed Goobers workflows do not support exactly the same features. Hewbers must be clear about where each workflow can run.

Build complete workflows

Connect each feature to the work it enables, from a local coding change to follow-on tasks and remote stages.

The original starter, implementation and merge-review workflows now run unchanged in selected local profiles. Implementation hands its PR to a separate review and merge process rather than merging as a side effect of success. Overlapping managed PRs follow controller-selected FIFO order: nonwinners wait on predecessors, and resolved blockers can release the wait. Independent review still decides whether the code has substantive defects. These controlled local paths are concrete steps towards Goobers parity, not the whole product: broader workflow branches, live services and installed operation remain ahead.

Explore the Goobers project ↗

04 / Roadmap

Build on the working workflows.

Original implementation and merge review run in separate selected local profiles. Broader workflow branches, live services, remote tasks and installed operation are the next outcomes to prove.

  1. Running locally

    Run the authored local workflows

    Run original authored workflows through the normal service, with recorded results and claim release.

    The unchanged DSL 2 starter and implementation workflow run natively with controlled services and real Git. Bounded flat graph cases execute too. Broaden configured policy and resource-aware kit coverage separately; unknown graph execution must stay quarantined.

  2. Local suites passing

    Keep workflow upgrades explicit

    Review and publish one supported version change without overwriting an original or rewriting a live run.

    The YAML mapping failure is repaired and migration and scalar suites pass. DSL 2 source runs unchanged. Extend installed operator and broader YAML/CLI coverage without turning a passing local set into a claim about every workflow.

  3. Running locally

    From original workflow to reviewed PR

    Run the original implementation on its twice-daily schedule, taking approved work to a pull request for separate merge review.

    The original eleven-task workflow executes success, review and CI repair passes, advanced-base re-review, restart and release. Repairs keep the same PR with distinct heads. The issue stays open and in review. Scheduled admission runs independently of active work without adding lifecycle capacity. Missed occurrences collapse to one catch-up; host-local daylight saving handling suppresses repeated civil minutes. No-work backoff starts at recorded completion, and restart accounting prevents completed runs from being recreated. Merge review runs in its own selected local profile. Live accounts and installed original workflows remain ahead.

  4. Running locally

    Close reviewed PRs and linked issues

    Run the original hourly merge-review workflow from PR selection through independent review, exact-head merge and linked-issue closeout.

    The original schedule runs at 23 minutes past each hour through serve in its selected local GitHub profile. This is separate from the implementation profile, not both workflows in one instance. Eligible managed approvals reach fresh head, base and CI checks before merging. Advisory and non-passing published reviews give feedback without a merge. Stale issue content goes to remediation before a model runs. Restart reconciles accepted merges and comments rather than repeating them.

  5. Running locally

    Give overlapping PRs an order

    Elect eligible managed PRs in FIFO order, park nonwinners on predecessors and unpark them when blockers resolve.

    The controller keeps independent review separate from election: ordering-only findings can pass for an eligible winner, but substantive defects still block a merge. Resolved closure, merge or demotion can unpark waiting PRs. Only a verified managed park requests priority selection through ordinary counted admission, within one hour and subject to readiness, quota, capacity and epoch checks. A later run can find no work or unpark, review and merge eligible work. Restart retains completed results and accepted label changes rather than repeating them.

  6. Running locally

    Finish queued and obsolete PRs

    Follow queued merges to closeout and close objectively moot, duplicate or superseded PRs after independent non-passing review.

    The unchanged merge-review configuration now covers these paths in its selected local GitHub profile. Queue recovery uses an authenticated current target-branch tip and retains accepted enqueue through later read failures; a new counted run can finish once without another enqueue. Objective closure requires both a genuine non-passing review and one of four observed grounds. Passing and advisory reviews stay protected. Close the PR and explain why without merging, publishing a native review, deleting a branch or closing an issue. Partial closeout and the original run remain visible after interruption.

  7. Running locally

    Respect scope and retain repair work

    Review scope-gated PRs, reconcile acknowledgements and heal existing remediation records against current code and target branches.

    The selected original merge-review profile keeps review available while the computed scope gate controls merging. Both retained gate decisions and the unchanged current acknowledgement must allow a merge; label presence alone cannot decide it. Definite provider warnings preserve that decision, while uncertain effects keep their fences. Restore the remediation lane before clearing a healed escalation, using current target tips and repository-read access only. Full PR-remediation execution and new repeat-fail state remain separate work; the full original workflow has source implementation only.

  8. Running locally

    Reuse reviews and classify Tutor changes

    Reuse trusted verdicts with fresh current-run checks, recover stale comments and apply Tutor policy at selection, direct merge and queue admission. Cache sibling file paths and line totals without skipping live PR metadata.

    The selected original merge-review profile reuses a verdict only while its author, reviewed code, acknowledgement and source-run bindings hold. Rebuild gate and publication authority rather than treating old approval as a new permission. Matching-head file paths and line totals can be reused; open inventory and mutable PR state stay fresh. File-cache and verdict-cache controls are independent. Recover stale comments without repeating effects; older malformed comments no longer stall fresh review. Tutor persona and automated gate-only changes can land through review, while structural, skill and validation changes require human handling, including late changes and reused verdicts. Full Tutor generation, holdout, forks and general reruns remain separate work.

  9. Worker builds

    Run the remote scratch-worker cycle

    Deliver a trusted task to a worker and return a result the owner can safely accept.

    The worker/API/TLS/owner chain and full component scenario are implemented, and the native worker builds. Satisfy namespace prerequisites and demonstrate the complete remote cycle. Image, Kubernetes and distributed actor messaging remain outstanding.

  10. Operating checks ahead

    Ship a service people can operate

    Install, start, inspect, restart, upgrade and restore Hewbers without a developer checkout.

    Native components build from the published default branch. Local service execution is working, not a supported release. Test the real installed profiles, including original workflows, optional authored kits and offline migration, then broaden live model, MCP and provider coverage.

  11. Running locally

    Author tasks with agents and reviewers

    Choose agents and reviewers in an authored workflow, with decisions tied to the work they actually reviewed.

    Configured implementation and independent review now execute in the original authored workflow with controlled services. Rejected review and CI failures drive bounded repair passes. Retained decisions survive restart without automatically replaying completed work. Broader agent/reviewer kits and live models remain work to do.

  12. Planned after authored agents

    Approve, override or rerun a stage

    Make a deliberate human decision that the run owner records and carries out once, even across a restart.

    Connect authenticated approval, a reasoned override or an explicit stage rerun to durable owner validation, admission and claim reacquisition. Resume the exact paused occurrence or retain rerun instructions without changing the pinned workflow. Refuse stale or conflicting decisions; do not let approval rewrite completion records. Keep existing abort behaviour intact. These complete control paths are planned, not implemented.

  13. Routing runs locally; repair planned

    Turn human feedback into a reviewed PR update

    Route fresh human comments into remediation; next, carry them through repair and review on the same branch and confirm the exact published change.

    The explicit comment-watch task routes fresh human feedback without approving or carrying out a repair. Connect this routing to PR-specific admission and a versioned repair brief. Verify changed work before publishing; clear remediation labels only after confirmation. Retain routing identity, the original head and progress budgets across runs and recovery. Full PR-remediation execution remains unfinished. The watcher runs only when invoked; immediate capture is not guaranteed.

  14. Further work

    Cover the wider Goobers workflows

    Support the resources, access and execution profiles that complete coding workflows need.

    Implementation and merge review run in separate selected local profiles, not as arbitrary workflow automation. Non-default coordination policies, fork workspaces, full Tutor generation and holdout execution, general reruns and instruction addenda remain unfinished. So do webhook ingress, arbitrary DSL 3 original merge-review profiles and permissive handling of disjoint base changes. Backlog curation, PR remediation, new repeat-fail state production, general failure retry and salvage, complete native controls and distributed actor messaging remain separate work. Expand live credentials, remote Git and agentic kits without treating local success as full parity.

Putting Hew to work.

Hewbers brings the complexity of repositories, subprocesses and recovery to Hew — with useful coding work as the goal.