carps 0.2.1

data/features/character_sheet.feature

@@ -0,0 +1,40 @@
+Feature: character sheets
+   As a CARPS player,
+   In order to play an RPG,
+   You need a character,
+   So you need a character sheet.
+
+   Scenario: fill in character sheet
+      Given carps is initialized with test/client
+      Given a character sheet schema
+      Given a sheet editor
+      Then fill in the character sheet
+
+   Scenario: parsable character sheet
+      When an parsable sheet is provided
+      Then parse the sheet
+
+   Scenario: unparsable character sheet
+      When an unparsable sheet is provided
+      Then do not parse the sheet
+
+   Scenario: fill in the sheet again
+      Given carps is initialized with test/client
+      Given a character sheet schema
+      Given a sheet editor
+      Then fill in the character sheet 
+      Then edit the character sheet again
+
+   Scenario: accept valid character sheet
+      Given carps is initialized with test/client
+      Given a character sheet schema
+      Given a sheet editor
+      When a valid sheet is provided
+      Then accept the valid sheet
+
+   Scenario: do not accept invalid character sheet
+      Given carps is initialized with test/client
+      Given a character sheet schema
+      Given a sheet editor
+      When an invalid sheet is provided
+      Then do not accept the invalid sheet

data/features/crash.feature

@@ -0,0 +1,15 @@
+Feature: crash
+
+   As a CARPS user,
+   If CARPS were to unfortunately crash,
+   Perhaps because its developer is a tool,
+   I expect a nice crash report that doesn't
+   mess up my screen.
+
+   Scenario: no crash
+      Given a proc that won't crash
+      Then the crash reporter won't report a crash
+
+   Scenario: crash
+      Given a proc that will crash
+      Then the crash reporter will report a crash

data/features/crypt.feature

@@ -0,0 +1,22 @@
+Feature: cryptography
+   In order for CARPS peers to communicate without the risk of someone pretending to be a peer when he isn't
+   CARPS must
+   sign each message using strong public key cryptography
+
+   Scenario: handshake
+      Given two peers, Alice and Bob
+      Then Alice initiates a handshake request and Bob accepts
+      When the user presses enter, threading stops
+
+   Scenario: hacker
+      Given two peers, Alice and Bob
+      Then Alice initiates a handshake request and Bob accepts
+      Then a hacker pretending to be Alice sends a nefarious message to Bob
+      Then bob tries to receive the message
+      When the user presses enter, threading stops
+
+   Scenario: spoofer
+      Given two peers, Alice and Bob
+      Then Alice initiates a handshake request and Bob accepts
+      Then a spoofer pretending to be Bob tries to make a handshake with Alice
+      When the user presses enter, threading stops

data/features/dice.feature

@@ -0,0 +1,173 @@
+Feature: rules
+   As a CARPS mod writer,
+   in order to efficiently encode game rules,
+   I need a high level interface to non-determinism.
+   IE, show me the dice!
+
+   Scenario: one dice 
+      Given a d3
+      Then show the odds
+      Then each of the odds must be 1 / 3
+      Then result 0 must be 1
+      Then result 1 must be 2
+      Then result 2 must be 3
+
+   Scenario: one dice and multiplication
+      Given a d3
+      Then multiply by 3
+      Then show the odds
+      Then each of the odds must be 1 / 3
+      Then result 0 must be 3
+      Then result 1 must be 6
+      Then result 2 must be 9
+
+   Scenario: one dice and addition
+      Given a d3
+      Then add 5
+      Then show the odds
+      Then each of the odds must be 1 / 3
+      Then result 0 must be 6
+      Then result 1 must be 7
+      Then result 2 must be 8
+
+   Scenario: one dice, fractional multiplication
+      Given a d6
+      Then multiply by 1 / 2
+      Then show the odds
+      Then result 0 must be 0
+      Then result 1 must be 1
+      Then result 2 must be 2
+      Then result 3 must be 3
+      Then odd 0 must be 1 / 6
+      Then odd 1 must be 1 / 3
+      Then odd 2 must be 1 / 3
+      Then odd 3 must be 1 / 6
+
+   Scenario: one dice, multiplication and addition 
+      Given a d3
+      Then multiply by 3
+      Then add 5
+      Then show the odds
+      Then each of the odds must be 1 / 3
+      Then result 0 must be 8
+      Then result 1 must be 11
+      Then result 2 must be 14
+
+   Scenario: one dice and division
+      Given a d3
+      Then divide by 2
+      Then show the odds
+      Then odd 0 must be 1 / 3
+      Then odd 1 must be 2 / 3
+      Then result 0 must be 0
+      Then result 1 must be 1
+
+   Scenario: one dice and range analysis
+      Given a d3
+      Then if it's greater or equal to 1, and less than or equal to 2, the result is 0
+      Then show the odds
+      Then odd 0 must be 2 / 3
+      Then odd 1 must be 1 / 3
+
+   Scenario: two dice and addition
+      Given a d2
+      Then add a d3
+      Then show the odds
+      Then odd 0 must be 1 / 6
+      Then odd 1 must be 1 / 3
+      Then odd 2 must be 1 / 3
+      Then odd 3 must be 1 / 6
+      Then result 0 must be 2
+      Then result 1 must be 3
+      Then result 2 must be 4
+      Then result 3 must be 5
+
+   Scenario: two dice and subtraction
+      Given a d2
+      Then subtract a d3
+      Then show the odds
+      Then result 0 must be -2
+      Then result 1 must be -1
+      Then result 2 must be 0
+      Then result 3 must be 1
+      Then odd 0 must be 1 / 6
+      Then odd 1 must be 1 / 3
+      Then odd 2 must be 1 / 3
+      Then odd 3 must be 1 / 6
+
+
+   Scenario: two dice and multiplication
+      Given a d3
+      Then multiply by a d2
+      Then show the odds
+      Then odd 0 must be 1 / 6
+      Then odd 1 must be 1 / 3
+      Then odd 2 must be 1 / 6
+      Then odd 3 must be 1 / 6
+      Then odd 4 must be 1 / 6
+      Then result 0 must be 1
+      Then result 1 must be 2
+      Then result 2 must be 3
+      Then result 3 must be 4
+      Then result 4 must be 6
+
+   Scenario: two dice and division
+      Given a d3
+      Then divide by a d2
+      Then show the odds
+      Then odd 0 must be 1 / 6
+      Then odd 1 must be 1 / 2
+      Then odd 2 must be 1 / 6
+      Then odd 3 must be 1 / 6
+      Then result 0 must be 0
+      Then result 1 must be 1
+      Then result 2 must be 2
+      Then result 3 must be 3
+
+   Scenario: two dice and range analysis
+      Given a d3
+      Then if it's greater or equal to 1, and less than or equal to 2, the result is a d4
+      Then show the odds
+      Then result 0 must be 1
+      Then result 1 must be 2
+      Then result 2 must be 3
+      Then result 3 must be 4
+      Then odd 0 must be 1 / 6
+      Then odd 1 must be 1 / 6
+      Then odd 2 must be 1 / 2
+      Then odd 3 must be 1 / 6
+
+   Scenario: two dice, uneven weights and range analysis
+      Given a d4
+      Then multiply by 2
+      Then if it's greater or equal to 2, and less than or equal to 2, the result is a d4
+      Then show the odds
+      Then result 0 must be 1
+      Then result 1 must be 2
+      Then result 2 must be 3
+      Then result 3 must be 4
+      Then result 4 must be 6
+      Then result 5 must be 8
+      Then odd 0 must be 1 / 16
+      Then odd 1 must be 1 / 16
+      Then odd 2 must be 1 / 16
+      Then odd 3 must be 5 / 16
+      Then odd 4 must be 1 / 4
+      Then odd 5 must be 1 / 4
+
+   Scenario: binary comparison
+      Given a d5
+      Then if it's greater than 3, the result is 4
+      Then show the odds
+      Then result 0 must be 1
+      Then result 1 must be 2
+      Then result 2 must be 3
+      Then result 3 must be 4
+      Then odd 0 must be 1 / 5
+      Then odd 1 must be 1 / 5
+      Then odd 2 must be 1 / 5
+      Then odd 3 must be 2 / 5
+
+   Scenario: roll dice
+      Given a d4
+      Then roll the dice

data/features/dm.feature

@@ -0,0 +1,36 @@
+Feature: High-level DM interface
+
+   Scenario: produce report 
+      Given carps is initialized with test/server
+      Given a DM mod
+      Given a character sheet schema
+      When barry joins the mod
+      Then check barry's sheet
+      Then set barry's status conditionally
+      Then preview player turns
+
+   Scenario: create npc
+      Given carps is initialized with test/server
+      Given a DM mod
+      Given a character sheet schema
+      Then create an NPC called paul of type orange 
+      When barry joins the mod
+      Then check barry's sheet
+      Then report the strength of the NPC paul to barry
+      Then preview player turns
+
+   Scenario: test inputs
+      Given carps is initialized with test/server
+      Given a DM mod
+      Given a character sheet schema
+      When barry joins the mod
+      Given a DM interface
+      Then test all inputs to interface
+
+   Scenario: user interaction
+      Given carps is initialized with test/server
+      Given a DM mod
+      Given a character sheet schema
+      When barry joins the mod
+      Given a DM interface
+      Then present a user interface to the DM

data/features/dmll.feature

@@ -0,0 +1,51 @@
+Feature: Low-level DM interface components
+   The DM requires a powerful interface
+   To communicate with the players
+
+   Scenario: produce reports
+      Given carps is initialized with test/server
+      Given a resource manager
+      Given a reporter
+      Then the reporter is registered with the resource manager
+      Given barry are in the cave
+      Then take turns for barry 
+
+   Scenario: produce customized report
+      Given carps is initialized with test/server
+      Given a resource manager
+      Given a reporter
+      Then the reporter is registered with the resource manager
+      Given carps is initialized with test/server
+      Given barry are in the cave
+      Then customize report for barry 
+      Then take turns for barry 
+
+   Scenario: change rooms
+      Given carps is initialized with test/server
+      Given a resource manager
+      Given a reporter
+      Then the reporter is registered with the resource manager
+      Given barry are in the cave
+      Then take turns for barry
+      Given barry are in the ship 
+      Then take turns for barry
+
+   Scenario: different rooms
+      Given carps is initialized with test/server
+      Given a resource manager
+      Given a reporter
+      Then the reporter is registered with the resource manager
+      Given barry are in the cave
+      Given paul are in the ship
+      Then take turns for barry paul
+
+   Scenario: individual question
+      Given a reporter
+      Then ask barry: do you like paul?
+      Then ask paul: does barry smell?
+      Then take turns for barry paul
+
+   Scenario: create NPC
+      Given carps is initialized with test/server
+      Given a resource manager
+      Then create an NPC of type human

data/features/edit.feature

@@ -0,0 +1,10 @@
+Feature: editor
+
+   As a CARPS user,
+   to edit character sheets and stuff,
+   I want to use a text editor.
+
+   Scenario: edit text
+      Given carps is initialized with test/client
+      Given a text editor
+      Then edit some text

data/features/email.feature

@@ -0,0 +1,29 @@
+Feature: email
+   In order for CARPS peers to communicate over the network in a distributed fashion
+   CARPS should be able to
+   Send and receive emails
+
+   Scenario: send email
+      Given carps is initialized with test/client
+      Given default IMAP settings
+      Given default SMTP settings
+      Given the email account
+      Then an email is sent
+
+   Scenario: receive email
+      Given carps is initialized with test/client
+      Given default IMAP settings
+      Given default SMTP settings
+      Given the email account
+      Then an email is received
+
+   Scenario: SMTP security
+      Given carps is initialized with test/client
+      Given default SMTP settings
+      Then attempt connections with various SMTP security settings
+
+
+   Scenario: IMAP security
+      Given carps is initialized with test/client
+      Given default IMAP settings 
+      Then attempt connections with various IMAP security settings

data/features/interface.feature

@@ -0,0 +1,17 @@
+Feature: user interface
+   In order for people to use carps
+   Well
+   They have to be able to use it
+
+   Scenario: user interface
+      Given a cheesey interface
+      Then present the cheesey interface to the user
+
+   # This is important because it lets me know when a interface is broken
+   # Also, it corrects the problem
+   # Further, it's best to tell the user rather than silently drop it
+   # in case they think it is supposed to have the option and are surprised 
+   # when it doesn't
+   Scenario: broken interface
+      Given a broken interface created by a drunk
+      Then present the interface, reporting the mistake to the user

data/features/ipc.feature

@@ -0,0 +1,10 @@
+Feature:  Interprocess Communication
+   In order to launch mods
+   CARPS should be able to
+   fork subprograms and communicate with them
+
+   Scenario: fork subprogram in another shell
+      Given carps is initialized with test/client
+      Given an object to be mutated
+      When the Process.launch method is called with the name of a ruby subprogram, which I should see in another window
+      Then I should see 'It works' from the server side 

data/features/mailbox.feature

@@ -0,0 +1,33 @@
+Feature: mailbox
+   As a CARPS user,
+   I need a way to reliably send and receive emails.
+
+   Scenario: mail persistence
+      Given carps is initialized with test/client
+      Then .mail is cleaned
+      Given a session manager
+      Given a testing mailbox
+      Then send mail with session 1 to the mailbox
+      When the user presses enter, continue
+      Given a testing mailbox
+      Then receive mail with session 1
+
+   Scenario: no session
+      Given carps is initialized with test/client
+      Then .mail is cleaned
+      Given a session manager
+      Given a testing mailbox
+      Then send mail with session 1 to the mailbox
+      Then receive mail with session 1
+
+   Scenario: session
+      Given carps is initialized with test/client
+      Then .mail is cleaned
+      Given a session manager
+      Given a testing mailbox
+      Then send mail with session 1 to the mailbox
+      Then send mail with session 2 to the mailbox
+      Then set session to 2
+      Then receive mail with session 2 
+      Then check that the mail with session 1 has not been received
+

data/features/mod.feature

@@ -0,0 +1,31 @@
+Feature: mods
+   In order to play or host a game
+   A mod needs to be executed
+
+   Scenario: resume dm mod
+      Given carps is initialized with test/server
+      Given a session manager
+      Given a dm game config, for mod test
+      Then resume the mod
+
+   Scenario: save and load dm mod
+      Given carps is initialized with test/server
+      Given a session manager
+      Given a dm game config, for mod saver
+      Then resume the mod
+      Then load the DM mod
+      Then resume the mod
+
+   Scenario: save and load player mod
+      Given carps is initialized with test/client
+      Given a session manager
+      Given a player game config, for mod saver
+      Then resume the mod
+      Then load the Player mod
+      Then resume the mod
+
+   Scenario: resume player mod
+      Given carps is initialized with test/client
+      Given a session manager
+      Given a player game config, for mod test
+      Then resume the mod

data/features/parser.feature

@@ -0,0 +1,9 @@
+Feature: message parsing
+   In order to send complicated messages through the ether
+   They must be parsed
+
+   Scenario: parse invitation
+      When an invitation is sent
+      Given a parser
+      Then emit the message
+      Then parse the message

data/features/persistent_protocol.feature

@@ -0,0 +1,14 @@
+Feature: persistent protocol
+   In order to continue playing carps,
+   between runs of the program,
+   without odd glitches occuring,
+   there must be persistency at the protocol level.
+
+   Scenario: persistent message
+      Given carps is initialized with test/client
+      Given a persistent message
+      Then save the message, noting the file name
+      Then make sure the file exists 
+      Then delete the message
+      Then make sure the file was deleted
+      

data/features/player.feature

@@ -0,0 +1,22 @@
+Feature: Player interface
+   In order to play carps
+   the player needs to be able
+   to interact with a mod
+
+   Scenario: player user interaction
+      Given a character sheet schema
+      Given carps is initialized with test/client
+      Given a player test mailer
+      Given a player mod
+      When the player receives turn information
+      Given a player interface
+      Then present a user interface to the player
+
+   Scenario: test inputs
+      Given a character sheet schema
+      Given carps is initialized with test/client
+      Given a player test mailer
+      Given a player mod
+      When the player receives turn information
+      Given a player interface
+      Then test all inputs to the player's interface

data/features/player_turn.feature

@@ -0,0 +1,29 @@
+Feature: client turns
+   In order for people to play a game
+   The players must be able to
+   Answer questions set by the Dungeon Master
+
+   Scenario: answer question
+      Given a question
+      Then the question should be asked
+
+   Scenario: read report
+      Given a status report
+      Then the status report should be printed
+
+   Scenario: take turn
+      Given a status report and a number of questions
+      Then all the questions should be asked
+
+   Scenario: parse answers
+      Given answers from a player's turn
+      Given a parser for the answers
+      Then emit the message
+      Then parse the message
+
+   Scenario: parse turn
+      Given a status report and a number of questions
+      When a turn is sent
+      Given a parser for the turn
+      Then emit the message
+      Then parse the message

data/features/random.feature

@@ -0,0 +1,15 @@
+Feature: dice
+   In order to play an RPG
+   You have to whittle some dice
+
+   Scenario: random integer
+      Given 1000 random integers between 12 and 15
+      Then ensure each of the random numbers are between 12 and 15
+
+   Scenario: random float
+      Given 1000 random floats between 35 and 40
+      Then ensure each of the random numbers are between 35 and 40
+
+   Scenario: probabalistic interface
+      Given an interface to dice rolling
+      Then launch the probabalistic interface

data/features/rule.feature

@@ -0,0 +1,19 @@
+Feature: rules
+   As a CARPS mod writer,
+   attempting to encode a game into a CARPS mod,
+   in order to manipulate character sheets in accordance
+   with the game manuals,
+   I require a high level interface for writing rules.
+
+   Scenario: show odds for rule on a character sheet
+      Given a character sheet schema
+      When a valid sheet is provided
+      Given a rule which operates on a character sheet
+      Then show the odds for the rule
+
+   Scenario: apply rule on a character sheet
+      Given a character sheet schema
+      When a valid sheet is provided
+      Given a rule which operates on a character sheet
+      Then apply the rule
+

data/features/safety.feature

@@ -0,0 +1,13 @@
+Feature: safety
+   As a CARPS user,
+   you essentially run untrusted programs,
+   in response to emails,
+   it's probably a good idea to use $SAFE.
+
+# This doesn't work, probably bug in cucumber
+
+   Scenario: Perform operations under SAFE
+#      Given $SAFE is 1
+#      Then allow checking a file, given by user input, exists
+#      Then disallow eval in response to user input
+

data/features/sessions.feature

@@ -0,0 +1,16 @@
+Feature: sessions
+   As a CARPS player,
+   whose going to play more than one game,
+   across a period of weeks,
+   it's desirable for the system to have sessions support,
+   because that means that while playing one game,
+   I won't receive a message
+   intended for a different game.
+
+   Scenario: accept message for this session
+      Given a session manager
+      Then accept a message meant for this session
+
+   Scenario: deny message intended for another session
+      Given a session manager
+      Then deny a message intended for another session

data/features/start_dm.feature

@@ -0,0 +1,18 @@
+Feature: start a game
+   In order to play carps, the dm must start a game
+
+   Scenario: start new game
+      Given carps is initialized with test/server
+      Given a session manager
+      Then host a new game called rot with resource campaign and mod fruit
+      Then save the game as rot.yaml
+
+   Scenario: resume game
+      Given carps is initialized with test/server
+      Given a session manager
+      Then the dm resumes a previous game called rot.yaml
+
+   Scenario: DM start game interface
+      Given a session manager
+      Given carps is initialized with test/server
+      Then present the start game interface to the dm

data/features/start_player.feature

@@ -0,0 +1,8 @@
+Feature: player initialization
+
+   Scenario: player start game interface
+      Given carps is initialized with test/client
+      Given a session manager
+      Given a mailer stub for the player start interface
+      When an invite is sent to the player
+      Then present the start game interface to the player