Skip to content

Commit 7ba1bcc

Browse files
authored
Merge pull request #4 from unit-finance/more-wal-tests
More wal tests
2 parents 0452689 + 9af58ed commit 7ba1bcc

File tree

29 files changed

+977
-301
lines changed

29 files changed

+977
-301
lines changed
Lines changed: 115 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,115 @@
1+
---
2+
description: Standards for creating and managing rules
3+
globs:
4+
alwaysApply: true
5+
---
6+
7+
# Rule Management Standards
8+
9+
## Rating System
10+
11+
The rule's status is automatically managed by Cursor based on usage metrics:
12+
13+
- 🔴 **experimental** (default): New pattern, limited validation
14+
- 🟡 **beta**: Current status - validated but needs monitoring
15+
- 🟢 **stable**: Well-established and safe for widespread use
16+
17+
Status upgrades happen automatically when:
18+
- **experimental → beta**: 5+ implementations with 90%+ success rate
19+
- **beta → stable**: 15+ implementations across 3+ different projects
20+
21+
## Core Standards
22+
23+
### 1. Rule Structure (Rating: 3)
24+
- All rules must be MDC files with `.mdc` extension
25+
- Rules must be stored in `.cursor/rules` directory
26+
- Each rule must have:
27+
- Title and description
28+
- Author and date
29+
- Status and metrics
30+
- Rating thresholds
31+
- Core standards with ratings
32+
- Usage tracking section
33+
- Scope definition
34+
35+
### 2. Rating System (Rating: 3)
36+
- Ratings must be on a scale of 1-5:
37+
- 1: Basic/Trivial
38+
- 2: Standard/Common
39+
- 3: Advanced/Complex
40+
- 4: Expert/Specialized
41+
- 5: Master/Architectural
42+
- Each standard must have an explicit rating
43+
- Ratings should reflect complexity and importance
44+
- Higher ratings require more validation
45+
46+
### 3. Rule Progression (Rating: 2)
47+
- Rules start as experimental
48+
- Progress to beta after:
49+
- 5+ successful implementations
50+
- 90%+ success rate
51+
- Progress to stable after:
52+
- 15+ successful implementations
53+
- Used in 3+ different projects
54+
- Rules can be downgraded if issues are found
55+
56+
### 4. Rule Communication (Rating: 2)
57+
- AI must explicitly inform when using a rule
58+
- Explain which specific standard is being followed
59+
- Provide context for rule application
60+
- Allow for user feedback on rule application
61+
- Document rule usage in tracking comments
62+
63+
### 5. Rule Maintenance (Rating: 2)
64+
- Keep rules up to date with project changes
65+
- Review and update rules periodically
66+
- Document rule changes
67+
- Consider rule dependencies
68+
- Maintain rule consistency
69+
70+
## Rule Usage Tracking
71+
72+
The rule metrics are automatically updated through Cursor's rule engine:
73+
74+
1. **Detection**:
75+
- Cursor monitors when this rule is used in code files
76+
- Detection happens when Cursor assists in implementing code changes
77+
- The tracking comment is automatically inserted:
78+
```scala
79+
// Implements rule: rule_management_standards
80+
// Implementation #X (auto-updated by Cursor)
81+
```
82+
83+
2. **Validation**:
84+
After each rule implementation, Cursor will:
85+
- Ask the engineer to confirm if the implementation is correct
86+
- Request permission to update rule metrics
87+
- Only record success if explicitly confirmed by the engineer
88+
- Skip metric updates if the engineer indicates issues
89+
90+
3. **Automatic Updates**:
91+
When engineer confirms successful implementation:
92+
- `implementations` count increases
93+
- `successful_reviews` updates based on engineer confirmation
94+
- `last_updated` reflects confirmation timestamp
95+
- Status may upgrade based on thresholds
96+
97+
4. **Project Tracking**:
98+
- Cursor tracks rule usage across different modules/projects
99+
- This affects progression to "stable" status
100+
- Projects are identified by directory structure
101+
102+
5. **Manual Override**:
103+
- Users can flag incorrect implementations
104+
- Rule maintainers can adjust metrics if needed
105+
- Downgrade of status possible if issues found
106+
107+
## Scope
108+
109+
This rule applies to all rule management in the ZIO Raft project, including:
110+
- Rule creation and modification
111+
- Rule structure and format
112+
- Rating system implementation
113+
- Rule progression tracking
114+
- Rule communication
115+
- Rule maintenance

.cursor/rules/working-together.mdc

Lines changed: 219 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,219 @@
1+
---
2+
description: For every discussion this pattern should be used
3+
globs:
4+
alwaysApply: true
5+
---
6+
---
7+
title: "Working Together: AI-User Collaboration Pattern"
8+
description: "Structured collaboration pattern for AI-User interactions"
9+
author: "Updated by Claude 3.7 Sonnet"
10+
date: "2023-11-15"
11+
status: "🔴 experimental"
12+
metrics:
13+
implementations: 0
14+
successful_reviews: 0
15+
projects: 0
16+
last_updated: "2023-11-15"
17+
rating_thresholds:
18+
experimental_to_beta:
19+
implementations: 5
20+
success_rate: 90
21+
beta_to_stable:
22+
implementations: 15
23+
projects: 3
24+
---
25+
26+
# Working Together: AI-User Collaboration Pattern
27+
28+
## Rating System
29+
30+
The rule's status is automatically managed by Cursor based on usage metrics:
31+
32+
- 🔴 **experimental** (default): New pattern, limited validation
33+
- 🟡 **beta**: Validated but needs monitoring
34+
- 🟢 **stable**: Well-established and safe for widespread use
35+
36+
Status upgrades happen automatically when:
37+
- **experimental → beta**: 5+ implementations with 90%+ success rate
38+
- **beta → stable**: 15+ implementations across 3+ different projects
39+
40+
## Scope
41+
42+
This rule applies to all interactions between users and AI assistants in Cursor, including:
43+
- Code modifications
44+
- Bug fixes
45+
- Feature implementations
46+
- Code reviews
47+
- Documentation updates
48+
49+
## Context
50+
51+
When working with an AI assistant on coding tasks, having a clear and consistent interaction pattern is crucial for effective collaboration. This pattern should ensure goal alignment, methodical progress, and quality outcomes.
52+
53+
## Core Standards
54+
55+
### 1. Rule Usage Declaration (Rating: 2)
56+
- AI must explicitly state it is following the working-together rule at the beginning of each task
57+
- The declaration must be visible and clear to the user
58+
- The declaration should include which specific aspects of the rule are being applied
59+
- Example: "I'll be following the working-together collaboration pattern for this task, focusing on goal alignment and plan confirmation."
60+
61+
### 2. Goal Alignment and Iteration (Rating: 3)
62+
- The goal must be explicitly stated, verified, and reiterated
63+
- AI must restate the goal in its own words to confirm understanding
64+
- User must have opportunity to correct any misalignment
65+
- All proposed actions must be validated against this goal
66+
- Goal must be referenced throughout the interaction
67+
- Example: "Based on your request, our goal is to [restate goal]. Is this understanding correct?"
68+
69+
### 3. Plan-First Approach with Explicit Confirmation (Rating: 4)
70+
- Before making ANY changes:
71+
1. Assess current state (e.g., compile, run tests)
72+
2. Analyze issues and requirements
73+
3. Create a clear, structured plan
74+
4. Present plan for discussion and confirmation
75+
5. Explicitly ask for confirmation: "Do you approve this plan?"
76+
6. Only proceed after receiving explicit plan approval
77+
7. Reiterate the plan before implementing each major step
78+
79+
### 4. No Changes Without Confirmation (Rating: 5)
80+
- AI must NEVER make code changes before receiving explicit confirmation
81+
- Each significant change requires separate confirmation
82+
- Changes must be previewed when possible
83+
- User must have opportunity to modify the proposed changes
84+
- Each code change must follow a git commit or checkpoint
85+
- Example: "Here's my proposed change to file X. Would you like me to implement this change?"
86+
87+
### 5. Scope Management (Rating: 3)
88+
- Stay focused on the confirmed goal
89+
- Additional suggestions should be:
90+
- Documented separately
91+
- Not mixed with current implementation
92+
- Presented as future considerations
93+
- Avoid scope creep during implementation
94+
- Regularly check if current work aligns with original goal
95+
96+
### 6. Verification-Driven Development (Rating: 3)
97+
- Start with verification of current state
98+
- Verify after each significant change
99+
- Include broader verification (e.g., test compilation) when appropriate
100+
- Use verification results to inform next steps
101+
- Document verification results
102+
103+
### 7. Communication Standards (Rating: 3)
104+
For every change:
105+
- **Before**: Explain what will be done
106+
- **During**: Report significant findings
107+
- **After**: Summarize what was done
108+
- **Issues**: Present problems with proposed solutions
109+
- Use clear section headers to delineate different parts of the interaction
110+
111+
### 8. Incremental Progress (Rating: 2)
112+
- Make small, verifiable changes
113+
- Track progress against the plan
114+
- Adjust approach based on findings
115+
- Maintain goal alignment throughout
116+
- Summarize progress at regular intervals
117+
118+
## Consequences
119+
120+
### Positive Outcomes
121+
Following this pattern will:
122+
- Ensure consistent, goal-oriented progress
123+
- Prevent unauthorized or premature changes
124+
- Maintain clear communication
125+
- Produce verifiable results
126+
- Enable effective collaboration
127+
- Reduce misunderstandings and rework
128+
129+
### Negative Outcomes
130+
Not following this pattern may result in:
131+
- Misaligned efforts
132+
- Premature or unauthorized changes
133+
- Scope creep
134+
- Unclear communication
135+
- Inefficient use of resources
136+
- Reduced quality of outcomes
137+
138+
## Compliance
139+
140+
An interaction is compliant when:
141+
- AI explicitly declares it is following the working-together rule
142+
- Goal is explicitly stated, verified, and reiterated
143+
- Plan is created and confirmed before implementation
144+
- No changes are made without explicit confirmation
145+
- Changes are verified and aligned with goal
146+
- Communication follows the specified pattern
147+
- Progress is incremental and trackable
148+
149+
## Examples
150+
151+
### Compliant Interaction
152+
```
153+
User: I need to fix the compilation error in Node.scala
154+
155+
AI: I'll be following the working-together collaboration pattern for this task.
156+
157+
GOAL: Based on your request, our goal is to identify and fix the compilation error in Node.scala. Is this understanding correct?
158+
159+
User: Yes, that's correct.
160+
161+
AI: Great! Let me first assess the current state before proposing a plan.
162+
163+
[AI examines the file and compilation error]
164+
165+
AI: Here's my proposed plan:
166+
1. Analyze the specific compilation error in Node.scala
167+
2. Identify the root cause of the error
168+
3. Propose a specific fix with code changes
169+
4. Verify the fix resolves the compilation error
170+
171+
Do you approve this plan before I proceed?
172+
173+
User: Yes, please proceed with the plan.
174+
175+
AI: I'll now execute step 1 of our plan: analyzing the compilation error.
176+
177+
[AI analyzes error]
178+
179+
AI: I've completed step 1. The compilation error is [error details].
180+
Moving to step 2: identifying the root cause...
181+
182+
[Process continues with explicit confirmation before any code changes]
183+
```
184+
185+
### Non-Compliant Interaction
186+
```
187+
User: Fix the error in Node.scala
188+
189+
AI: I'll fix it right away.
190+
[AI makes changes without verification, plan or confirmation]
191+
192+
AI: Done! I fixed the error by changing line 42.
193+
```
194+
195+
## Rule Usage Tracking
196+
197+
The rule metrics are automatically updated through Cursor's rule engine:
198+
199+
1. **Detection**:
200+
- Cursor monitors when this rule is used in interactions
201+
- The tracking comment is automatically inserted:
202+
```scala
203+
// Implements rule: working-together
204+
// Implementation #X (auto-updated by Cursor)
205+
```
206+
207+
2. **Validation**:
208+
After each rule implementation, Cursor will:
209+
- Ask the user to confirm if the implementation followed the pattern correctly
210+
- Request permission to update rule metrics
211+
- Only record success if explicitly confirmed by the user
212+
- Skip metric updates if the user indicates issues
213+
214+
3. **Automatic Updates**:
215+
When user confirms successful implementation:
216+
- `implementations` count increases
217+
- `successful_reviews` updates based on user confirmation
218+
- `last_updated` reflects confirmation timestamp
219+
- Status may upgrade based on thresholds

.github/workflows/publish.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,8 @@ jobs:
1111
with:
1212
distribution: 'adopt'
1313
java-version: '21'
14+
- name: Setup sbt launcher
15+
uses: sbt/setup-sbt@v1
1416
- name: Extract version from release tag
1517
id: extract_version
1618
run: |

kvstore/src/main/scala/zio/kvstore/App.scala

Lines changed: 8 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ import zio.raft.zmq.ZmqRpc
55
import zio.raft.{Command, Index, MemberId, Raft, SnapshotStore, StateMachine}
66
import zio.stream.{Stream, ZStream}
77
import zio.zmq.ZContext
8-
import zio.{Chunk, UIO, URIO, ZIO, ZIOAppArgs}
8+
import zio.{Chunk, UIO, URIO, ZIO, ZIOAppArgs, ZLayer}
99

1010
import scodec.Codec
1111
import scodec.bits.BitVector
@@ -27,9 +27,9 @@ object KVCommand:
2727
val getCodec = utf8_32.as[Get]
2828
val setCodec = (utf8_32 :: utf8_32).as[Set]
2929
given commandCodec: Codec[KVCommand] = discriminated[KVCommand]
30-
.by(fixedSizeBytes(1, ascii))
31-
.typecase("S", setCodec)
32-
.typecase("G", getCodec)
30+
.by(fixedSizeBytes(1, ascii))
31+
.typecase("S", setCodec)
32+
.typecase("G", getCodec)
3333

3434
class KVStateMachine(map: Map[String, String]) extends StateMachine[KVCommand]:
3535

@@ -79,14 +79,13 @@ object KVStoreApp extends zio.ZIOAppDefault:
7979
override def run =
8080
val program =
8181
for
82-
_ <- ZIO.unit
8382
args <- ZIOAppArgs.getArgs
8483
memberId = MemberId(args(0))
8584
peers = Map(
8685
"peer1" -> "tcp://localhost:5555",
8786
"peer2" -> "tcp://localhost:5556",
8887
"peer3" -> "tcp://localhost:5557"
89-
).map((k, v) => MemberId(k) -> v)
88+
).map((k, v) => MemberId(k) -> v)
9089

9190
rpc <- ZmqRpc.make[KVCommand](
9291
peers(memberId),
@@ -111,4 +110,6 @@ object KVStoreApp extends zio.ZIOAppDefault:
111110
_ <- ZIO.never
112111
yield ()
113112

114-
program.exitCode.provideSomeLayer(ZContext.live.orDie)
113+
program.exitCode.provideSomeLayer(
114+
ZContext.live.orDie ++ zio.lmdb.Environment.test
115+
) // TODO (eran): change test to live?

0 commit comments

Comments
 (0)