Update beads export for daz-script-server-p1af notes

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: ghirpara

.beads/issues.jsonl

@@ -142,7 +142,7 @@
 {"_type":"issue","id":"daz-script-server-jnbm","title":"Verify getRenderElementObjects()[3] Environment holder assumption via readback","description":"apply_hdri_environment() and DazRenderSettings' environment setters (_render.py) assume App.getRenderMgr().getRenderElementObjects()[3] is always the Iray Environment Options holder. This was confirmed against exactly one live DAZ Studio 4.x instance during design research for daz-script-server-x6sy. If that index is wrong for a different DAZ Studio version, or reordered, or on the SDK6/Qt6 build this repo also supports, every environment write silently no-ops (matches the existing if (!holder) return; / if (p) ... pattern already used by _set_iray_property) and apply_hdri_environment() returns None as if it succeeded -- the caller has no way to know the HDRI was never applied.\n\nFlagged by the final whole-branch review of the HDRIEnvironment branch (Important #2, non-blocking) as a real gap worth a follow-up rather than a merge blocker, since it's an inherited pattern from pre-existing code (_set_iray_property has the same silent-no-op shape) rather than a new regression.\n\nSuggested fix: add a post-apply readback in apply_hdri_environment (e.g. re-read 'Environment Intensity' via the already-present but currently test-only DazRenderSettings._get_environment_property and compare against what was just set), raising a clear error on mismatch -- mirroring the existing precedent in DazRenderSettings.set_render_engine, whose docstring notes it 'returns only after exact readback' and raises RenderError on disagreement.","status":"closed","priority":3,"issue_type":"task","assignee":"G.Hirpara","owner":"ghirpara@yahoo.com","created_at":"2026-08-08T03:22:50Z","created_by":"G.Hirpara","updated_at":"2026-08-10T01:46:46Z","started_at":"2026-08-10T01:44:20Z","closed_at":"2026-08-10T01:46:46Z","close_reason":"Added post-apply readback verification (Environment Intensity) in apply_hdri_environment; raises RenderError on holder-unavailable or mismatch instead of silently no-oping","dependency_count":0,"dependent_count":0,"comment_count":0}
 {"_type":"issue","id":"daz-script-server-x6sy","title":"Research and implement dazpy.lighting HDRIEnvironment (IBL/dome lighting)","description":"GitHub issue #31 proposed dazpy.lighting.HDRIEnvironment alongside ThreePointLightSetup and SetLightColor. ThreePointLightSetup shipped (daz-script-server-p1af); SetLightColor needed no new code (already covered by DazLight.set_color). HDRIEnvironment was explicitly deferred during design (docs/superpowers/specs/2026-08-07-dazpy-lighting-design.md) because no dome/environment-map DazScript primitive currently exists in dazpy -- this needs research into what DAZ Studio actually exposes for Iray environment/IBL lighting (DzUberEnvironmentShader or similar) before a design can be written.","status":"closed","priority":3,"issue_type":"feature","owner":"ghirpara@yahoo.com","created_at":"2026-08-07T12:19:13Z","created_by":"G.Hirpara","updated_at":"2026-08-10T01:49:50Z","closed_at":"2026-08-10T01:49:50Z","close_reason":"Shipped: design spec + plan (docs/superpowers/specs|plans/2026-08-07-dazpy-hdri-environment*.md), HDRIEnvironment dataclass, apply_hdri_environment, validated environment-map setter, package exports, and readback verification (daz-script-server-jnbm) — all landed across commits 691d04c..b62ca4c","dependency_count":0,"dependent_count":0,"comment_count":0}
 {"_type":"issue","id":"daz-script-server-okpk","title":"Add coordinate-system \u0026 vector math conversion utilities","description":"GitHub issue #31 (item 4): Daz Studio uses Y-up with idiosyncrasies (e.g. Genesis 9 facing +Z, Y-rotation inversion on cameras) that force every downstream integration (Blender, Unreal) to reimplement coordinate conversion. Proposed dazpy.math helper module with functions like daz_yup_to_blender_zup() and fix_camera_orientation(). dazpy/math3.py currently provides Vec3/Quat/BoundingBox math primitives but no coordinate-space conversion helpers -- this would build on top of those.","status":"closed","priority":3,"issue_type":"feature","owner":"ghirpara@yahoo.com","created_at":"2026-08-07T10:28:25Z","created_by":"G.Hirpara","updated_at":"2026-08-10T02:42:17Z","closed_at":"2026-08-10T02:42:17Z","close_reason":"Added AxisRemap to dazpy/math3.py: apply_vec3/apply_quat/apply_bbox with reflection rejection, Y_UP_TO_Z_UP preset, exported from dazpy package. Wired into tests.py unit runner.","dependency_count":0,"dependent_count":0,"comment_count":0}
-{"_type":"issue","id":"daz-script-server-p1af","title":"Add domain submodules (cinematics, lighting, materials, poses)","description":"GitHub issue #31 (item 2) proposes packaging common DazScript macros into first-class Python submodules to avoid downstream users writing raw DazScript for common scene-choreography tasks: dazpy.cinematics (OrbitCamera, CinematicShot, FrameSubject), dazpy.lighting (ThreePointLightSetup, HDRIEnvironment, SetLightColor), dazpy.materials (IrayMaterial, TextureMap, SurfaceProperty), dazpy.poses (ApplyPose, ResetTransforms, ZeroFigure). None of these modules currently exist in dazpy/. Should build on existing DazNode/DazCamera/DazLight/DazMaterial primitives rather than raw script strings.","notes":"ThreePointLightSetup shipped on branch feature/dazpy-lighting (design: docs/superpowers/specs/2026-08-07-dazpy-lighting-design.md; plan: docs/superpowers/plans/2026-08-07-dazpy-lighting.md). SetLightColor needed no new code (DazLight.set_color already covers it). HDRIEnvironment split off to daz-script-server-x6sy (CLOSED). Yaw-sign correctness in _look_at_euler needs live DAZ Studio verification before full trust -- tracked in daz-script-server-bu86. Cinematics/materials/poses submodules from GitHub #31 remain separate future work.\n\n2026-08-10 GH #31 status audit: lighting submodule is the only domain submodule with any code shipped (ThreePointLightSetup, HDRIEnvironment, SetLightColor). dazpy.cinematics (OrbitCamera, CinematicShot, FrameSubject), dazpy.materials (IrayMaterial, TextureMap, SurfaceProperty), and dazpy.poses (ApplyPose, ResetTransforms, ZeroFigure) do not exist yet in dazpy/ -- none of that work has started. This is now the only open item from GH #31 (items 1/4/5 shipped, item 3 won't-fix per daz-script-server-0p8).","status":"in_progress","priority":3,"issue_type":"feature","assignee":"G.Hirpara","owner":"ghirpara@yahoo.com","created_at":"2026-08-07T10:28:24Z","created_by":"G.Hirpara","updated_at":"2026-08-11T02:18:31Z","started_at":"2026-08-07T10:32:12Z","dependency_count":0,"dependent_count":0,"comment_count":0}
+{"_type":"issue","id":"daz-script-server-p1af","title":"Add domain submodules (cinematics, lighting, materials, poses)","description":"GitHub issue #31 (item 2) proposes packaging common DazScript macros into first-class Python submodules to avoid downstream users writing raw DazScript for common scene-choreography tasks: dazpy.cinematics (OrbitCamera, CinematicShot, FrameSubject), dazpy.lighting (ThreePointLightSetup, HDRIEnvironment, SetLightColor), dazpy.materials (IrayMaterial, TextureMap, SurfaceProperty), dazpy.poses (ApplyPose, ResetTransforms, ZeroFigure). None of these modules currently exist in dazpy/. Should build on existing DazNode/DazCamera/DazLight/DazMaterial primitives rather than raw script strings.","notes":"dazpy.poses shipped (apply_pose, reset_transforms, zero_figure) -- see docs/superpowers/specs/2026-08-10-dazpy-poses-design.md and docs/superpowers/plans/2026-08-10-dazpy-poses.md. zero_figure defaults to include_props=False after final review found the True/apply_full path could zero the figure's root Scale/transform via DzNode's generic property enumeration -- True remains available as an explicit opt-in. Remaining GH #31 domain submodules: dazpy.cinematics, dazpy.materials.","status":"in_progress","priority":3,"issue_type":"feature","assignee":"G.Hirpara","owner":"ghirpara@yahoo.com","created_at":"2026-08-07T10:28:24Z","created_by":"G.Hirpara","updated_at":"2026-08-11T02:52:39Z","started_at":"2026-08-07T10:32:12Z","dependency_count":0,"dependent_count":0,"comment_count":0}
 {"_type":"issue","id":"daz-script-server-xusn","title":"Pool DazClient connections via requests.Session + add close()/context-manager","description":"DazClient currently issues each HTTP call via bare requests.post()/get() (module-level function calls), creating a fresh TCP connection per request instead of reusing a pooled connection. AsyncDazClient (added in 2.9.0, dazpy.aio) uses a persistent httpx.AsyncClient with close()/async-context-manager support. Bring DazClient to parity: back it with a requests.Session for connection pooling/keep-alive, and add close()/__enter__/__exit__ so sync callers can also do 'with DazClient() as client:'.","status":"closed","priority":3,"issue_type":"task","assignee":"G.Hirpara","owner":"ghirpara@yahoo.com","created_at":"2026-08-07T02:33:34Z","created_by":"G.Hirpara","updated_at":"2026-08-07T02:36:25Z","started_at":"2026-08-07T02:33:38Z","closed_at":"2026-08-07T02:36:25Z","close_reason":"DazClient now uses a pooled requests.Session for all HTTP calls (post/get/delete, including streaming), and gained close()/__enter__/__exit__ for parity with AsyncDazClient. Updated TestErrorMapping in tests/test_dazpy.py to mock the session instead of module-level requests.post; added close()/context-manager tests. Full test_dazpy.py suite (540 tests) + test_dazpy_aio.py (21 tests) pass.","dependency_count":0,"dependent_count":0,"comment_count":0}
 {"_type":"issue","id":"daz-script-server-0p8","title":"Replace raw dict returns with typed models (dataclasses/Pydantic)","description":"dazpy methods currently return raw dicts for structured values (e.g. {x,y,z,w} quaternions, bounding boxes, scene snapshots) rather than typed objects, so callers get no IDE autocompletion or runtime validation. math3.py already has Vec3/Quat/BoundingBox for math ops -- evaluate extending those (or adding lightweight dataclasses/Pydantic models) as the return type for node/camera/light/material property accessors across dazpy/_node.py, _camera.py, _light.py, _material.py, etc.","status":"deferred","priority":3,"issue_type":"feature","assignee":"G.Hirpara","owner":"ghirpara@yahoo.com","created_at":"2026-08-06T23:57:57Z","created_by":"G.Hirpara","updated_at":"2026-08-07T10:21:47Z","started_at":"2026-08-07T10:19:20Z","dependency_count":0,"dependent_count":0,"comment_count":0}
 {"_type":"issue","id":"daz-script-server-a5o","title":"FaceID face-identity pass doesn't preserve hair color","description":"IPAdapter FaceID's embedding (docs/examples/rendering/sprite_matrix/) encodes facial features only, not hair color. Since the SAM-refined face-detailer crop covers hair as well as face (needed to avoid a hairline color seam, see bbox_dilation), and the pass no longer starts from real source pixels (SetDefaultImageForSEGS was removed), hair color is unconstrained during refinement and can drift from the source. Confirmed live on a grey-haired test character (jason_a): hair rendered brown/blonde across the entire tested denoise (0.15-0.35) x faceid_weight (0.8-1.2) grid, independent of both knobs. User explicitly chose to ship with this documented as a known limitation (README.md, config.py) rather than pause to fix it. Filed as follow-up in case it becomes worth revisiting -- e.g. a secondary hair-color-only conditioning signal, or constraining just a hair sub-region to real pixels while still FaceID-conditioning the face.","status":"closed","priority":3,"issue_type":"bug","owner":"ghirpara@yahoo.com","created_at":"2026-08-06T02:41:10Z","created_by":"G.Hirpara","updated_at":"2026-08-07T01:53:31Z","closed_at":"2026-08-07T01:53:31Z","close_reason":"Confirmed resolved via live testing against jason_a and abby_b, following the daz-script-server-3os rebuild (single-pass + lineart composite, replacing FaceDetailer/IPAdapterFaceID) and the r5br negative-prompt/Canny-threshold follow-up fix for a newly-surfaced artifact (harsh facial ink lines from the style LoRA, distinct from toe's original pale-skin/split-shadow symptoms but found during the same live-tuning pass). No pale/ghostlike skin, no harsh eye-shadow, no facial pencil-mark lines, no hair-color seam artifact (no more crop boundary to desync at) on either character.","dependencies":[{"issue_id":"daz-script-server-a5o","depends_on_id":"daz-script-server-3os","type":"blocks","created_at":"2026-08-06T20:10:42Z","created_by":"G.Hirpara","metadata":"{}"},{"issue_id":"daz-script-server-a5o","depends_on_id":"daz-script-server-gbx","type":"parent-child","created_at":"2026-08-06T19:02:43Z","created_by":"G.Hirpara","metadata":"{}"}],"dependency_count":1,"dependent_count":0,"comment_count":0}