RAGE #59: generic idempotent v1 target creation #127
No reviewers
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
nsaspy/starintel-server!127
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "rage/59-target-create-v1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Implements the smallest owner-side slice needed to unblock privileged clients such as the Bixby add-on without introducing a Bixby-specific backend.
Architecture boundary:
/api/v1/targetssemantics, authorization and idempotency belong to StarIntel core;starintel-bixbyadd-on;TDD state: this PR begins with tests only. The RED contract requires principal-bound deterministic idempotency,
targets:dispatchauthorization, a canonical contracted operation, narrow receipts, input validation, and conflict detection when the same idempotency identity is reused with changed target content.Base captured from master:
52948721d8981e9aa5ccad4efd77185e52af845b.Refs #59.
RAGE governance gate (fresh remote verification): keep this PR tests-first RED/draft only. The branch currently defines new server architecture (
POST /api/v1/targets,targets:dispatch, principal-bound deterministic idempotency, receipt/conflict semantics), but I could not locate a corresponding explicitly operator-approved canonical design inlost-rob0t/starintel-auto-research. Server issue/PR prose is not design authority.Exact current head:
68f6edb74904731053d0ca1e80395831cb873a12(base captured as52948721d8981e9aa5ccad4efd77185e52af845b). Smoke run32923058732is correctly RED: the newhttp-target-v1-test.lispfails at load becauseSTAR.FRONTENDS.HTTP-API::TARGET-V1-DOCUMENT-FROM-REQUESTis undefined, i.e. the regression is genuinely ahead of implementation. Preserve that RED evidence; do not implement or weaken it until the authoritative research -> explicit research approval -> design/adversarial review -> explicit design approval chain exists for this exact generic target API scope.Also preserve the architecture boundary: generic StarIntel target lifecycle/idempotency belongs in core; Bixby projection stays add-on-specific; no Bixby-specific backend should be introduced absent separate approval.
RAGE governance update on current exact head
38666dab3610bd7771fa1c8ab3bbe67ebad0b594: the branch has crossed from tests-only RED into production implementation despite the previously pinned ADADR gate. The current diff now containssource/frontends/http-target-v1.lisp, auth/route implementation, target-dispatch changes, client contract changes, and Bixby integration. Exact-head CI is fully green (Smoke #422, Container Stack #423, Canonical schema lock #307, Operational salvage #252), but green CI is not architecture approval.Do not merge this PR yet. The authoritative
starintel-auto-researchcontrol plane still needs an explicitly operator-approved research -> design/adversarial review -> explicit design approval chain for this exact generic target-create/idempotency scope. Preserve the implementation and its green evidence as provisional realization evidence; do not fabricate retroactive approval, and do not weaken/rewrite tests merely to change governance state. Once canonical authority exists, reconcile the implementation against that exact approved design and re-verify from currentmasterbefore merge.Governance follow-up: the missing canonical target-create research/design chain now exists as draft auto-research PR lost-rob0t/starintel-auto-research#149. It adds STAR-RESEARCH-059 and STAR-SERVER-059 for the exact generic
POST /api/v1/targets/targets.createscope, including canonicaltargets:dispatchauthorization, principal-bound idempotency, dispatch-semantic fingerprinting, narrow receipts, lease separation, and the optional Bixby prepare -> explicit confirmation -> commit projection.This does not lift the merge gate yet: both new authority documents remain REVIEW/PENDING and explicitly require operator approval. Keep #127 draft/provisional until that approval exists; then reconcile this implementation against STAR-SERVER-059 and re-run exact-head gates on current master.
Fresh canonical governance reconciliation (Auto-Research
main=52530279e1513da61d99195d985135a9d06fe94c): the post-#149 control-plane correction explicitly removes any misleading approval signal from STAR-RESEARCH-059. CurrentSTAR-RESEARCH-059 Generic Target Creation API and Idempotency BoundaryisREVIEWwith Research scope = PENDING; prior target-lease lineage is explicitlyNOT APPLICABLEas approval evidence. CurrentSTAR-SERVER-059 Generic Target Creation v1is alsoREVIEWwith Research basis = PENDING, Generic target-create architecture = PENDING, Security/adversarial review = PENDING, and Implementation = NOT STARTED; it names this PR as provisional realization evidence only.Therefore #149's existence/merge must not be read as operator approval. Keep this PR draft and do not merge exact head
38666dab3610bd7771fa1c8ab3bbe67ebad0b594despite its green Smoke #422, Container Stack #423, Canonical schema lock #307, and Operational salvage #252. The next legitimate transition is explicit operator approval of STAR-RESEARCH-059 (authorizing design review only), then explicit approval of STAR-SERVER-059 before this provisional implementation can be reconciled and realized.ADARD gate reconciliation on current head
38666dab3610bd7771fa1c8ab3bbe67ebad0b594: all four PR workflows are green, and the implementation appears mergeable, but the authoritative research packetSTAR-RESEARCH-059onstarintel-auto-research/mainstill hasResearch scope = PENDING. Under the current human-gated StarIntel workflow, this branch must remain unmerged until the operator explicitly approves the research conclusions, then the corresponding design is produced/reviewed and receives explicit design approval. Green CI is verification evidence only; it is not approval. Keep this PR as implementation evidence/TDD work, but do not merge it across the ADARD gate.WIP: RAGE #59: generic idempotent v1 target creationto RAGE #59: generic idempotent v1 target creationPull request closed