Conversation
Every stage challenges its own answers under core.md's Pushback rule, but no interview can see another's: a stack pick that breaks a mockup promise is not raisable while either one runs, so it surfaces for the first time in the code build is about to write. New Procedure step 7 applies that rule across the six pre-build interviews once stack formalizes. Findings are cross-stage only - grounds inside a single interview stay that stage's job, and a Q entry that already records an objection is settled and never re-raised. Same two-round cap, same citations; a resolution amends the interview that gives way and regenerates its outputs without re-interviewing. The pass records itself with ledger key readback/all@Q<n> so a resumed run skips it, which is core.md's one exception to start writing no changelog entries.
mockup predates logic and uiux. When they were added, only its handoff
paragraph changed, so it still carries the scope it had when it was the
whole front of the pipeline. Two failures follow, both visible in a real
project's docs.
It invents rules to fill its sections. A screen's `## States` required a
trigger per state, so one got invented - a credit threshold and a chat
notice, cited to an interview entry that records the question as
unanswered, and not marked assumed. logic later settled the same
question the other way and explicitly rejected that threshold. Both
files are still on disk, same date, same stamp, and uiux styles from the
mockup's states.
And it under-delivers what logic needs. logic seeds its scenario list
from the mockup, but the mockup writes routes ("first-run: 01 -> 02 ->
05"), not behaviors. One of eight rows survived into logic's real
scenarios; the stage started cold after mockup had already spent turns
producing rules nobody kept.
So: the generation rule gets a stop - an answer that would be a
threshold, formula, branch condition or failure behavior is named, logged
`for: logic`, and left. `## States` becomes an inventory whose unsettled
triggers are marked `rule: logic` rather than filled in, and the assumed
discipline now covers states, where it failed. Phase C's Scenarios angle
splits into Journeys (paths through screens, mockup's own unit) and
Behaviors (what the product decides, named only), and the README carries
both plus a scenario table written at logic's unit, with the test that
every `rule: logic` marker is claimed by exactly one row.
logic seeds from that table instead of from screen flows and inherits
the `for: logic` threads. uiux learns that an unsettled state has no
trigger to style and must not invent one. The commercial model stays
mockup's on purpose: that seam already worked, and now it is stated
rather than left to habit.
mockup gets shorter and its handoffs get stronger.
Reviewer's GuideThis PR refines the pipeline’s stage boundaries by making mockup produce an explicit UI and behavior inventory while deferring business-rule decisions to logic, then adds a resumable cross-stage readback before build to detect and resolve contradictions across all interviews; plugin manifests are version-bumped accordingly. Sequence diagram for the pre-build cross-stage readbacksequenceDiagram
participant Start
participant Interviews
participant Readback
participant User
participant Stage
participant Build
Start->>Interviews: Read six interview files
Interviews-->>Readback: Provide recorded decisions and citations
Readback->>Readback: Collect cross-stage contradictions
alt finding exists
Readback->>User: Raise finding with both stage citations
User-->>Readback: Answer after at most two rounds
Readback->>Stage: Append resolution to stage interview
Stage->>Stage: Regenerate affected outputs
Stage-->>Readback: Updated decisions
Readback->>Readback: Re-check amended decisions
else no finding
Readback->>Readback: Record completed pass
end
Readback-->>Start: Write readback/all ledger entry
Start->>Build: Execute build protocol
Entity relationship diagram for mockup-to-logic handofferDiagram
SCREEN ||--o{ JOURNEY_SCREEN : follows
JOURNEY ||--o{ JOURNEY_SCREEN : contains
BEHAVIOR ||--o{ SCREEN_BEHAVIOR : surfaces_on
SCREEN ||--o{ SCREEN_BEHAVIOR : exposes
BEHAVIOR ||--o{ OPEN_THREAD : settles
SCREEN {
string screen_id
string state_inventory
}
JOURNEY {
string journey_id
string screen_path
}
BEHAVIOR {
string behavior_id
string rule_status
}
OPEN_THREAD {
string question
string target_logic
}
Flow diagram for the refined Capstone pipelineflowchart LR
M[mockup: depict screens and inventory behaviors] --> L[logic: settle business rules]
L --> U[uiux: design committed experience]
U --> A[architecture]
A --> S[standards]
S --> T[stack]
T --> R[readback: compare six interviews]
R -->|resolved or no contradictions| B[build]
R -->|resolution changes a stage| G[regenerate affected outputs]
G --> R
M -.->|Scenarios and open threads| L
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="skills/core/references/protocols/logic.md" line_range="29-32" />
<code_context>
+table if it exists - `mockup` wrote it at this stage's unit, one row
+per behavior the product decides, so it is the list rather than a
+source for one. Confirm it with the user and extend it where the
+screens moved on. Add a scenario for any state or element marked
+`rule: logic` that no row claims, and carry every open thread the
+mockup interview marked `for: logic` into the scenario that owns it:
+those are questions the user was deliberately not asked yet, and they
+are answered here or nowhere. An older mockup with no Scenarios table
</code_context>
<issue_to_address>
**issue (bug_risk):** The logic setup adds scenarios only for markers with no claiming row; it never rejects a marker claimed by multiple rows. Consequently the required exactly-one-row invariant can be violated, causing one unresolved state or element to be assigned to multiple logic scenarios and its open thread to have ambiguous ownership.
**Triggers:** When the mockup Scenarios table contains duplicate claims for the same `rule: logic` state or element.
**Suggested fix:** Validate both sides of the cardinality rule during logic setup: reject duplicate claims and add scenarios for unclaimed markers before confirming the scenario checklist.
```suggestion
source for one. Extend it where the screens moved on, then validate
that every state or element marked `rule: logic` is claimed by exactly
one row: reject duplicate claims and add a scenario for any unclaimed
marker before confirming the scenario checklist with the user. Carry
every open thread the mockup interview marked `for: logic` into the
scenario that owns it:
```
</issue_to_address>Sourcery assessment
Needs a human reviewer. 1 finding to address first, and the change substantially alters the plugin's pipeline and interview protocols, so a mistake could cause generated documentation or implementation decisions to be wrong and persist after the plugin is reverted. Those artifacts are bounded and can be regenerated or corrected, with no evidence of irreversible data, access, payment, or infrastructure changes.
Blocking findings: skills/core/references/protocols/logic.md:32
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
…conflicts An interview generates its questions from the answers before it, so it regularly reaches a decision it does not own: the architecture interview stumbles onto a business rule, the standards interview onto a library pick. It gets filed wherever it came up, and the owning stage then either re-decides it or never sees it. No interview can catch this, for the same reason none can catch a cross-stage contradiction - it cannot see the others. core.md gains a Stage ownership table: what each of the six settles, what it never settles, and the test - a decision belongs to the stage whose subject it answers, not the one that reached it first. Referencing another stage's decision is correct and stays correct; a decision is misplaced only where the non-owner is its only record, or restates it in its own words. The crossings that are deliberate (the mockup owning the commercial model, architecture's framing pre-filled from the mockup, extraction mode recording observed fact) are named so the pass does not churn on them. The readback pass now runs in two halves, misplacement first so the contradiction half cites final locations. Re-filing is not re-deciding, so it is one digest the user confirms rather than a finding per turn: each move appends the decision verbatim to the receiving interview marked with its source, annotates the original as relocated rather than deleting it, and regenerates both stages' outputs. architecture.md and mockup.md now point at the table at ask-time, which is where a misplacement is cheapest to avoid entirely.
Sourcery caught that the exactly-one-row rule mockup states was only half-enforced: logic added scenarios for unclaimed markers but nothing rejected a marker two rows claim, so one unsettled state could be decided by two scenarios. The gap is real, but "reject duplicates" is the wrong close. A state is routinely touched by two behaviors that are correctly separate - one decides why a session ends, another what happens when it does. The rule is the one core.md already draws between stages: exactly one owner, any number of references. So a doubly-claimed marker names its owner rather than merging two distinct behaviors, and logic checks both directions before confirming the list. Versions go back to 5.2.0. Nothing has merged to main, so the branch ships one version rather than a bump per commit.
logic's completeness test was "nothing left to invent", which measures what the interviewer noticed. A rule nobody thought to ask about reads exactly like a rule that does not exist, and the gap is invisible in the output: the scenario file looks finished either way. architecture solves this with interview.md, an inventory walked top to bottom. Business logic cannot have a fixed question list - a payments product and a game ask nothing alike - but the layer above it is the same everywhere. logic-craft.md names sixteen dimensions a rule can live in, each with the probe that generates its questions for the scenario at hand and the tell that decides whether it applies. The dimensions with no natural question behind them are the reason this exists. Nobody asks what the system deliberately hides, or what it deliberately never says, because both are absences; they surface only if something prompts them. The generation rule still orders the questions. The sweep decides when a scenario is done: every dimension answered, cited to an earlier scenario via depends_on, or recorded inapplicable with its reason in a closing section, so a later reader can tell "no money here" from "nobody asked about money". A dimension the user declines to settle is an open question, not an inapplicable one. Volume is controlled by running the sweep rather than performing it: questions the mockup or an earlier scenario already answers are deleted, and the dimensions that do not apply are confirmed in one batch instead of sixteen turns. Extraction mode sweeps the same way, where "not implemented" is the finding rather than a gap to skip.
The Stage ownership table gave mockup "rate and runway equations" and logic "exact rules and formulas" without drawing the line where they meet, so a decision like "unused credits expire monthly" could be filed either way with the table backing both readings. The split is the offer versus the mechanics. What a plan costs and what it grants is a mockup question, and it stays the one place that stage decides arithmetic. When a balance is debited, reserved, reconciled, refunded or expired, what happens at zero, and who absorbs a failed charge are all scenarios. Expiry lands with logic despite being commercially motivated: it is a lifecycle transition that happens to have a commercial reason. Stated in the table where the ambiguity was, in mockup's exception so the stage reads its own limit at ask-time, and in logic-craft's money dimension so the sweep cites the price rather than re-setting it.
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
1 participant
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 by Sourcery
Make the capstone pipeline sweep business rules comprehensively and reconcile stage decisions before build.
New Features:
Bug Fixes:
Enhancements:
Documentation:
Chores: