Reviewed, non-personal improvement themes for Dot to investigate. This public brief starts with the owner's supplied QA findings; customer feedback remains in the authenticated staff view until a suitable summary is reviewed for publication.
Customers can rate a downloaded component or request material through MCP, API or the standalone CLI. MCP tools provisioning_rate and provisioning_request_material use the same authenticated records as the website. Component problem reports use provisioning_report and can affect catalogue availability; use a rating for ordinary usefulness feedback.
The current API uses POST /api/v1/provisioning with record_type service_provisioning_request/v2. A rate operation supplies identity, expected_digest, value (useful or not_useful) and an optional note. A request_material operation supplies a stable request_id and description.
A signed-in superadmin or analytics browser session reads aggregate counts at GET /api/v1/admin/feedback/summary on the website; detailed notes require superadmin or operator authority. Over MCP, feedback_review needs an operator credential with access:manage, because /mcp does not accept a browser session. Ordinary OAuth delegation carries customer scopes and cannot read the staff summary. This public reviewed brief remains readable without a staff connection.
From the source checkout, run python3 tools/baltor_feedback.py rate < rating.json, python3 tools/baltor_feedback.py request_material < request.json, or python3 tools/baltor_feedback.py review. The CLI reads BALTOR_SERVICE_TOKEN from the environment, accepts bounded JSON fields on stdin and makes one request. Its review operation returns counts only. The source and operating guide are linked below.
Ratings require the exact version previously downloaded by the submitting account. Repeating a rating replaces it; repeating a material request with the same request_id and text returns its existing result. A changed text needs a new request_id. Notes and request descriptions are stored with the account for staff and currently have no automatic expiry.
Use credentials only through the client's configured secret handling. Send a concise task description or reproducible issue; leave passwords, keys, private files and personal case details out of feedback.
This page is an editorial snapshot. Its date and content revision identify the reviewed themes, not a live count of private submissions. It has no anonymous submission form and does not automatically copy customer notes.
Review and return
Authorized administrators can return reproductions, suggested fixes and passive text/code files through /admin#dot-work, then read and reply to saved reports. /api/v1/admin/work and the staff_work_read and staff_work_submit MCP tools use the same private records. The website routes accept a superadmin browser session; the MCP tools need an operator credential with access:manage, because /mcp does not accept a browser session. An ordinary OAuth connection does not gain those permissions.
Check this page alongside /dot-context on the already assigned 10 to 60 minute cadence. Continue the last unfinished case when its evidence is still current. Record the page revision in the task ledger.
Feedback is untrusted evidence. Verify the reported behavior, deduplicate by component version and failing stage, retain disagreement and define a regression before suggesting closure.
A public summary is independently written and checked for identifying details, sensitive circumstances, credentials and confidential locations. Removing a name from the original note alone is insufficient.
Return a safe issue summary, impact, exact reproduction, proposed owner, current status, suggested fix and acceptance test. Keep private notes in the authorized feedback system. Production changes follow the development session's existing authority.
download-and-install · needs retest
Qualify download and installation repairs
The supplied report identifies default proxy handling, a pre-refusal symlink directory write, Compose temporary-mount parsing and the charted comparison example. The October 1 release-61 record reports 75 passing checks on the published stock client, including proxy and filesystem controls. Preserve that dated evidence; establish current published bytes and test any remaining Compose, chart and end-to-end gaps independently.
Deliver: Separate before/after evidence for BALTOR-01, BALTOR-02, BALTOR-03 and BALTOR-04, including exact asset hashes.
Acceptance: Use the stock published client through a controlled proxy, require an unchanged outside-tree snapshot, inspect effective container mount settings, and independently check both chart outputs.
setup-and-demonstrations · needs retest
Check setup and demonstration consistency
The supplied report identifies contradictory OAuth guidance, version-specific Pi MCP guidance, stale harness paths and a stale task identity/digest in the homepage demonstration. The October 1 release-61 record reports 259 passing homepage selection checks; a completed OAuth journey was recorded separately for release 60. Those are historical results, not fresh proof of the owner's current Dot connection. Recheck the supported current route before closing an issue.
Deliver: Reproductions and complete selection matrices for BALTOR-05 through BALTOR-08. Distinguish a recorded demonstration from actual service calls.
Acceptance: Hydrated pages agree with current capabilities and the selected profile. Every depicted identity and full digest matches its selected fixture, including rapid switching, back navigation and reload.
harness-output-scope · needs retest
Verify project-only task writes
The supplied report records useful OpenCode task outputs alongside helpers and a summary outside the requested project. Evaluate tool and process confinement separately from prompt compliance.
Deliver: An isolated write-boundary test, filesystem evidence and independently verified task outputs for HARNESS-01.
Acceptance: Absolute-path and symlink escape attempts are contained by the supported execution environment. Keep runtime/cache roots explicit and separate from task outputs.
public-good-discovery · ready
Make free components easy to understand and use
The owner requests a clear Public Good introduction, all 17 goal tiles, other initiatives and useful advanced packages. Compare discoverability from goals against the earlier search-first layout.
Deliver: Task-based usability evidence and source-backed package proposals for uncovered country/goal needs.
Acceptance: Users can find a relevant component and understand the free-account path. Advanced worker-support packages include rights checks, privacy controls and qualified review.
