|
245 | 245 | {"id":"bd-sgm7","title":"Share link single-click: auto-connect without requiring manual project setup","description":"Make share links work in a single click regardless of whether the receiving user already has the project in their settings. Currently, new recipients must manually click 'Connect' in the ProjectSelector. The new flow should auto-create the project entry and connect immediately. Also add project name to the share URL for better UX. Plan: claude-notes/plans/2026-03-30-share-link-single-click.md","status":"closed","priority":1,"issue_type":"feature","created_at":"2026-03-30T16:47:27.895709Z","created_by":"cscheid","updated_at":"2026-03-30T16:56:38.302807Z","closed_at":"2026-03-30T16:56:38.302195Z","close_reason":"Implemented: share links now auto-create project entries and connect immediately. Added project name to share URL. Removed pendingShareData plumbing. All tests pass.","source_repo":".","compaction_level":0,"original_size":0} |
246 | 246 | {"id":"bd-sh4h","title":"L9 follow-up: Atom 1.0 emission","description":"L9 emits RSS 2.0 only (with the atom:link rel=self extension element, matching Q1). A pure Atom 1.0 alternative would be a forward feature for users who prefer it. Likely shape: feed.format: rss|atom on the listing config; new templates under feed/templates/atom/.","status":"open","priority":4,"issue_type":"feature","created_at":"2026-05-08T17:33:49.689660Z","created_by":"cscheid","updated_at":"2026-05-08T17:33:49.689660Z","source_repo":".","compaction_level":0,"original_size":0,"dependencies":[{"issue_id":"bd-sh4h","depends_on_id":"bd-o90m","type":"discovered-from","created_at":"2026-05-08T17:33:49.689660Z","created_by":"cscheid","metadata":"{}","thread_id":""}]} |
247 | 247 | {"id":"bd-si8b","title":"Evaluate Temml as a third math engine for HTML output","description":"MathJax (default) and KaTeX shipped in bd-w5ov. Temml is a KaTeX fork that emits MathML directly (~80 KB bundle, native browser rendering, best a11y story). MathML support is now near-universal (Chromium since 2023, WebKit + Firefox always).\n\nInvestigate whether to add Temml as a third 'html-math-method' option:\n- Output contract differs from MathJax/KaTeX (MathML in markup vs TeX delimiters).\n- Could be added as a parallel arm in MathEngine / from_meta() / render_math_slot().\n- Decide: does q2 ship TeX-source delimiters and let Temml convert client-side, or do server-side TeX→MathML conversion at render time?\n\nOut of scope: making Temml the default. Default stays MathJax for parity with Quarto 1.","status":"open","priority":3,"issue_type":"task","created_at":"2026-05-04T23:58:18.920001Z","created_by":"cscheid","updated_at":"2026-05-04T23:58:18.920001Z","source_repo":".","compaction_level":0,"original_size":0,"dependencies":[{"issue_id":"bd-si8b","depends_on_id":"bd-w5ov","type":"discovered-from","created_at":"2026-05-04T23:58:18.920001Z","created_by":"cscheid","metadata":"{}","thread_id":""}]} |
| 248 | +{"id":"bd-sizl","title":"q2-debug placeholder loses CustomNode type_name","description":"q2-debug's Block/Inline dispatchers (`hub-client/src/components/render/q2-debug/dispatchers.tsx`) currently render the miss path as `<span>Not registered: CustomBlock</span>` (or `<div>...</div>` for blocks) — using only `args.node.t`, which discards the CustomNode `type_name` discriminator.\n\nFor CustomBlock / CustomInline AST nodes, the rendered debug placeholder should include the type_name so developers can see *which* CustomNode hit the fallback path. Example: `Not registered: CustomBlock(Callout)` instead of `Not registered: CustomBlock`.\n\n~5 LOC change. Pattern: in the dispatcher, when `args.node.t === 'CustomBlock' || args.node.t === 'CustomInline'`, append the type_name to the displayed text.\n\n**Why**: q2-preview's parallel placeholder (`q2-preview/dispatchers.tsx` post-Plan-2C) already includes the tag name; q2-debug's debug-mode visualization should be at least as informative.\n\n**Discovered**: while reviewing Plan 2C (q2-preview customnode rendering, `claude-notes/plans/2026-05-09-q2-preview-plan-2c-customnode-rendering.md`). Not in 2C scope — q2-debug is a separate format. Filing as a follow-up.","status":"open","priority":3,"issue_type":"task","created_at":"2026-05-10T09:43:10.869153Z","created_by":"gordon","updated_at":"2026-05-10T09:43:10.869153Z","source_repo":".","compaction_level":0,"original_size":0} |
248 | 249 | {"id":"bd-sr73","title":"Re-measure trace size on a fixture that exercises a real engine (jupyter/knitr supporting_files)","description":"bd-5qnj's provisional size budgets (≤100 KB compressed for CI fixtures, ≤1 MB for user-attached bug reports) were measured on markdown-engine fixtures where `engine_capture` is `None`. After merging bd-45yw (replay engine recording), traces from real engine runs additionally carry `engine_capture.result.supporting_files` — for jupyter/knitr documents this can include base64-encoded PNG plots, data-frame snapshots, etc.\n\nInvestigate:\n- Capture a representative jupyter trace from a real notebook (a plot + a small dataset).\n- Measure: total `latest.json.gz` size, `engine_capture.result` share, supporting_files byte share.\n- Decide whether the 100 KB CI-fixture budget still holds, or whether engine_capture needs its own size accommodation (separate file? on-disk gzip-of-gzip is unhelpful for already-compressed PNGs).\n\nReferences:\n- claude-notes/plans/2026-05-03-trace-size-for-replay.md (Phase 3 outstanding follow-up)\n- claude-notes/plans/5qnj-trace-size-investigation/measurements.md (current measurements; markdown engine only)\n- crates/quarto-trace/src/lib.rs::EngineCapture (where supporting_files content lives)","status":"open","priority":2,"issue_type":"task","created_at":"2026-05-03T23:28:59.411296Z","created_by":"cscheid","updated_at":"2026-05-03T23:28:59.411296Z","source_repo":".","compaction_level":0,"original_size":0,"dependencies":[{"issue_id":"bd-sr73","depends_on_id":"bd-5qnj","type":"discovered-from","created_at":"2026-05-03T23:28:59.411296Z","created_by":"cscheid","metadata":"{}","thread_id":""}]} |
249 | 250 | {"id":"bd-swpy","title":"Sidebar/navbar/footer hrefs not relativized to current page in nested directories","description":"Surfaced building examples/websites/03-nested-sidebar (bd-2jwk). resolve_href_for_html in crates/quarto-core/src/transforms/navigation_href.rs returns profile.output_href verbatim, which is project-root-relative. Body links go through resolve_doc_relative_href + ResourceResolverContext::page_url_for, so they get relativized correctly (e.g. inside _site/guide/installation.html the body link to index.qmd renders as 'index.html', not 'guide/index.html'). But sidebar / navbar / page-footer / page-nav hrefs use resolve_href_for_html and skip the resolver, producing absolute-looking project-relative paths like 'guide/index.html' from within a page at depth 1, which a browser resolves as 'guide/guide/index.html'. Reproduces in examples/websites/03-nested-sidebar/_site/guide/installation.html and reference/api.html. Fix plan: claude-notes/plans/2026-04-29-bd-swpy-nav-href-relativization.md (thread ResourceResolverContext through resolve_href_for_html + four Render transforms, route hits through page_url_for matching the body-link path).","status":"closed","priority":1,"issue_type":"bug","created_at":"2026-04-29T14:07:50.403220Z","created_by":"cscheid","updated_at":"2026-04-29T15:10:53.397840Z","closed_at":"2026-04-29T15:10:53.397537Z","close_reason":"Threaded ResourceResolverContext through resolve_href_for_html in commit aa50d29e. All four Render transforms (sidebar, navbar, footer, page-nav) now route hits through page_url_for, mirroring the body-link path. Native renders produce page-relative URLs (deployment-portable); hub-client vfs_root mode produces absolute /{vfs_root}/... URLs (intended). 8081 workspace tests + cargo xtask verify pass. Closes bd-swpy.","source_repo":".","compaction_level":0,"original_size":0,"dependencies":[{"issue_id":"bd-swpy","depends_on_id":"bd-0tr6","type":"parent-child","created_at":"2026-04-29T14:07:50.403220Z","created_by":"cscheid","metadata":"{}","thread_id":""},{"issue_id":"bd-swpy","depends_on_id":"bd-2jwk","type":"discovered-from","created_at":"2026-04-29T14:07:50.403220Z","created_by":"cscheid","metadata":"{}","thread_id":""}]} |
250 | 251 | {"id":"bd-t3ny","title":"Publish command scaffolding + gh-pages provider","description":"Build the scaffolding for Quarto 2's `publish` command (mirroring Quarto 1's organization in src/publish/) and ship the `gh-pages` endpoint end-to-end. All other providers (quarto-pub, netlify, posit-connect, posit-connect-cloud, confluence, huggingface) and single-document publishing are explicitly deferred.\n\nPlan: claude-notes/plans/2026-05-03-publish-command-and-gh-pages.md\n\nStatus: design draft — pending user review before implementation.","status":"completed","priority":1,"issue_type":"epic","created_at":"2026-05-03T13:47:55.362968Z","created_by":"cscheid","updated_at":"2026-05-03T15:18:38.758969Z","source_repo":".","compaction_level":0,"original_size":0} |
|
0 commit comments