Roadmap

Evaluation, plan and roadmap for vibe-sketch.

The shared scope decision, confirmed on 2026-10-15, sets the boundary: publication-quality 2D drawing and reaction graphics here, detailed 3D calculation work in vibe-view, with input, drawing, basic cleanup and calculation workflows in both. WP 3.6/3.7 implement the sketcher side of reference-geometry and FIRE cleanup. The geometry database still needs a source/licence decision; existing cleanup must not be labelled as that future implementation.

Status. The maintainer accepted this proposal on 2026-10-13 and chose the name. Phase 0 was delivered on 2026-10-14: the repository skeleton, the canvas spike with a go recommendation (spike_canvas.md), document schema v1 with the writer interface, and the cross-repository asks (section 5). Phase 1 followed on the same day as the first testing version, on the spike’s go recommendation (decision 3 in section 7 still waits on the maintainer), with drawing clean-up and mechanisms added. Phase 2 is all but done:

  • 3D embedding, the ORCA, vibe-qc and QCSchema writers, QVF, vibe-queue and the MCP server (WP 2.1 to 2.6) are in.

  • QVF, which the maintainer made the standard for every file in the vibe family on 2026-10-14, is the document format, pinned to QVF toolkit v0.4.0.

  • vibe-sketch opens what the other vibe programs write.

  • The Electron desktop shell, runtime installer and macOS source launcher are implemented. Remaining desktop file workflows, the desktop CLI, file associations and release acceptance remain tracked under WP 2.7.

From 2026-10-15 Claude and Codex sessions work in parallel from the issue tracker (“Where the work stands” below; AGENTS.md, “Picking up work”). The code is proprietary for now. An open-source release under MPL-2.0 is possible later, so the repository is written public-safe from the first commit: no private values anywhere, and every dependency compatible with MPL-2.0. Partnership and licensing considerations are kept outside this repository.

1. What we are building

A 2D chemical structure and reaction sketcher with ChemSketch and ChemDraw class ergonomics that does three things the existing sketchers do not do together:

  1. Publication graphics. Reaction schemes and structures exported as SVG, PNG and PDF in journal styles, plus CDXML for co-authors who use ChemDraw and chemfig for LaTeX users.

  2. Calculation inputs. The same sketch becomes a 3D structure and a ready-to-run input for vibe-qc and ORCA, with charge, multiplicity, method, basis and solvent chosen in a side panel. More programs follow through the same writer interface.

  3. An API agents can drive. Everything the browser does, a Python SDK, a CLI, a REST API and an MCP server can do too. A human and an agent can edit the same live document.

It runs in the browser and as a desktop app. It hands 3D work to vibe-view and jobs to vibe-queue. There is no terminal drawing mode.

Three user stories anchor the scope:

  • The author. Draws reactants, products, arrows and conditions for a paper, numbers the compounds, exports the scheme in the journal’s style and sends the CDXML to a co-author.

  • The computational chemist. Sketches a molecule, cleans it, gets a 3D conformer, picks B3LYP/def2-TZVP with CPCM(water), exports an ORCA input or submits it through vibe-queue, and opens the result in vibe-view. For a reaction, one job per species and a reaction energy that lands back on the scheme.

  • The agent. Builds a document from a SMILES string or a name, lays it out, renders it, writes inputs and submits them, or edits the document a human is looking at.

Non-goals: a 3D editor (vibe-view has one), an electronic lab notebook, feature parity with ChemDraw, drawing in the terminal.

2. Evaluation

2.1 Plugin for vibe-view, or standalone?

Factor

Plugin

Standalone with a bridge

Plugin API in vibe-view

Does not exist yet; proposed for v3.0 in the vibe-view roadmap. Building the sketcher as a plugin means building that API first and coupling two release schedules.

Nothing to wait for.

UI technology

vibe-view is Trame: Python owns the UI state and renders Vue. A sketcher is a client-side canvas with state in the browser, the opposite model.

Plain TypeScript app over an HTTP and WebSocket API.

Install weight

A chemist drawing a scheme would install VTK and PyVista.

pip install vibesketch pulls RDKit and FastAPI, nothing 3D.

Users who want both

Served by a bridge: a Sketch button in vibe-view, an Open in vibe-view button in the sketcher, QVF in between.

Same.

Licensing freedom

Bound to vibe-view’s licence.

Decided separately.

Repository

Shared tracker, shared CI minutes, shared release gate.

Own repository, as requested.

Recommendation: standalone product in its own repository, integrated with vibe-view both ways. The bridge is cheap: vibe-view already builds from SMILES, exports QVF and submits to vibe-queue, and it has an Electron shell that can later host both products as tabs.

2.2 Build the canvas, or embed one?

A 2D chemical editor is the most expensive component: bond drawing with angle snapping, ring and chain tools, stereo wedges, charges and radicals, atom labels and abbreviations, brackets and S-groups, reaction arrows and text, selection, rotation, flipping, undo, copy and paste, and a hotkey layer that chemists already know. Candidates:

Candidate

Licence

What it is

Verdict

Ketcher (EPAM)

Apache-2.0

TypeScript and React editor; standalone mode bundles the Indigo toolkit as WebAssembly, so layout, clean-up, aromatize, CDXML, MOL/RXN, SMILES, InChI and SVG/PNG rendering work offline. Own JSON format (KET). Used by PubChem. Active 3.x releases.

Primary candidate.

OpenChemLib JS

BSD-3-Clause

Cheminformatics toolkit with a structure editor; DataWarrior lineage.

Fallback engine; editor less polished.

Kekule.js

MIT

Toolkit with an editor widget. Low recent activity.

Fallback.

JSME

BSD-3-Clause

GWT-compiled minified editor; hard to restyle.

No.

RDKit.js

BSD-3-Clause

Depiction and chemistry in WebAssembly, no editor.

Useful for rendering, not a canvas.

ChemDoodle Web Components

GPLv3 or paid

Capable, but GPL conflicts with MPL-2.0 and with any commercial route.

Excluded.

Marvin JS

Proprietary

Excluded.

Own editor

Ours

Full UX control, our design language.

Three to six times the effort of embedding, before any compute feature exists. Only if the spike fails.

Recommendation: embed Ketcher as the canvas engine behind an adapter, and own everything around it: the shell, the document format, the compute panel, the style presets, the exports and the API. The adapter is the only module that imports Ketcher, so the engine can be swapped if EPAM’s direction diverges from ours. Apache-2.0 is compatible with MPL-2.0 and with a commercial licence; a fork is permitted if ever needed.

The decision is confirmed by a time-boxed spike (WP0) with written exit criteria: bundle size and load time with Indigo WebAssembly, how far the toolbar and template library can be replaced, KET round-trip fidelity for stereo, charges, S-groups, arrows and text, the cost of hosting a React component inside our shell, and a check of the licence files as shipped.

2.3 Chemistry engine

  • RDKit (BSD-3-Clause) in Python, as a core dependency. 2D coordinates, ETKDG embedding with MMFF94 refinement, conformer ensembles, CIP stereo labels, InChI and InChIKey, formula and mass, ACS 1996 depiction style. vibe-view keeps RDKit optional because it is a viewer; the sketcher is a chemistry tool and should not ship without it.

  • Indigo in the browser through Ketcher’s standalone build, so drawing, clean-up and basic export work with no Python running. The release notes for Indigo 1.25 list an ACS-style reaction layout and CDX/CDXML fixes.

  • No Open Babel (GPL-2.0) and no ChemDoodle, in line with vibe-view’s ground rule 4. A licence check in CI enforces this.

  • Name to structure beyond the 83 built-in structures: a network fallback through the resolvers vibeqc_naming.external already wraps, and optionally OPSIN behind a lazy import once its licence has been checked.

2.4 What we reuse

From

What

How

vibe-qc

vibeqc_naming: MolecularGraph, name_from_graph, structure_from_name, smiles_from_name, NamedResult with provenance and confidence, the solids engine for later crystal work

The sketcher has explicit bonds, so it calls the graph API rather than the 3D bond perception. It becomes the first consumer that can feed CIP descriptors into the engine.

vibe-qc

Molecule, run_job, run_qcschema, solvation presets

The targets of the vibe-qc writer. The QCSchema adapter’s fail-closed stance is the model for every writer.

vibe-view

input_generator templates, converters.atoms_to_qvf and sdf_to_qvf, build_tools.FRAGMENTS

Copied, then generalized into the writer registry.

vibe-view

Electron shell: handshake JSON, managed venv, interpreter probe, updater feed, PUBLISHING.md contract

Forked as electron/, product name and feed path changed.

vibe-view

codenames.py, release process, changelog fragments, Sphinx toolchain, .githooks/pre-commit privacy hook, scripts/install.sh family, CI layout, strict mypy and Ruff gates

Copied as the repository skeleton on day one, so the lessons of the mypy ramp are not relearned.

qvf

qvf-writer (numpy only)

QVF export without depending on vibe-view’s VTK stack.

qc-input-library

ORCA conventions and real inputs

Golden files for the ORCA writer’s style; generated inputs can be contributed back.

vibe-queue

vq submit, fetch and status

Optional [queue] extra, same shape as vibe-view’s.

Two conditions attach. vibeqc_naming ships inside the vibe-qc wheel today, so it must become a separately installable pure-Python distribution before the sketcher can depend on it (cross-repository ask, section 5). The vibeview core package depends on PyVista and VTK, so the sketcher uses it only inside an optional [view] extra and writes QVF through qvf-writer.

2.5 The name

Decided: vibe-sketch, package vibesketch, command vibe-sketch, document extension .vsk. The family is vibe-qc, vibe-view and vibe-queue, with packages vibeqc, vibeview and vq. The options that were weighed:

Name

Package, CLI

Notes

vibe-sketch

vibesketch, vibe-sketch

Reads like vibe-view: a verb-shaped noun that says what it does. No collision with a chemist’s acronyms. Chosen.

vibe-qs

vibeqs, vibe-qs

“Quantum sketcher” is accurate but opaque to first-time visitors, and vqs sits next to vq in the shell.

vibe-ms

vibems, vibe-ms

To a chemist, MS is mass spectrometry. Avoid.

vibe-draw

vibedraw

Generic; nothing says chemistry.

Codename pool, if the maintainer wants the “Person’s Animal” form the siblings use: structure drawing, nomenclature and cheminformatics pioneers, which no sibling product has claimed. The codename choice stays the maintainer’s.

3. Architecture

 browser or Electron                         Python package: vibesketch
 +---------------------------------+          +----------------------------------+
 | shell  (TypeScript, Vite)       |  HTTP +  | server  (FastAPI, uvicorn)       |
 |  canvas adapter                 |  WS      |   document store, revisioned     |
 |    Ketcher + Indigo (WASM)      |<-------->|   chem      RDKit                |
 |  compute panel                  |          |   naming    vibeqc_naming        |
 |  scheme and style panel         |          |   render    SVG, PNG, PDF, chemfig|
 |  3D peek (Miew or 3Dmol)        |          |   inputs    orca, vibeqc, qcschema|
 +---------------------------------+          |   export    qvf-writer, vibe-view |
                                              |   queue     vq (optional)        |
 agents: MCP server, REST, Python SDK, CLI -->|                                  |
                                              +----------------------------------+

Four principles:

  1. API first. The browser is one client of the same API that agents use. Nothing is reachable only through a button.

  2. The document is the unit. One JSON file with a versioned schema. The canvas state (KET) is embedded verbatim for lossless round trips, and a normalized layer carries what the compute side needs: species with SMILES, InChIKey, charge, multiplicity and cached conformers; reactions with roles, arrows, conditions and yields; job specifications; style; provenance.

  3. Chemistry in Python, drawing in the browser. Indigo covers the offline canvas; everything that produces a number or a file for a calculation goes through RDKit and the writers on the server, where it is testable.

  4. Degrade without optional pieces. No vibe-qc, no vibe-queue, no vibe-view installed: the corresponding features hide behind install hints, the pattern vibe-view already uses.

3.1 Document model, first cut

{
  "schema": "vibe-sketch/1",
  "revision": 17,
  "canvas": {"format": "ket", "data": {}},
  "species": [
    {"id": "m1", "label": "1", "smiles": "CCO", "inchikey": "LFQSCWFLJHTTHZ-UHFFFAOYSA-N",
     "charge": 0, "multiplicity": 1,
     "name": {"value": "ethanol", "source": "vibeqc_naming", "confidence": "high"},
     "conformers": [{"method": "etkdg+mmff94", "xyz_angstrom": []}]}
  ],
  "reactions": [
    {"id": "r1", "reactants": ["m1"], "reagents": [], "products": ["m2"],
     "arrow": "forward", "conditions": ["Pd(PPh3)4, K2CO3", "dioxane, 80 C"], "yield": "87%"}
  ],
  "jobs": [
    {"species": "m1", "program": "orca",
     "spec": {"task": "opt+freq", "method": "B3LYP", "basis": "def2-TZVP", "aux_basis": "def2/J",
              "approximation": "RIJCOSX", "dispersion": "D4",
              "solvent": {"model": "CPCM", "name": "water"}, "resources": {"nprocs": 8, "maxcore_mb": 3000}}}
  ],
  "style": {"preset": "acs-1996"},
  "provenance": {"app": "vibe-sketch 0.1.0", "created": "2026-10-13T00:00:00Z", "edits": []}
}

The job specification is program neutral. Each writer maps it and refuses what it cannot express rather than guessing, the stance vibe-qc’s QCSchema adapter takes. Charge is the sum of formal charges on the drawing; multiplicity defaults from the radical count and is always editable, because the drawing cannot know the spin state of a metal centre.

3.2 API surface, version 1

  • Python SDK. Document with load, save, from_smiles, from_name, from_molfile, from_cdxml, add_species, add_reaction, layout, embed_3d, name, render, write_input, to_qvf, submit.

  • CLI. vibe-sketch serve | desktop | render | input | convert | name | mcp.

  • REST. Documents with optimistic concurrency (If-Match on the revision), species and reaction sub-resources, render, inputs, chem/embed3d, chem/name, export/qvf, jobs/submit. OpenAPI is served, so an agent can read the contract instead of guessing it.

  • WebSocket. Document events, so the browser reflects an agent’s edit within a frame and the agent sees the human’s.

  • MCP server. The same operations as tools, so a Claude or Codex session can sketch, name, render, write inputs and submit without a browser.

Human and agent edit the same document through the server’s revision counter. The browser pushes debounced canvas changes; an agent’s patch names the revision it read; a stale patch gets a conflict and re-reads. That is enough for version 1; operational transforms are not.

3.3 Rendering

The canvas is what you see while drawing. Exports render on the server from the normalized document, so a batch of fifty schemes renders the same way from the CLI as from the button: style presets (ACS 1996 first, then RSC and Wiley), compound numbering, conditions above and below arrows, yields, multi-step layout. SVG is native; PNG through RDKit’s Cairo backend; PDF through a BSD-licensed SVG-to-PDF path chosen in the spike; CDXML through Indigo; chemfig from our own emitter.

3.4 Desktop

Electron, forked from vibe-view’s shell: the CLI writes a handshake file, the shell finds or creates a managed venv, probes the interpreter, starts the server on a free port and loads it. macOS first, as vibe-view did; the update feed lives under the same site, in its own path. Later, one shell hosts vibe-view and the sketcher as tabs.

3.5 Repository layout

vibe-sketch/
  AGENTS.md  CLAUDE.md  CODEX.md  CONTRIBUTING.md  LICENSE  README.md
  pyproject.toml              vibesketch: core = pydantic, rdkit, fastapi, uvicorn, qvf-writer
  schema/                     document JSON schema, versioned
  src/vibesketch/
    document/                 model, KET bridge, MOL/RXN/SDF/CDXML import and export
    chem/                     RDKit services: layout, embed3d, stereo, properties
    naming/                   vibeqc_naming wrapper and fallbacks
    render/                   styles, SVG, PNG, PDF, chemfig
    inputs/                   registry; orca.py, vibeqc.py, qcschema.py
    server/                   FastAPI app, WebSocket, static bundle
    agent/                    MCP server
    cli.py
  web/                        TypeScript shell, Ketcher adapter, Vite build
  electron/                   desktop shell
  docs/                       Sphinx, same toolchain and theme as vibe-view
  tests/                      pytest; Playwright for the served UI
  scripts/                    install, update, release artifacts, changelog fold

Optional extras: [queue] for vq, [view] for vibe-view, [opsin] if adopted, [all], [test], [dev], [docs].

4. Roadmap

Phases are ordered by what unblocks what. Durations assume agent-driven development with the maintainer reviewing; they are estimates, not dates. Each work package names a tier so the model can be chosen: A needs architectural judgement or novel chemistry logic, B is substantial implementation against a fixed contract, C is well specified and test-anchored. Every open work package is one or more issues in the tracker, labelled with its phase and tier, and any agent may take one.

Where the work stands (2026-10-15)

WP

State

Issues

0.1 to 0.5

Done

1.1 to 1.7

Done; two bugs open

#7 (hidden-pane zoom), #8 (V2000 atom limit)

1.5, names

Waits on vibe-qc #536 and #537

#2

2.1 to 2.6

Done; automated browser and MCP exit covered, real-program run open

#16

2.7

Partly implemented: source shell, runtime installer and macOS launcher available; desktop workflow and delivery tasks remain

#9 (open and save), #10 (Electron runtime), #11 (desktop), #12 (installer), #13 (file types), #14 (acceptance)

3.1

Open

#20 (scheme layout), #21 (render as drawn)

3.2

Open

#22 (PNG and PDF, needs a backend decision), #23 (styles)

3.3

Open, needs ChemDraw samples

#24

3.4

Open

#25

3.5

Open

#26

3.6

Open

#17 (FIRE), #18 (database-driven clean-up, needs a data-source decision)

3.7

Open

#19

4.1

Open

#3 (vibe-qc jobs as QVF containers), #27 (submit a group)

4.2

Open, needs a storage decision

#28

4.3

Open

#29

4.4

Open

#30

Continuous

Open

#6 (formatting), #31 (accessibility), #32 (notices), #33 (releases)

Phase 0: decide and spike (one to two weeks)

WP

Deliverable

Exit criterion

Tier

0.1

Name, licence, hosting decided by the maintainer

Done 2026-10-13; recorded in README.md and LICENSE

maintainer

0.2

Repository skeleton copied from vibe-view: AGENTS.md, privacy hook, Ruff and strict mypy from the first module, CI with lint and a smoke test, changelog fragments, codename module

Green pipeline on an empty package

B

0.3

Canvas spike: Ketcher standalone inside a Vite shell, toolbar replaced, custom template, KET round trip of a stereo-bearing reaction with text and brackets

A written go/no-go against section 2.2’s criteria

A

0.4

Document schema v1 and the writer interface, with JSON schema and two toy writers

Schema validates fixtures; writers refuse unsupported specs with a reason

A

0.5

Cross-repository asks filed (section 5)

Issues exist

C

Phase 1: sketch (four to six weeks)

WP

Deliverable

Tests

Tier

1.1

Browser app: shell, canvas adapter, open and save .vsk, undo through the engine

Playwright smoke

B

1.2

Import SMILES, MOL, SDF, RXN, CDXML, and a name through structure_from_name and fallbacks

Round-trip fixtures

B

1.3

Export SVG, PNG, MOL, SMILES, InChI from the canvas and from the server

Structural SVG comparison, not pixels

B

1.4

Clean-up and layout presets: one button, predictable result

Fixture layouts

B

1.5

Properties panel: formula, mass, charge, suggested multiplicity, live IUPAC name with confidence badge

Unit tests over the naming wrapper, including the no-vibeqc-naming branch

A for the multiplicity logic, B otherwise

1.6

Python SDK, CLI and REST for everything above; OpenAPI served; WebSocket events

Contract tests generated from the OpenAPI document

B

1.7

Manual pages: quickstart, drawing, formats, API

Docs build strict

C

Exit: a chemist can draw a molecule, name it, and export a clean SVG from the browser and from the CLI, with no vibe-qc installed.

Phase 2: compute (about four weeks)

WP

Deliverable

Tests

Tier

2.1

3D embedding: ETKDG with MMFF94, stereo preserved, conformer cache in the document

Stereo round trips SMILES to 3D to CIP labels

A

2.2

ORCA writer: keyword model for method, basis, auxiliary basis, RIJCOSX, dispersion, CPCM and SMD, tasks SP, Opt, Freq, Opt+Freq, TDDFT, NMR; %pal and %maxcore; constraints

Golden files styled after qc-input-library

A for the model, B for the writer

2.3

vibe-qc writer: Python script from the vibe-view templates, plus QCSchema JSON

Scripts import and parse; QCSchema validates

B

2.4

QVF export through qvf-writer; Open in vibe-view; 3D peek in the panel

QVF conformance script passes

B

2.5

vibe-queue submit and status in the compute panel, optional extra

Mocked vq

B

2.6

MCP server exposing the SDK

Tool-call tests

A

2.7

Electron desktop app, macOS first; updater feed path

Packaged app opens a .vsk

B

Exit: sketch to ORCA input and to a vibe-qc run in two clicks or one API call; an agent does the same through MCP. Automated workflow criterion met (#15): from imported ethanol and the default B3LYP/def2-SVP settings, the browser writes ORCA input in one click, then choosing vibe-qc and submitting takes two actions. tests/test_phase2_exit.py checks the real browser, embedding, writers and server, plus the MCP tool sequence, against a stand-in queue. CI requires both tests. Execution with the actual external programs remains #16; remaining desktop workflow and delivery tasks are tracked in WP 2.7. The source desktop shell is already available.

Phase 3: publish (about four weeks)

WP

Deliverable

Tier

3.1

Reaction schemes: arrows (forward, equilibrium, retrosynthetic, resonance), conditions, yields, compound numbering, multi-step layout

A

3.2

Style presets ACS 1996, RSC, Wiley; bond length, line width, fonts, hash spacing; PDF export

B

3.3

CDXML export and import fidelity pass against ChemDraw-produced files

B

3.4

chemfig emitter

A

3.5

Batch rendering CLI; docs chapter on figures for papers

C

3.6

Clean-up from a reference table: ideal bond lengths, angles and ring templates per atom environment, non-bonded repulsion, stereo kept, minimised with FIRE (Bitzek et al., 2006), following the shared scope decision

A

3.7

Constrained 3D relaxation with FIRE on RDKit force fields

B

Exit: a scheme drawn here appears in a manuscript without touching another program.

Phase 4: reactions as jobs (about four weeks)

WP

Deliverable

Tier

4.1

Job sets: one job per species in a reaction, shared specification, manifest; submit as a group

B

4.2

Results back onto the scheme: read QVF energies, compute reaction energies with the CODATA factors vibe-view uses, annotate the arrow

A

4.3

ORCA NEB-TS endpoints from reactant and product sketches; vibe-qc equivalent where supported

A

4.4

Reaction energy table export

C

Phase 5: inorganic and crystals (later, scope to be decided)

  • Coordination complexes: dative and haptic bonds, metal centres with explicit oxidation state and spin, which the 2D engine only partly models. Design first.

  • A crystal builder that is a form and a 3D preview rather than a canvas: space group and Wyckoff positions or a CIF, supercell and slab through the code vibe-view already has, adsorbate placement from a sketched molecule, periodic inputs for vibe-qc. Names through name_solid_from_atoms.

Continuous tracks

Accessibility of the served UI, licence compliance check in CI, release process and codename catalogue mirrored from vibe-view, cross-repository pin changes announced when create_app style contracts move.

5. Cross-repository asks

Filed on 2026-10-14 (WP 0.5). A feature or decision another project owns is asked for in that project’s tracker; vibe-sketch’s own side of each interaction is tracked here: the hand-off to vibe-view (#1), naming through vibeqc_naming (#2) and keeping the sketch with its result archive (#3).

  • vibe-qc. Publish vibeqc_naming as its own pure-Python distribution (vibe-qc #536). Accept explicit bonds and CIP descriptors on a MolecularGraph so systematic names can carry R/S and E/Z (vibe-qc #537). external.name_from_rdkit is confirmed a silent no-op: RDKit has no MolToIUPACName (vibe-qc #538).

  • vibe-view. A Sketch entry point that opens the sketcher when the [sketch] extra is installed, alongside the viewer’s own name/SMILES input and 3D builder (vibe-view #77). Later, the v3.0 plugin API would allow true embedding.

  • qvf. Whether a result archive may carry the 2D sketch (the .vsk document, or an SVG) that produced it, so a .qvf opened months later still shows its scheme (qvf #10). Decided in qvf v0.2.0: vendor sections carry the document, and the scheme, a preview, species identity and job sets have canonical kinds, which vibe-sketch writes (vibe-sketch #4).

  • qc-input-library. Use as golden fixtures; contribute generated ORCA inputs back under its naming rules.

  • vibe-queue. Nothing new for phases 1 to 3.

6. Risks

Risk

Mitigation

Ketcher’s React stack is heavy or its upgrades churn our adapter

The adapter is the only import site; the spike measures bundle size; Apache-2.0 permits pinning or forking

Indigo WebAssembly load time on first open

Lazy-load Indigo; drawing works before it arrives

2D to 3D stereo errors

CIP labels compared before and after embedding in tests; refuse to export when they differ

Multiplicity guessed wrong for metals and radicals

Always visible, always editable, never silently defaulted for d-block centres

Multi-step scheme layout is hard to make beautiful

Phase 3 only after phases 1 and 2 ship; manual placement always wins over the layout engine

vibeqc_naming returns no systematic name for many drawn molecules

The confidence badge is honest; the sketcher becomes the engine’s test bed and feeds it cases

Agents and humans overwrite each other

Revisioned documents with conflict responses from day one

7. Decisions needed from the maintainer

  1. ~~The name.~~ Decided: vibe-sketch (section 2.5).

  2. ~~The licence.~~ Decided: proprietary for now, MPL-2.0 possible later.

  3. Go or no-go on Ketcher after the Phase 0 spike. The spike recommends go, with Ketcher 3.18.0 and its separate-WebAssembly, no-render build (docs/spike_canvas.md).

  4. ~~Hosting.~~ Decided: the private GitLab project is canonical. A public mirror under the vibe-qc organisation only follows an open-source release.

  5. Whether a contributor licence agreement is required before the first external contribution. Moot while every contributor is the maintainer or an agent working for the maintainer; decide before opening the code.

  6. ~~The codename pool.~~ Approved: structural-chemistry pioneers in docs/codenames.md, with Couper’s Coati reserved for the first minor release. The release version has not been selected.

  7. ~~Browser and desktop notices.~~ Approved: retain the current Indigo WASM with its exact corresponding source and full notices, including reviewed supplements for incomplete npm distributions (docs/license.md). Builds now enforce this inventory. Python and RDKit install separately; bundling them would require their additional notices to be reviewed.

  8. ~~The CI trigger policy.~~ Confirmed: full gates on merge requests, main and release candidates; release publishes the qualified tree. The documentation, versioned-wheel and desktop-feed paths are approved in docs/release_process.md. Current sketch/compute features and complete desktop delivery define the first release scope.

Sources consulted for the engine comparison