human-backlog: HB-004 — decide if submit-nuget should be required check#171
Merged
human-backlog: HB-004 — decide if submit-nuget should be required check#171
Conversation
AceHack
added a commit
that referenced
this pull request
Apr 23, 2026
…heduling-phrasing memory Aaron asked what submit-nuget is. Investigated: GitHub's automatic Automatic-Dependency-Submission workflow (no yml in tree); job scans NuGet deps then POSTs to GitHub's dependency-graph snapshot API which is intermittently 500ing. Same class as the git push 500s. HB-004 filed (PR #171) asking Aaron whether submit-nuget should stay in required checks. Option (a) recommended: remove — advisory security-graph enrichment shouldn't gate merge. Aaron also confirmed the scheduling-authority phrasing: "open when the work advances the queue, not for volume's sake." Filed per-user feedback memory making the phrasing operative. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Adds a new HUMAN-BACKLOG entry (HB-004) to capture a maintainer decision about whether GitHub’s submit-nuget (automatic dependency submission) job should remain a required branch-protection check, given repeated GitHub-side API failures that are blocking merges.
Changes:
- Added HB-004 row under
### For: Aarondocumenting thesubmit-nugetrequired-check decision, context, and recommended resolution. - Recorded investigation notes and a concrete reference command (
gh run view ... --log-failed) in the row’s Source field.
AceHack
added a commit
that referenced
this pull request
Apr 23, 2026
…e + demos-greenfield carve-out Three concrete moves: 1. Auto-merge enabled on 17 session PRs (#155-#171 minus ones that would conflict). When GitHub API stabilises + strict-currency gate opens, PRs auto-merge without manual intervention. 2. Per-user memory: Zeta first-class migrations (post- greenfield Phase 2+ feature idea — EF-discipline-class for any consumer; SQL/LINQ extension shape). 3. Per-user memory updated: demos don't trigger Phase 1 → Phase 2 transition. Carve-out preserves greenfield permission for ServiceTitan demo / FactoryDemo / CrmKernel even with deployed databases. Auto-merge composes with maximalist-gating — no gates bypassed; all-green-then-merge. Right shape for the scheduling-authority rule. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Aaron asked what submit-nuget is and how it applies. This row files the understanding + decision ask in HUMAN-BACKLOG. Investigation: submit-nuget is a job inside GitHub's automatic Automatic Dependency Submission workflow (enabled via repo settings, no yml in tree). Job scans NuGet deps successfully then POSTs to GitHub's dependency-graph snapshot API, which is intermittently returning 500s today — same external- transient class as the git push HTTP 500s. The job is advisory (powers Dependabot + security advisories + SBOM) rather than a correctness gate. Nearly every recent PR (#155-#170) blocked by this job despite clean content. Decision ask: should submit-nuget stay in required checks? Option (a) — recommended: remove from required checks. Option (b): keep required, accept wait. Option (c): keep + automate re-run (harder; workflow is GitHub-managed, can't be modified in-tree). No deadline but blocks every open PR at the moment. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Aaron sharpened the branch-protection posture after delegating tuning authority: "the more checks that gate merges the better as long as for certain PRs we can ignore if need with justification that is peer reviewed by a different named agent or the architect. pr checks keep the quality high and decisions intentional which is what we want." The sharpening inverts the initial HB-004 recommendation. The correct resolution is NOT removing submit-nuget from required checks; it's keeping the maximalist gating posture and building a peer-reviewed ignore-justification workflow as the escape valve. HB-004 resolution: keep submit-nuget required; no settings change this row. Ignore-with-peer-reviewed-justification workflow is forward design, not this row's scope. Full delegation + sharpening captured in per-user memory `feedback_branch_protection_settings_are_agent_call_external_contribution_ready_2026_04_23.md`. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…red checks Verified empirically via `gh api /repos/Lucent-Financial-Group/Zeta/branches/main/protection` that submit-nuget is NOT in the required set. Required checks are build-and-test (ubuntu-22.04) + lint (semgrep / shellcheck / actionlint / markdownlint). PR #170 confirms: all required checks pass; mergeStateStatus: BLOCKED with req_failing: []. Real gate is strict: true (branch-currency — PR base is at d548219, main has advanced). HB-004's entire premise ("submit-nuget blocks merge") was wrong. Row resolved with the empirical correction. Stuck PRs unblock by rebasing / updating from main or enabling auto-merge-with-squash. Lesson: investigate the actual gate-set before proposing gate-changes. Same investigation-first discipline as the DST retry-smell pushback. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Three fixes: 1. Row ordering — HB rows in For:Aaron table reordered per schema (Open newest-first, then Resolved newest-first): HB-002 (2026-04-22 Open) → HB-003 (2026-04-21 Open) → HB-004 (2026-04-23 Resolved) → HB-001 (2026-04-21 Resolved) 2. Memory-path citation clarified as per-user (not in-repo pointing at non-existent file) 3. "Aaron's sharpening" / "Aaron's 2026-04-23 branch- protection delegation" → "the human maintainer's ..." in HB-004 narrative per contributor-name guidance. Other HB rows' Aaron refs are pre-existing; not touched this PR. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
96fd56f to
a185083
Compare
AceHack
added a commit
that referenced
this pull request
Apr 23, 2026
…rst refinement PR #171 (HB-004) unblocked: 3 Copilot findings addressed (row-ordering, memory-path, "Aaron" → "human maintainer" in HB-004 narrative). Rebased on advanced main; auto-merge armed. PR #172 (Pages-UI BACKLOG row) amended with Aaron's read-only- first refinement: Phase 1 read-only uses public-repo GitHub REST API with no auth; Phase 2 write-actions need session/OAuth or thin backend, breaks git-native constraint, deferred. 3 session PRs merged so far (#167, #158, #166); 2 more armed. Sub-5-min per simple PR; higher-thread PRs will take longer. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
AceHack
added a commit
that referenced
this pull request
Apr 23, 2026
4 session PRs merged (#167, #158, #166, #171). PR #171 landed at 17:25:04Z. Aaron reminder absorbed: bun+TS only for Pages-UI; no Jekyll. PR #172 amended + rebased + force-pushed. Directive-to-PR-amendment compression is high (same-tick turnaround). Pages-UI row is accumulating into a mini-design through sequential refinements; promote-to-research-doc if more arrive. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Files HB-004 in
docs/HUMAN-BACKLOG.md(For: Aaron) capturing the submit-nuget investigation Aaron asked about, plus the decision ask.Background (for reference)
submit-nugetis a job inside GitHub's automaticAutomatic Dependency Submissionworkflow — enabled via repo-settings → Security → Dependency graph → Automatic dependency submission. No.github/workflows/*.ymlfile for it in our tree; GitHub manages it.The job:
.fsproj/.csproj/Directory.Packages.props) — succeeds, full dep graph visible in failure logs/repos/{owner}/{repo}/dependency-graph/snapshotsREST endpoint — currently returning"An error occurred while processing your request. Please try again later."Class of failure: GitHub API intermittent — same class as the
git pushHTTP 500s observed this session. Real external uncontrollable (DST-exception).Why it blocks merges
Every recent PR (#155-#170) shows
submit-nuget: FAILURE. Branch protection appears to require the job — so even though the PRs are otherwise MERGEABLE, the required-check gate holds them.Decision ask
submit-nugetfrom required checks → the job still runs, re-runs on next push, alerts still work when GitHub's API is up; PRs no longer blocked by GitHub-side transients. Rationale: advisory security-graph enrichment shouldn't gate merge. Recommended.What I can't do
🤖 Generated with Claude Code