ultra-builder-pro-cli 0.13.0 → 0.15.0

package/docs/STATE-DB-ACCESS-POLICY.md

@@ -4,13 +4,13 @@
 > risks R21 / R25.
 
 `.ultra/state.db` is the only authoritative state store for baselines, changes,
-tasks, events, sessions, incidents, projections, telemetry, and spec references
+tasks, workflow runs/steps, events, sessions, incidents, projections, telemetry, and spec references
 (D18, D52, D54). Every process
 that touches it must follow the rules below; deviations are bugs.
 
 ## 1. Three-role write matrix
 
-| Role | tasks | baselines | change/artifact state | events | sessions | telemetry | specs_refs | migration_history |
+| Role | tasks | baselines | change/workflow/artifact state | events | sessions | telemetry | specs_refs | migration_history |
 |---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
 | **MCP server** (single writer for mutables) | RW | RW | RW | RW | RW | RW | RW | RW |
 | **CLI** (`ultra-tools …`) | R | RW (init only) | R | RW (append-only) | R | R | R | RW (migration only) |
@@ -31,7 +31,11 @@ write API for normal task, change, session, or baseline lifecycle updates.
 The append-only carve-out for `events` exists because `events.id INTEGER
 PRIMARY KEY AUTOINCREMENT` makes concurrent inserts collision-free under
 WAL + `busy_timeout`. This lets hooks and short-lived CLI invocations
-record audit events without paying the cost of a full MCP round trip.
+record audit observations without paying the cost of a full MCP round trip.
+It does not grant lifecycle authority: external writers and public
+`task.append_event` use the published observation allowlist, while lifecycle event
+names are emitted only inside the mutation that owns the corresponding state change.
+Consumers must verify mutable rows rather than infer success from an event name.
 
 ## 2. Connection discipline
 
@@ -40,31 +44,27 @@ Every process **must**:
 1. Open the database with WAL + `busy_timeout=5000` + `foreign_keys=ON`.
    Use `mcp-server/lib/state-db.cjs` `openStateDb` so the pragmas are
    applied uniformly.
-2. Wrap every write in `BEGIN IMMEDIATE` (use the helper `withWrite(db,
-   fn)` once Phase 2.3 lands; until then call `db.transaction(fn)()` and
-   know that better-sqlite3 promotes to IMMEDIATE on the first write).
-3. Retry up to **3 times** on `SQLITE_BUSY`, with exponential backoff
-   starting at 25 ms. Each retry must re-issue the full transaction —
-   never partially commit.
+2. Wrap every mutable state operation with `state-ops.cjs` `tx(db, fn)`. The
+   helper calls better-sqlite3's immediate transaction variant, so the writer
+   lock is acquired before user code runs and the whole operation rolls back on
+   failure.
+3. Retry the complete transaction up to **10 attempts** on `SQLITE_BUSY`, using
+   decorrelated jitter from a 50 ms base with a 2 s cap. Never retry only a
+   suffix of a failed transaction or preserve partial state.
 4. Close the connection in a `finally` block. WAL files (`-wal`,
    `-shm`) are reclaimed on the last writer's close.
 
 Reads never need explicit transactions; better-sqlite3 reads observe a
 consistent snapshot under WAL.
 
-## 3. WAL fallback
+## 3. WAL requirement
 
-WAL is **unsafe on NFS / SMB / certain Docker bind mounts** (R21). When
-`.ultra/state.db` resides on such a filesystem the orchestrator must
-either:
-
-- refuse to start (preferred — surfaces the deployment problem early), or
-- downgrade to `PRAGMA journal_mode = DELETE` and warn loudly. Concurrent
-  writers fall back to short-burst contention; throughput drops but
-  correctness holds.
-
-Detection happens at boot: `statvfs` of `.ultra/state.db`'s mount;
-`f_type` ∈ `{NFS_SUPER_MAGIC, SMB_SUPER_MAGIC}` ⇒ refuse / downgrade.
+WAL is part of the authority contract, not an optional performance setting.
+`openStateDb` asks SQLite to enable WAL and checks the actual returned mode. If
+the storage layer returns anything else, startup fails with
+`STATE_DB_WAL_UNAVAILABLE`. Ultra does not silently downgrade to a different
+concurrency model. Move `.ultra/state.db` to storage that supports SQLite WAL or
+resolve the mount/runtime constraint before retrying.
 
 ## 4. Where each table is owned
 
@@ -73,9 +73,10 @@ Detection happens at boot: `statvfs` of `.ultra/state.db`'s mount;
 | `baselines`        | MCP server (`baseline.start` / `baseline.record` / `baseline.converge`); initialization and legacy-projection migration may create only the first draft or compatibility row |
 | `tasks`            | MCP server (`task.create` / `task.update` / `task.delete`) |
 | `changes`          | MCP server (`change.create` / `change.update` / `change.converge` / `change.archive`) |
+| `workflow_runs`, `workflow_steps` | MCP server (`workflow.start` / `workflow.step` / `workflow.complete`); skills provide evidence inputs but never write rows directly |
 | `artifacts`, `context_snapshots`, `spec_learning_candidates`, `trace_links` | MCP server through change lifecycle tools |
 | `incidents`, `projection_jobs`, `event_consumers`, `circuit_breaker` | MCP server; backup-first doctor recovery may perform only documented mechanical transitions |
-| `events`           | MCP server **and** any process via append-only INSERT  |
+| `events`           | MCP server for lifecycle events; approved processes and `task.append_event` for allowlisted append-only observations |
 | `sessions`         | MCP server (`session.spawn` / `session.close` / `session.heartbeat`); orchestrator may write status transitions |
 | `telemetry`        | MCP server (collected from tool-call wrappers); orchestrator may dump bulk samples |
 | `specs_refs`       | MCP server (rebuilt on `spec_changed` event); orchestrator may rebuild |
@@ -110,6 +111,7 @@ The contract on this page is enforced by:
   appending to `events` simultaneously; asserts no `SQLITE_BUSY` escapes
   the retry loop and the resulting `events.id` sequence has no gaps and
   no duplicates.
-- Phase 2.3 will add `concurrency-update.test.cjs` — 20 worker threads
-  driving `task.update` against disjoint task ids, verifying serialized
-  writes through the MCP server.
+- `mcp-server/tests/state-ops.test.cjs` — immediate transactions, rollback,
+  status transitions, task contracts, and event coupling.
+- `mcp-server/lib/workflow-state.test.cjs` — ordered workflow transitions,
+  evidence/output requirements, blocking/resume, and cross-stage gates.

package/docs/WORKFLOW-LIFECYCLE.md

@@ -0,0 +1,266 @@
+# Ultra Builder Pro workflow lifecycle
+
+This document defines when Ultra writes authoritative state, how each workflow
+advances, what invalidates evidence, and which decisions remain with the active
+host and project owner. It is the operational companion to
+[`ARCHITECTURE.md`](./ARCHITECTURE.md) and the machine contracts under `spec/`.
+
+## 1. Authority boundaries
+
+| Surface | Owns | Must not own |
+|---|---|---|
+| Active host and owner | Product judgment, research content, implementation, review findings, release authorization | Durable workflow status or fabricated evidence digests |
+| Skill | One reusable procedure and its evidence requirements | Project state, static product doctrine, host-specific tool fiction |
+| MCP | IDs, transitions, task contracts, evidence references, output hashes, gate verdicts, next action | Research prose, code generation, memory, or model calls |
+| `.ultra/state.db` | Baseline, change, task, workflow, session, event, incident, projection, and evidence authority | External memory or code-graph payloads |
+| Generated JSON and Markdown | Read-only projections and durable artifacts | Independent lifecycle authority |
+| Hook | Compact DB-derived lifecycle observation, minimal event metadata, and projection protection | Generic engineering judgment, prompt/transcript capture, parallel lifecycle logs, or arbitrary edit blocking |
+
+Prompt input can supply facts, content paths, reasons, owner decisions, and
+evidence references. MCP reads the current repository and DB, validates those
+inputs, hashes outputs, and derives status. Prompt input cannot override a task's
+public seam, verification command, context references, workflow summary, gate
+verdict, output digest, or next action.
+
+Every change-bound research, plan, dev, test, review, and deliver run inherits
+the baseline id from the owning change workflow. A Prompt cannot switch that
+authority, and no new stage may start on an archived or cancelled change. Doctor
+recovers a legacy change without this link into an explicitly blocked workflow;
+it does not fabricate the missing provenance.
+
+Ultra does not select an MVP. Product scope and delivery posture are owner
+decisions. A reduced research mode is valid only for an explicitly bounded active
+change with a recorded selection reason; initial greenfield and brownfield
+baselines always use all seventeen research steps.
+
+## 2. How `ultra-init` classifies a repository
+
+`task.init_project` scans a bounded repository view while ignoring `.git`,
+`.ultra`, dependencies, virtual environments, generated build output, and other
+known non-source directories.
+
+`auto` classification is deterministic:
+
+- `brownfield` when delivered-system evidence exists: application source, tests,
+  deployment configuration, or persisted-state/schema evidence;
+- `greenfield` when none of those signals exists. A Git repository, README,
+  package manifest, workspace manifest, or starter documentation alone does not
+  prove delivered behavior;
+- `migrated` is never inferred from source. It is a compatibility state created
+  when older Ultra authority is preserved and upgraded. It requires a new
+  evidence-backed brownfield adoption before normal work.
+
+The scan also records bounded signal paths, detected verification commands,
+evidence-backed project type and technology signals, monorepo markers, candidate
+workspace roots, and whether the scan limit was reached. Explicit owner-supplied
+project type or stack metadata overrides detection without deleting the observed
+signals. In a monorepo, the owner selects the repository scope; baseline
+worktree digests and accepted dirty files are restricted to that scope.
+
+Classification and readiness are separate. Initialization immediately creates
+or resumes `.ultra/state.db`, installs only the required scaffold, records the
+classification, opens an `init` workflow, and opens `full` research for
+greenfield or `adoption` research for brownfield. Empty templates are not an
+approved baseline.
+
+## 3. Durable status machines
+
+### Baseline
+
+```text
+draft -> adopting -> ready -> superseded
+            |
+            -> blocked -> adopting
+```
+
+- `draft`: greenfield authority exists but has not been established.
+- `adopting`: brownfield or migrated evidence is being recorded.
+- `blocked`: current baseline evidence, verification, scope, or approval cannot
+  converge.
+- `ready`: research, evidence, repository snapshot, gaps, and approval converged.
+- `superseded`: preserved historical baseline after an explicitly authorized
+  replacement.
+
+`ready` is not trusted as a label alone. Every baseline/status/doctor/change gate
+revalidates its persisted fields, current files, research outputs, revision and
+worktree, known-red acceptance, blocking gaps, and approval provenance. An ordinary
+active change may downgrade only the expected drift created after its completed
+`bind-baseline` step to warnings; it cannot downgrade adoption, migration, missing
+evidence, or structural blockers. Approved incident break-glass is the only other
+execution exception and creates a mandatory reconciliation gap.
+
+### Change
+
+```text
+active <-> blocked -> ready -> archived
+   \--------------------------> cancelled
+```
+
+Only a healthy `ready` baseline may authorize a new ordinary change. An incident
+may bypass an unhealthy baseline only with a stored reason and approver; archive
+then creates a blocking baseline-reconciliation gap.
+
+### Task
+
+```text
+pending -> in_progress -> completed
+   |            |
+   v            v
+ blocked <------+
+   |
+   -> pending
+
+pending -> expanded -> completed
+```
+
+A task is executable only when its DB contract contains an observable outcome,
+traceability, slice kind, public seam, exact verification command, acceptance
+checks, context references, resolved documentation impact, owner, and valid
+dependencies.
+
+### Workflow run and step
+
+```text
+run:  active <-> blocked -> ready -> completed
+                              \----> cancelled
+
+step: pending -> in_progress -> completed
+         |            |
+         v            v
+       blocked ------> in_progress/completed
+```
+
+Required steps execute in definition order. A step that requires evidence or an
+output cannot complete without it. When the final required step completes, the
+run becomes `ready`; `workflow.complete` revalidates the entire stage before
+making it `completed`.
+
+## 4. Write and verification lifecycle
+
+| Stage | Authoritative writes | Completion verification | Next route |
+|---|---|---|---|
+| `init` | Baseline classification/scope, init run, research run, initialization event, projection job | DB/schema opens, scaffold/projection succeeds; baseline convergence later completes init | `research`, re-adoption, or `change` for an already-ready baseline |
+| `research` | Ordered step evidence, decisions, typed semantic records with source digests, one immutable report per selected step, output paths and SHA-256 digests | Every report has the required structure; semantic kinds/attributes/source anchors are valid and current; full/adoption synthesis binds the current three specifications and distillate; all digests remain current | `baseline.record`, then approval/convergence; bounded change research returns to its change |
+| baseline convergence | Spec/source/runtime refs, verification results, known failures, unknowns, gaps, branch/HEAD/worktree, approval | Full/adoption research complete; required discovery/product/architecture refs current; revision/worktree exact; blocking gaps resolved or explicitly accepted where allowed | `change` for every initial or daily outcome |
+| `change` | Complete Change Contract, profile/risk rationale, research disposition, intent/delta artifacts, linked change run, initial context snapshot | Blocking decisions resolved; selected change research current; current plan task set matches DB; task-bound context is ready; one next action is derived | selected `research`, then `plan`, or `dev` for an already approved current plan |
+| `plan` | Plan-step evidence, complete change-owned task rows, acceptance coverage matrix, change-bound `.ultra/execution-plan.json`, explicit plan approval | Every Change acceptance id is owned by a task; task trace targets resolve; quick has one task; ownership/dependencies valid; no cycles; exported topology and digest exactly match the current change task set | `dev` for the first dependency-ready task |
+| `dev` | Task/session transitions, step evidence, immutable implementation context, completion/review references | Task completed; no live session; task contract unchanged; starting context and review artifacts valid; completion commits remain ancestors of current HEAD | Next task, then aggregate `test` |
+| `test` | Immutable checking context and `.ultra/reports/tests/<workflow-id>.json` | Report change/task set, full HEAD, worktree digest, context digest, commands, public seam, blockers, and all acceptance/regression/integration/static/build/performance/security/recovery dimensions agree; every omission has a not-applicable rationale | `review` when passing, otherwise resume `dev`/`test` |
+| `review` | Immutable review context, `task`/`change`/`plan` mode, worker selection provenance, two specialist axes, coordinated summary | Current diff/HEAD and context match; selected/skipped workers match recorded rationale; both axes complete; P0/P1 and axis verdicts deterministically derive final verdict | `deliver` only from approved `change` mode, otherwise resume implementation |
+| `deliver` | Convergence context, verified learning resolutions, schema-validated semantic reconciliation manifest, change archive, durable release-authorization decision, immutable delivery report | Tasks/test/change-review current; every baseline update has an anchored before/after semantic record; `change.converge` derives evidence from DB and accepts no Prompt verdicts; archive and baseline transaction agree; external actions have evidence | Report completion or start the next `change` |
+| `status` | None | Reads doctor, baseline, workflows, breadcrumb, tasks, sessions, Git, and DB-referenced reports | One exact current route |
+| `doctor` | None by default; explicit repair writes only mechanical recovery state | Re-runs integrity, schema, workflow-output, projection, session, incident, archive, and install checks | Exact repair, restore/rebaseline decision, or workflow route |
+
+Every mutating MCP operation appends an event and enqueues projection work when
+the corresponding read-only view can change. Projection failure is recorded as
+a retryable incident; it does not silently convert a failed write into success.
+`task.append_event` accepts only non-authoritative observations. Lifecycle events are
+emitted by their owning DB mutation and never act as a substitute state transition.
+
+## 5. Context and prompt follow-through
+
+`change.context` compiles an immutable Context Manifest v2 snapshot. It combines:
+
+- the bound baseline/change/task identity;
+- a role and lifecycle gate;
+- DB-backed task outcome, public seam, verification command, and required refs;
+- local file hashes, current HEAD, branch, and worktree digest;
+- optional metadata-only external memory or graph references;
+- advisory file/token/context-share budgets;
+- readiness blockers and one DB-derived next action.
+
+Critical stage workflows bind a matching snapshot as a durable output:
+
+| Workflow | Required role | Required gate |
+|---|---|---|
+| `change` | `plan` or `implement` | `planning` or `implementation` |
+| `dev` | `implement` | `implementation` |
+| `test` | `check` | `verification` |
+| `review` | `review` | `review` |
+| `deliver` | `check` | `convergence` |
+
+The snapshot path and digest are then carried into test, review, and delivery
+reports. This prevents a later Prompt from claiming evidence gathered under a
+different context. File and token budgets warn; they do not block legitimate
+work. Missing authority, required refs, task contracts, outputs, approval, or
+current gate evidence do block.
+
+## 6. Invalidation rules
+
+- Changing a task contract invalidates contexts and gates that depended on the
+  former contract.
+- Changing required source/spec content invalidates the recorded output or
+  context digest.
+- Changing a research semantic source invalidates that workflow even when its immutable
+  step report remains unchanged.
+- Changing full HEAD or the worktree invalidates aggregate test, review, and
+  delivery evidence.
+- A completed dev run remains valid across later task commits when its bound
+  task contract is unchanged and its recorded commits remain ancestors of the
+  current HEAD.
+- Test, review, and delivery reports use workflow-id paths so a later run cannot
+  overwrite historical evidence.
+- `.ultra` workflow artifacts are excluded from application-worktree drift, but
+  their own recorded SHA-256 digests are still authoritative.
+- Generated `tasks.json` and task-context headers are projections. Manual edits
+  are overwritten and never repair DB authority.
+
+## 7. Entry flows
+
+### New project
+
+```text
+ultra-init -> full research (17 steps) -> baseline approval
+-> initial change + plan -> dev per task -> test -> review -> deliver
+```
+
+### Existing project
+
+```text
+ultra-init -> brownfield adoption research (17 steps)
+-> characterization and known-red evidence -> gap ledger -> owner approval
+-> first selected change -> plan -> dev -> test -> review -> deliver
+```
+
+Adoption records the system that exists. It does not force the owner to recreate
+market, persona, or roadmap claims that cannot be supported; those remain
+`Unknown` or explicit gaps while every semantic step is still processed.
+
+### Earlier Ultra project
+
+```text
+doctor/migrate with backup -> migrated compatibility authority
+-> explicit brownfield re-adoption -> full convergence -> normal change loop
+```
+
+Migration preserves prior files and rows but never carries old approval forward.
+
+### Daily maintenance
+
+```text
+ultra-status -> ultra-change -> plan if task contracts are absent
+-> dev -> test -> review -> deliver -> reconciled baseline
+```
+
+Quick changes shorten the artifact burden only where the machine contract allows;
+they do not skip task ownership, executable acceptance, current checking, review,
+or baseline reconciliation. Incidents add structured diagnosis and recovery
+evidence rather than bypassing them.
+
+## 8. Recovery and diagnosis
+
+Use `system.doctor` for project authority and `ubp --doctor` for installed host
+assets. Both are read-only unless an explicit project repair command is chosen.
+
+During an explicit repair, a legacy active change that predates durable workflows gets
+one blocked change run at `bind-baseline` with
+`LEGACY_CHANGE_PROVENANCE_REQUIRED`; repair does not invent its evidence. Rebind it to
+the re-adopted baseline and resume the same run before planning. Every plan must use
+the exact baseline id stored by its owning change run; only an approved break-glass
+incident may legitimately bind no baseline id.
+
+Resume the same blocked workflow and current step after resolving its blocker.
+Do not create parallel runs to escape state. Supported schema and projection
+repairs are backup-first. A corrupt DB is preserved and requires an explicit
+restore or rebaseline decision; neither action can manufacture research,
+verification, or owner approval.

package/hooks/README.md

@@ -14,12 +14,17 @@ advisory workflow conditions into refusal gates.
 | Before compact | `workflow_checkpoint.py` | Validate and atomically save a minimal workflow checkpoint |
 | After compact/resume | `workflow_resume.py` | Prefer the DB breadcrumb; restore the minimal file checkpoint only when no active change owns recovery |
 | Stop | `pre_stop_check.py` | Report an incomplete workflow boundary and allow stop |
-| Subagent lifecycle | `subagent_tracker.py` | Append lifecycle evidence under `.ultra/runtime/` |
+| Subagent lifecycle | `subagent_tracker.py` | Append minimal start/stop metadata to the authoritative DB event stream |
 
 The plugin deliberately does not capture prompts, tool observations, transcripts, summaries, or
 cross-session memory or code-graph content. Generic command blocking and post-edit policy are
 user/repository governance. Persistent Memory/graph content belongs to separately installed providers.
 
+`subagent_tracker.py` passes only agent id/type and the host session id to the bundled
+`hook-event.cjs` helper. The helper binds the current change/task and appends
+`subagent_started` or `subagent_stopped` to `state.db`; it never stores transcript
+paths, messages, or a parallel JSONL lifecycle log.
+
 `context_spine.py` is an imported library, not an eighth lifecycle registration.
 Registering it separately would duplicate hook execution. The checkpoint is a recovery artifact, not a second authority. A valid newer
 live workflow wins; a newer valid checkpoint may restore a missing or older

package/hooks/active_task_context.py

@@ -2,13 +2,11 @@
 """Protect Ultra projections and restate an active task boundary before edits."""
 
 import json
-import sqlite3
 import sys
 from pathlib import Path
 
-from context_spine import read_breadcrumb, render_breadcrumb
+from context_spine import ContextSpineError, find_root, read_breadcrumb, render_breadcrumb
 
-TERMINAL = {"committed", "completed", "done", "cancelled"}
 TASKS_PROJECTION = Path(".ultra/tasks/tasks.json")
 
 
@@ -34,58 +32,32 @@ def main() -> None:
     except json.JSONDecodeError as exc:
         print(f"[active_task_context] invalid hook input: {exc}", file=sys.stderr)
         data = {}
-    start = Path(data.get("cwd") or Path.cwd()).resolve()
-    for root in (start, *start.parents):
-        ultra = root / ".ultra"
-        state_file = ultra / "workflow-state.json"
-        initialized = (
-            (ultra / "state.db").is_file()
-            or state_file.is_file()
-            or (ultra / "changes" / "active").is_dir()
-        )
-        if not initialized:
-            continue
-        if targets_tasks_projection(data, root):
-            print(json.dumps({"hookSpecificOutput": {
-                "hookEventName": "PreToolUse",
-                "permissionDecision": "deny",
-                "permissionDecisionReason": (
-                    "Refusing a direct write to the .ultra/tasks/tasks.json projection. "
-                    ".ultra/state.db is authoritative; use the Ultra MCP task tools and "
-                    "run ultra-doctor when state or projection health is degraded."
-                ),
-            }}))
-            return
-        try:
-            breadcrumb = read_breadcrumb(root)
-        except (sqlite3.Error, OSError) as exc:
-            print(f"[active_task_context] cannot inspect Context Spine: {exc}", file=sys.stderr)
-            breadcrumb = None
-        if breadcrumb and breadcrumb.get("task_id"):
-            print(json.dumps({"hookSpecificOutput": {
-                "hookEventName": "PreToolUse",
-                "additionalContext": render_breadcrumb(root, breadcrumb),
-            }}))
-            return
-        if not state_file.is_file():
-            break
-        try:
-            state = json.loads(state_file.read_text(encoding="utf-8"))
-        except (OSError, json.JSONDecodeError) as exc:
-            print(f"[active_task_context] cannot read {state_file}: {exc}", file=sys.stderr)
-            break
-        if not isinstance(state, dict) or state.get("status") in TERMINAL:
-            break
-        task = state.get("task_id", state.get("task", "unknown"))
-        step = state.get("step", "unknown")
+    root = find_root(Path(data.get("cwd") or Path.cwd()).resolve())
+    if root is None:
+        print(json.dumps({}))
+        return
+    if targets_tasks_projection(data, root):
         print(json.dumps({"hookSpecificOutput": {
             "hookEventName": "PreToolUse",
-            "additionalContext": (
-                f"Active Ultra task {task}, step {step}. Keep this edit inside the approved "
-                "task and preserve .ultra/state.db as workflow authority."
+            "permissionDecision": "deny",
+            "permissionDecisionReason": (
+                "Refusing a direct write to the .ultra/tasks/tasks.json projection. "
+                ".ultra/state.db is authoritative; use the Ultra MCP task tools and "
+                "run ultra-doctor when state or projection health is degraded."
             ),
         }}))
         return
+    try:
+        breadcrumb = read_breadcrumb(root)
+    except ContextSpineError as exc:
+        print(f"[active_task_context] cannot inspect Context Spine: {exc}", file=sys.stderr)
+        breadcrumb = None
+    if breadcrumb and breadcrumb.get("change_id"):
+        print(json.dumps({"hookSpecificOutput": {
+            "hookEventName": "PreToolUse",
+            "additionalContext": render_breadcrumb(root, breadcrumb),
+        }}))
+        return
     print(json.dumps({}))