What works today
A workspace member can launch a Pipedream-hosted GitHub authorization flow. CloseSpan associates verified account metadata and connection health with the current organization. Pipedream handles the provider credential rather than exposing it to the CloseSpan browser.
Workspace admins can view connection state and disconnect an individual account. The connection does not currently read repository content or create a GitHub object.
The intended engineering workflow
CloseSpan is designed to connect a reviewed customer problem to repository ownership, relevant code context, existing issues, release evidence, and an approved engineering action. The proposed action should show the evidence, confidence, destination, data shared, and reversibility before an operator approves it.
That workflow is visible in the product as a simulated approval path. Approval currently creates a simulated external work item in CloseSpan, not a live GitHub issue or pull request.
Permissions and future boundaries
The hosted authorization flow displays the GitHub permissions associated with the configured Pipedream app. A production GitHub workflow should separate repository read access from approved write access and should limit both to explicitly selected repositories.
- Read repository metadata only after repository selection and scope verification.
- Bind each proposed write to an approved payload, destination, and expiration.
- Require fresh authorization and review when the repository, scope, or payload changes.
- Store the resulting issue or pull-request reference and audit event after a confirmed provider response.
- Never treat model-generated code context as a confirmed root cause without engineering review.
What is not implemented
- Repository ingestion
- No repository files, code graph, commits, or ownership data are currently imported
- Issue actions
- No live GitHub issue is created, edited, or closed by the current workflow
- Pull requests
- No branch, commit, or pull request is created by CloseSpan
- Release sync
- GitHub releases and deployment status are not continuously synchronized
- Approval executor
- The current approval result is a simulated work item, not an approval-bound GitHub API call
How to evaluate the product now
Use the current workspace to review how feedback evidence, business impact, investigation notes, risk, and approval state should be packaged before engineering work is created. Treat every external GitHub object shown in demo data as simulated unless the product explicitly reports a confirmed live provider response.