claude-fsd 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +43 -0
- package/bin/claudefsd-dev +208 -0
- package/bin/claudefsd-plan +71 -0
- package/bin/claudefsd-plan-gen +64 -0
- package/package.json +25 -0
package/README.md
ADDED
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
# claude-fsd
|
|
2
|
+
|
|
3
|
+
Claude Full Stack Development tools for managing development projects.
|
|
4
|
+
|
|
5
|
+
## Installation
|
|
6
|
+
|
|
7
|
+
```bash
|
|
8
|
+
npm install -g claude-fsd
|
|
9
|
+
```
|
|
10
|
+
|
|
11
|
+
## Usage
|
|
12
|
+
|
|
13
|
+
After installation, the following commands will be available globally:
|
|
14
|
+
|
|
15
|
+
### claudefsd-dev
|
|
16
|
+
Development environment management tool.
|
|
17
|
+
|
|
18
|
+
```bash
|
|
19
|
+
claudefsd-dev
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
### claudefsd-plan
|
|
23
|
+
Project planning and management tool.
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
claudefsd-plan
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
### claudefsd-plan-gen
|
|
30
|
+
Plan generation utility.
|
|
31
|
+
|
|
32
|
+
```bash
|
|
33
|
+
claudefsd-plan-gen
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
## Requirements
|
|
37
|
+
|
|
38
|
+
- Node.js >= 14.0.0
|
|
39
|
+
- Unix-like environment (macOS, Linux)
|
|
40
|
+
|
|
41
|
+
## License
|
|
42
|
+
|
|
43
|
+
MIT
|
|
@@ -0,0 +1,208 @@
|
|
|
1
|
+
#!/bin/bash
|
|
2
|
+
|
|
3
|
+
set -e
|
|
4
|
+
|
|
5
|
+
# Add counter for loop iterations
|
|
6
|
+
LOOP_COUNTER=0
|
|
7
|
+
|
|
8
|
+
while true; do
|
|
9
|
+
# Increment loop counter
|
|
10
|
+
LOOP_COUNTER=$((LOOP_COUNTER + 1))
|
|
11
|
+
|
|
12
|
+
mkdir -p logs
|
|
13
|
+
# Use a temporary directory for tmp files, as codex is sandboxed to this directory
|
|
14
|
+
mkdir -p tmp
|
|
15
|
+
export TMPDIR=tmp/
|
|
16
|
+
LOGFILE="logs/claude-$(date +%Y%m%d_%H%M%S).txt"
|
|
17
|
+
|
|
18
|
+
echo "Logging to ${LOGFILE}-* ..."
|
|
19
|
+
|
|
20
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
21
|
+
echo -e "\033[32m== PLANNING NEXT TASK\033[0m"
|
|
22
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
23
|
+
|
|
24
|
+
# Check if this is the 4th iteration for megathinking mode
|
|
25
|
+
if [ $((LOOP_COUNTER % 4)) -eq 0 ]; then
|
|
26
|
+
echo -e "\033[33m**** MEGATHINKING MODE ACTIVATED ****\033[0m"
|
|
27
|
+
echo -e "\033[33mThis is your 4th development cycle. Taking a step back for architectural planning.\033[0m"
|
|
28
|
+
MEGATHINKING_MODE="**** MEGATHINKING MODE ACTIVATED ****\nThis is your 4th development cycle. Before proceeding with the next task, please take a step back and use megathinking mode to architecturally plan the next phase of development. Consider the overall structure of the codebase, potential refactoring opportunities, design patterns, technical debt, and how the current work connects to broader project goals.\n\n"
|
|
29
|
+
else
|
|
30
|
+
MEGATHINKING_MODE=""
|
|
31
|
+
fi
|
|
32
|
+
|
|
33
|
+
time claude -p "
|
|
34
|
+
$MEGATHINKING_MODE
|
|
35
|
+
Read docs/PLAN.md in order and tell me what's the first open task that needs to be
|
|
36
|
+
done by the developer. Include any context that relates to it , such as sub-bullet
|
|
37
|
+
points or the section the todo item lives in.
|
|
38
|
+
Also bring in any related context from BRIEF.md, docs/QUESTIONS.md and docs/REQUIREMENTS.md.
|
|
39
|
+
Really think this through, as
|
|
40
|
+
the developer will need not just to have blinders on when doing a dev task, but
|
|
41
|
+
also sometimes will need to think about the bigger picture. Particularly if it's
|
|
42
|
+
been stuck in the weeds making a ton of changes when sometimes a single fix
|
|
43
|
+
can clear out a thousand errors. Please consider what are the lowest risk changes
|
|
44
|
+
that achieve the task goal, since you knoow the full plan and the developer
|
|
45
|
+
doesn't necessarily see it.
|
|
46
|
+
|
|
47
|
+
If the plan is complete, say <ALL DONE>.
|
|
48
|
+
" | tee >(cat > $LOGFILE-planner)
|
|
49
|
+
|
|
50
|
+
set +e
|
|
51
|
+
if grep -q "<ALL DONE>" $LOGFILE-planner; then
|
|
52
|
+
echo -e "\033[32mNo more tasks to do\033[0m"
|
|
53
|
+
exit 0
|
|
54
|
+
fi
|
|
55
|
+
|
|
56
|
+
nexttask=$(cat $LOGFILE-planner | grep -v "<ALL DONE>")
|
|
57
|
+
set -e
|
|
58
|
+
|
|
59
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
60
|
+
echo -e "\033[32m== RUNNING DEVELOPER TASK\033[0m"
|
|
61
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
62
|
+
|
|
63
|
+
# run the task
|
|
64
|
+
time claude --dangerously-skip-permissions -p "
|
|
65
|
+
$MEGATHINKING_MODE
|
|
66
|
+
You are an AI developer working within an automated development environment. Your role is
|
|
67
|
+
to complete tasks, plan implementations, and maintain high-quality code. Here is the
|
|
68
|
+
specific task you need to complete:
|
|
69
|
+
|
|
70
|
+
<next_task>
|
|
71
|
+
$nexttask
|
|
72
|
+
</next_task>
|
|
73
|
+
|
|
74
|
+
Before you begin working on this task, please follow these steps:
|
|
75
|
+
|
|
76
|
+
1. Analyze the task with full megathinking and plan your approach.
|
|
77
|
+
Wrap your analysis in <task_analysis> tags inside your thinking block:
|
|
78
|
+
<task_analysis>
|
|
79
|
+
- Break down the task into clear, actionable steps
|
|
80
|
+
- For each step:
|
|
81
|
+
- Identify potential challenges
|
|
82
|
+
- Propose solutions for each challenge
|
|
83
|
+
- Consider architectural implications
|
|
84
|
+
- Ensure your plan adheres to clean code principles
|
|
85
|
+
- Consider how your changes will affect the overall system
|
|
86
|
+
- Verify that your approach uses defensive programming techniques
|
|
87
|
+
- Double-check that you're not implementing any 'cheats' (e.g., unnecessary fallbacks, ignoring issues, or marking tests to be ignored)
|
|
88
|
+
- Consider potential edge cases and how to handle them
|
|
89
|
+
- Think about testing strategies for your changes
|
|
90
|
+
- Evaluate the impact on system performance and scalability
|
|
91
|
+
</task_analysis>
|
|
92
|
+
|
|
93
|
+
2. Execute the necessary changes or Bash commands to complete the task.
|
|
94
|
+
Wrap your code or commands in <execution> tags.
|
|
95
|
+
|
|
96
|
+
3. If a linter is defined for this project, run it after your work.
|
|
97
|
+
Include the linter output in <linter_output> tags if applicable.
|
|
98
|
+
|
|
99
|
+
4. Describe the changes you've made:
|
|
100
|
+
<changes>
|
|
101
|
+
- Provide a clear, concise summary of the implemented changes
|
|
102
|
+
- Explain any architectural decisions you made
|
|
103
|
+
- Highlight any potential areas of concern or future considerations
|
|
104
|
+
- Confirm that your implementation uses defensive programming techniques
|
|
105
|
+
- Verify that all failure modes throw exceptions rather than using silent warnings or fallbacks
|
|
106
|
+
- Describe how you've addressed potential edge cases
|
|
107
|
+
- Outline the testing strategy implemented for these changes
|
|
108
|
+
</changes>
|
|
109
|
+
|
|
110
|
+
5. If you have any questions for future reference, add them to the QUESTIONS.md file. Wrap these additions in <questions_update> tags.
|
|
111
|
+
|
|
112
|
+
6. If you have any ideas for future improvements or features, add them to the IDEAS.md file. Wrap these additions in <ideas_update> tags.
|
|
113
|
+
|
|
114
|
+
Important guidelines to follow:
|
|
115
|
+
- Prioritize simplicity in your code and project structure
|
|
116
|
+
- Always use git for version control; do not create backup copies
|
|
117
|
+
- Delete unused code and options
|
|
118
|
+
- Maintain clean directory structures and consistent file placement
|
|
119
|
+
- Be brutally honest about potential issues or disagreements with the given task
|
|
120
|
+
- Throw exceptions for errors instead of adding fallbacks; errors should be visible and fixable
|
|
121
|
+
- Focus on creating a bulletproof system
|
|
122
|
+
- Create unit and integration tests whenever possible, focusing on real system interactions
|
|
123
|
+
- Maintain web tests in a WEBTESTS.md file if applicable
|
|
124
|
+
- Add lint/architecture/static code analysis tests as you go
|
|
125
|
+
- Run cheap and easy tests (lint, architecture, unit) frequently during development
|
|
126
|
+
|
|
127
|
+
Remember, your work will be reviewed before being committed to the repository. Ensure your changes are well-documented and adhere to the project's standards and best practices.
|
|
128
|
+
|
|
129
|
+
Your final output should consist of the following sections in this order:
|
|
130
|
+
1. <execution>
|
|
131
|
+
2. <linter_output> (if applicable)
|
|
132
|
+
3. <changes>
|
|
133
|
+
4. <questions_update> summarizing the questions you added to QUESTIONS.md
|
|
134
|
+
5. <ideas_update> summarizing the ideas you added to IDEAS.md
|
|
135
|
+
|
|
136
|
+
Do not include any additional commentary or explanations outside of these tagged sections. Your final output should not duplicate or rehash any of the work you did in the task analysis section.
|
|
137
|
+
" | tee >(cat > $LOGFILE-developer)
|
|
138
|
+
|
|
139
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
140
|
+
echo -e "\033[32m== REVIEWING WORK (backgrounded)\033[0m"
|
|
141
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
142
|
+
|
|
143
|
+
# run the static code reviewer (codex can't do the git push part yet, so we need to follow up with claude after)
|
|
144
|
+
# also run it in the background because it's very slow
|
|
145
|
+
(codex --full-auto -q "
|
|
146
|
+
You are the team's static code reviewer.
|
|
147
|
+
A developer has completed this task: $nexttask
|
|
148
|
+
The developer's notes are at $LOGFILE-developer .
|
|
149
|
+
|
|
150
|
+
Related docs:
|
|
151
|
+
- BRIEF.md
|
|
152
|
+
- docs/PLAN.md
|
|
153
|
+
- docs/QUESTIONS.md
|
|
154
|
+
- docs/REQUIREMENTS.md
|
|
155
|
+
- README.md
|
|
156
|
+
|
|
157
|
+
Please review the task and make sure it's complete, and done to satisfaction.
|
|
158
|
+
DO NOT trust the developer's notes, always review the code and build/test results yourself.
|
|
159
|
+
Look for typical 'cheating' patterns, such as turning off unit tests, taking files
|
|
160
|
+
out of the compilation configuration, and redefining the plan to skip tasks
|
|
161
|
+
that aren't working.
|
|
162
|
+
|
|
163
|
+
If the task is not complete, adjust the item in docs/PLAN.md with suggestions for
|
|
164
|
+
the developer to complete the task properly.
|
|
165
|
+
|
|
166
|
+
If you have any questions of the user for the future, you can add them to QUESTIONS.md.
|
|
167
|
+
If you have any ideas for the future, you can add them to IDEAS.md.
|
|
168
|
+
" > $LOGFILE-reviewer) &
|
|
169
|
+
|
|
170
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
171
|
+
echo -e "\033[32m== REVIEWING/TESTING/COMMITTING WORK\033[0m"
|
|
172
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
173
|
+
|
|
174
|
+
# run the reviewer/tester
|
|
175
|
+
time claude --dangerously-skip-permissions -p "
|
|
176
|
+
You are a megathinking reviewer, tester, and architect.
|
|
177
|
+
A developer has completed this task: $nexttask
|
|
178
|
+
|
|
179
|
+
The developer's notes are at $LOGFILE-developer .
|
|
180
|
+
The static code reviewer reviewed the code and its (possibly partial) result is at $LOGFILE-reviewer .
|
|
181
|
+
|
|
182
|
+
Related docs:
|
|
183
|
+
- BRIEF.md
|
|
184
|
+
- docs/PLAN.md
|
|
185
|
+
- docs/QUESTIONS.md
|
|
186
|
+
- docs/REQUIREMENTS.md
|
|
187
|
+
- README.md
|
|
188
|
+
|
|
189
|
+
Please review the task and uncommitted changes, and make sure the task is complete, and done to satisfaction.
|
|
190
|
+
DO NOT trust the developer's notes, always review the code and build/test results yourself.
|
|
191
|
+
Look for typical 'cheating' patterns, such as turning off unit tests, taking files
|
|
192
|
+
out of the compilation configuration, and redefining the plan to skip tasks
|
|
193
|
+
that aren't working.
|
|
194
|
+
If there's a linter defined for this project, run it.
|
|
195
|
+
|
|
196
|
+
If the task is not complete, adjust the item in docs/PLAN.md with suggestions for
|
|
197
|
+
the developer to complete the task properly.
|
|
198
|
+
|
|
199
|
+
If the task is complete and we're happy with the code, run a git commit+push.
|
|
200
|
+
|
|
201
|
+
If you have any questions of the user for the future, you can add them to QUESTIONS.md.
|
|
202
|
+
If you have any ideas for the future, you can add them to IDEAS.md.
|
|
203
|
+
" | tee >(cat > $LOGFILE-tester)
|
|
204
|
+
|
|
205
|
+
sleep 1
|
|
206
|
+
done
|
|
207
|
+
|
|
208
|
+
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
#!/bin/bash
|
|
2
|
+
|
|
3
|
+
set -e
|
|
4
|
+
|
|
5
|
+
mkdir -p logs
|
|
6
|
+
|
|
7
|
+
# Use a temporary directory for tmp files, as codex is sandboxed to this directory
|
|
8
|
+
mkdir -p tmp
|
|
9
|
+
export TMPDIR=tmp/
|
|
10
|
+
|
|
11
|
+
# look for a brief file
|
|
12
|
+
if [ ! -f BRIEF.md ]; then
|
|
13
|
+
echo "No BRIEF.md file found, please create one first "
|
|
14
|
+
exit 1
|
|
15
|
+
fi
|
|
16
|
+
|
|
17
|
+
if [ "$EDITOR" == "" ]; then
|
|
18
|
+
EDITOR="nano"
|
|
19
|
+
fi
|
|
20
|
+
|
|
21
|
+
LOGFILE="logs/claude-$(date +%Y%m%d_%H%M%S).txt"
|
|
22
|
+
|
|
23
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
24
|
+
echo -e "\033[32m== ANALYZING PROJECT BRIEF\033[0m"
|
|
25
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
26
|
+
|
|
27
|
+
prompt1="
|
|
28
|
+
Read all of these documents if they exist:
|
|
29
|
+
- BRIEF.md -- the project brief
|
|
30
|
+
- docs/REQUIREMENTS.md -- the project requirements
|
|
31
|
+
- docs/PLAN.md -- the project plan
|
|
32
|
+
- docs/QUESTIONS.md -- the project questions
|
|
33
|
+
- docs/IDEAS.md -- the backlog of future ideas
|
|
34
|
+
- docs/WEBTESTS.md -- the project web tests
|
|
35
|
+
- README.md -- the project README
|
|
36
|
+
|
|
37
|
+
Your job, as a megathinking business analyst, project manager, architect and product manager, is to help solidify
|
|
38
|
+
the requirements and plan.
|
|
39
|
+
|
|
40
|
+
1. Read through all of these documents and follow any references on the web to read more background.
|
|
41
|
+
2. Add 10 relevant questions to docs/QUESTIONS.md to expand on the brief and requirements.
|
|
42
|
+
3. Create the document docs/QUESTIONS.md if it doesn't exist.
|
|
43
|
+
|
|
44
|
+
Try to think of typical assumptions an AI or developer would make, and add questions to address them directly.
|
|
45
|
+
|
|
46
|
+
As part of this work, please consider our SDLC and what infrastructure will need to be established to ensure
|
|
47
|
+
the system is compliant. Make sure the basics like a git repo and a pre-commit hook that call a custom
|
|
48
|
+
linter are in the plan to be established if they don't exist now.
|
|
49
|
+
Also make sure our work is being done on a feature branch.
|
|
50
|
+
Other than that, DO NOT get distracted by infrastructure, stick with the YAGNI principle.
|
|
51
|
+
Just ensure the basic branching and linter is working and move on.
|
|
52
|
+
Focus on the user's brief and answers from docs/QUESTIONS.md, and the plan.
|
|
53
|
+
"
|
|
54
|
+
|
|
55
|
+
# run BA's
|
|
56
|
+
echo "Running claude..."
|
|
57
|
+
claude --dangerously-skip-permissions -p "$prompt1" | tee >(cat > $LOGFILE-ba1)
|
|
58
|
+
echo "Running codex o3 (results won't display)..."
|
|
59
|
+
codex -m o3 --full-auto -q "$prompt1" > $LOGFILE-ba2
|
|
60
|
+
|
|
61
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
62
|
+
echo -e "\033[32m== ANSWER THE QUESTIONS IN QUESTIONS.md\033[0m"
|
|
63
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
64
|
+
|
|
65
|
+
echo "Press enter to continue..."
|
|
66
|
+
read -n 1 -s
|
|
67
|
+
|
|
68
|
+
echo "Opening QUESTIONS.md in $EDITOR..."
|
|
69
|
+
$EDITOR QUESTIONS.md
|
|
70
|
+
|
|
71
|
+
/usr/local/bin/claudefsd-plan-gen
|
|
@@ -0,0 +1,64 @@
|
|
|
1
|
+
#!/bin/bash
|
|
2
|
+
|
|
3
|
+
set -e
|
|
4
|
+
|
|
5
|
+
mkdir -p logs
|
|
6
|
+
|
|
7
|
+
# Use a temporary directory for tmp files, as codex is sandboxed to this directory
|
|
8
|
+
mkdir -p tmp
|
|
9
|
+
export TMPDIR=tmp/
|
|
10
|
+
|
|
11
|
+
# look for a brief file
|
|
12
|
+
if [ ! -f BRIEF.md ]; then
|
|
13
|
+
echo "No BRIEF.md file found, please create one first "
|
|
14
|
+
exit 1
|
|
15
|
+
fi
|
|
16
|
+
|
|
17
|
+
LOGFILE="logs/claude-$(date +%Y%m%d_%H%M%S).txt"
|
|
18
|
+
|
|
19
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
20
|
+
echo -e "\033[32m== PROCESSING THE QUESTIONS IN QUESTIONS.md\033[0m"
|
|
21
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
22
|
+
|
|
23
|
+
prompt2="
|
|
24
|
+
Read all of these documents if they exist:
|
|
25
|
+
- BRIEF.md -- the project brief
|
|
26
|
+
- docs/REQUIREMENTS.md -- the project requirements
|
|
27
|
+
- docs/PLAN.md -- the project plan
|
|
28
|
+
- docs/QUESTIONS.md -- the project questions
|
|
29
|
+
- docs/IDEAS.md -- the backlog of future ideas
|
|
30
|
+
- docs/WEBTESTS.md -- the project web tests
|
|
31
|
+
- README.md -- the project README
|
|
32
|
+
|
|
33
|
+
Your job, as a megathinking business analyst, project manager, architect and product manager, is to help solidify
|
|
34
|
+
the requirements and plan.
|
|
35
|
+
|
|
36
|
+
1. Read through these documents and pay particular attention to the questions and answers in QUESTIONS.md.
|
|
37
|
+
2. Update the docs/REQUIREMENTS.md and docs/PLAN.md documents to incorporate the full brief and all answers.
|
|
38
|
+
3. If the requirements and plan don't already exist, create them.
|
|
39
|
+
|
|
40
|
+
If the brief, questions or answers have been updated, the requirements and plan will need to be updated.
|
|
41
|
+
|
|
42
|
+
As part of this work, please consider our SDLC and what infrastructure will need to be established to ensure
|
|
43
|
+
the system is compliant. Make sure the basics like a git repo and a pre-commit hook that call a custom
|
|
44
|
+
linter are in the plan to be established if they don't exist now.
|
|
45
|
+
Also make sure our work is being done on a feature branch.
|
|
46
|
+
Other than that, DO NOT get distracted by infrastructure, stick with the YAGNI principle.
|
|
47
|
+
Just ensure the basic branching and linter is working and move on.
|
|
48
|
+
Focus on the user's brief and answers from docs/QUESTIONS.md, and the plan.
|
|
49
|
+
"
|
|
50
|
+
|
|
51
|
+
# run BA's
|
|
52
|
+
echo "Running claude..."
|
|
53
|
+
claude --dangerously-skip-permissions -p "$prompt2" | tee >(cat > $LOGFILE-ba3-$round)
|
|
54
|
+
echo "Running codex o3 (results won't display)..."
|
|
55
|
+
codex -m o3 --full-auto -q "$prompt2" > $LOGFILE-ba4-$round
|
|
56
|
+
|
|
57
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
58
|
+
echo -e "\033[32m== DONE\033[0m"
|
|
59
|
+
echo -e "\033[32m==================================================================\033[0m"
|
|
60
|
+
echo "You can now run claudefsd-dev to start the development process."
|
|
61
|
+
echo "Or do one more round of $0 to cover more questions."
|
|
62
|
+
|
|
63
|
+
|
|
64
|
+
|
package/package.json
ADDED
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "claude-fsd",
|
|
3
|
+
"version": "1.0.0",
|
|
4
|
+
"description": "Claude Full Stack Development tools for managing development projects",
|
|
5
|
+
"bin": {
|
|
6
|
+
"claudefsd-dev": "./bin/claudefsd-dev",
|
|
7
|
+
"claudefsd-plan": "./bin/claudefsd-plan",
|
|
8
|
+
"claudefsd-plan-gen": "./bin/claudefsd-plan-gen"
|
|
9
|
+
},
|
|
10
|
+
"keywords": [
|
|
11
|
+
"claude",
|
|
12
|
+
"development",
|
|
13
|
+
"project-management",
|
|
14
|
+
"cli"
|
|
15
|
+
],
|
|
16
|
+
"author": "",
|
|
17
|
+
"license": "MIT",
|
|
18
|
+
"repository": {
|
|
19
|
+
"type": "git",
|
|
20
|
+
"url": "https://github.com/yourusername/claude-fsd.git"
|
|
21
|
+
},
|
|
22
|
+
"engines": {
|
|
23
|
+
"node": ">=14.0.0"
|
|
24
|
+
}
|
|
25
|
+
}
|