@tekyzinc/gsd-t 2.0.0

package/commands/gsd-t-brainstorm.md

@@ -0,0 +1,171 @@
+# GSD-T: Brainstorm — Creative Exploration and Rethinking
+
+You are a thinking partner. Your job is to help the user explore ideas, challenge assumptions, generate alternatives, and break out of tunnel vision. Unlike `discuss` (which produces contracts) or `prompt` (which produces a structured brief), brainstorm produces **insight** — new angles, reframed problems, and unexpected connections.
+
+This command is lightweight — no mandatory state file updates, no commits. Ideas flow freely. Actionable outcomes get captured at the end only if the user wants them.
+
+## Step 1: Load Context (if available)
+
+If inside a GSD-T project, read what's relevant:
+1. `CLAUDE.md` — understand the project
+2. `.gsd-t/progress.md` — where things stand
+3. `.gsd-t/roadmap.md` (if exists) — the plan
+4. `.gsd-t/techdebt.md` (if exists) — known pain points
+5. `docs/` — requirements, architecture
+
+If no project context exists, that's fine — brainstorm works without it.
+
+## Step 2: Determine the Mode
+
+From $ARGUMENTS and conversation, identify what kind of brainstorm this is:
+
+### A) Ideation — "What could we build?"
+The user wants to generate new ideas, features, products, or directions.
+- Cast a wide net first, then narrow
+- Use "yes, and" thinking — build on ideas rather than filtering early
+- Aim for quantity before quality
+
+### B) Enhancement — "How could we improve this?"
+The user has something that works but wants it better.
+- Start by understanding what's working and why
+- Identify friction points, missed opportunities, underserved users
+- Look at adjacent products/patterns for inspiration
+- Consider both incremental improvements and step-change upgrades
+
+### C) Rethink — "Are we approaching this wrong?"
+The user suspects a fundamental assumption is flawed or wants fresh perspective.
+- Surface and name the current assumptions explicitly
+- Challenge each one: "What if the opposite were true?"
+- Look for constraint inversion: "What if the thing we're avoiding is the answer?"
+- Consider: problem reframing, user reframing, technology reframing
+
+### D) Unstuck — "I don't know what to do next"
+The user is blocked, overwhelmed, or lost momentum.
+- Don't solve immediately — listen first
+- Break the problem down: what specifically is stuck?
+- Offer multiple small next moves, not one big plan
+- Sometimes the answer is to simplify, not add
+
+### E) Blue Sky — "Let's think big"
+No constraints, no timeline, just explore what's possible.
+- Remove all practical limitations first: "If time, money, and skill were unlimited..."
+- Then progressively reintroduce constraints to find the interesting tension
+- Look for ideas that are 10x, not 10%
+
+If mode is unclear, ask: "What kind of thinking would be most useful right now — generating new ideas, improving what exists, questioning your approach, or getting unstuck?"
+
+## Step 3: Run the Brainstorm
+
+### Techniques to Use (pick what fits):
+
+**Divergent Thinking (generating options)**
+- **Random Input**: Pick an unrelated concept and force a connection. "What if your auth system worked like a library card?" "What if the deploy process was like ordering coffee?"
+- **Worst Idea First**: Start with intentionally bad ideas — they often invert into good ones
+- **User Hat-Switching**: How would a power user see this? A beginner? A competitor? Someone who hates your product?
+- **Constraint Removal**: "If we didn't have to worry about {X}, what would we do?" Then: "Actually, can we remove that constraint?"
+- **Analogy Mining**: What solved a similar problem in a completely different domain?
+
+**Convergent Thinking (evaluating options)**
+- **2x2 Matrix**: Plot ideas on Impact vs. Effort, or Certainty vs. Potential
+- **Pre-mortem**: "It's 6 months from now and this failed. Why?"
+- **Regret Minimization**: "Which of these would you regret NOT trying?"
+- **First Principles**: Strip away convention. What must actually be true?
+
+**Reframing Techniques**
+- **Flip the Problem**: Instead of "how do we get more users?" ask "why would someone NOT use this?"
+- **Change the Unit**: Instead of optimizing one thing, what if you optimized something upstream or downstream?
+- **Time Shift**: How would you solve this if you had 10x more time? 10x less?
+- **Audience Shift**: What if this wasn't for your current users but for {different group}?
+
+### Conversation Rhythm:
+1. Explore one thread for 2-3 exchanges
+2. Summarize what's emerged
+3. Ask: "Want to go deeper on this, or explore a different angle?"
+4. When energy shifts to a new idea, follow it
+5. Periodically collect the best ideas into a running list
+
+### Team Mode (if enabled and user requests):
+```
+Create an agent team for brainstorming:
+
+- Teammate "visionary": Push boundaries. What's the most ambitious 
+  version? What would make this remarkable? Think in terms of 
+  possibilities, not constraints.
+
+- Teammate "pragmatist": Keep it real. What can we actually build?
+  What's the shortest path to value? Where are the hidden costs?
+
+- Teammate "devil's advocate": Challenge everything. Why might this 
+  fail? What are we not seeing? Which assumptions are weakest?
+
+Lead: Synthesize the best insights from all three perspectives.
+```
+
+## Step 4: Capture the Sparks
+
+As ideas emerge, maintain a running list. Don't over-organize — just capture:
+
+```
+## Brainstorm Notes — {date}
+
+### Ideas Worth Exploring
+1. {idea} — {why it's interesting}
+2. {idea} — {why it's interesting}
+3. {idea} — {why it's interesting}
+
+### Assumptions Challenged
+- We assumed {X} — but what if {Y}?
+- We assumed {X} — still valid because {reason}
+
+### Reframes
+- Instead of {old frame}, think about it as {new frame}
+
+### Questions to Answer
+- {question that would unlock a decision}
+- {question that needs research}
+
+### Parking Lot (interesting but not now)
+- {idea for later}
+```
+
+## Step 5: Land the Brainstorm
+
+When energy winds down or the user signals they're done, transition:
+
+"Here's what stood out to me from this session:"
+
+1. **Top 3 ideas** — the ones with the most energy and potential
+2. **Key insight** — the single most valuable reframe or discovery
+3. **Immediate next move** — one small, concrete thing to do with this thinking
+
+Then offer to connect back to GSD-T:
+
+"Want to turn any of these into action?"
+- **New project idea** → "Run `/user:gsd-t-prompt` to structure it, then `/user:gsd-t-project`"
+- **Enhancement to existing work** → "Run `/user:gsd-t-feature {idea}`"
+- **Fundamental rethink of current milestone** → "Let's revisit the milestone scope — run `/user:gsd-t-milestone` to redefine"
+- **Tech debt or architectural concern** → "Add to `.gsd-t/techdebt.md` and promote when ready"
+- **Just capture for later** → Save brainstorm notes to `.gsd-t/brainstorm-{date}.md`
+- **None yet — still marinating** → "No worries. The notes are here when you're ready."
+
+## Step 6: Optionally Save State
+
+If the user wants to save, create `.gsd-t/brainstorm-{date}.md` with the captured notes.
+
+If inside an active milestone and the brainstorm produced decisions:
+- Log key decisions in `.gsd-t/progress.md` Decision Log
+- Update contracts only if the user explicitly confirms a direction
+
+**Do NOT auto-update contracts or docs from a brainstorm.** Brainstorms generate options; decisions happen in discuss/plan phases.
+
+## Conversation Style
+
+- Be a collaborator, not an interviewer — contribute ideas, not just questions
+- Match the user's energy: if they're excited, build momentum; if they're frustrated, slow down and listen
+- Use "What if..." and "Have you considered..." rather than "You should..."
+- Make unexpected connections — the best brainstorm insights come from non-obvious angles
+- Keep it fun — brainstorming should feel energizing, not like a status meeting
+- It's OK to go on tangents — the detour is often where the insight lives
+- When you sense a breakthrough idea, name it: "That feels like the real insight here"
+
+$ARGUMENTS

package/commands/gsd-t-complete-milestone.md

@@ -0,0 +1,171 @@
+# GSD-T: Complete Milestone — Archive and Tag Release
+
+You are finalizing a completed milestone. Your job is to archive the milestone documentation, create a git tag, and prepare for the next milestone.
+
+This command is:
+- **Auto-invoked** at the end of `/user:gsd-t-wave` after verify passes
+- **Standalone** when user wants to manually close a milestone
+
+## Step 1: Verify Completion
+
+Read:
+1. `.gsd-t/progress.md` — confirm status is VERIFIED
+2. `.gsd-t/verify-report.md` — confirm all checks passed
+
+If status is not VERIFIED:
+"⚠️ Milestone not yet verified. Run `/user:gsd-t-verify` first, or use `--force` to complete anyway."
+
+If `--force` flag provided, proceed with warning in archive.
+
+## Step 2: Gather Milestone Artifacts
+
+Collect all files related to this milestone:
+- `.gsd-t/progress.md` (current state)
+- `.gsd-t/verify-report.md`
+- `.gsd-t/impact-report.md` (if exists)
+- `.gsd-t/test-coverage.md` (if exists)
+- `.gsd-t/domains/*/` (all domain folders)
+- `.gsd-t/contracts/` (snapshot)
+
+## Step 3: Create Archive
+
+Create milestone archive directory:
+
+```
+.gsd-t/milestones/{milestone-name}-{date}/
+├── progress.md           # Final state
+├── verify-report.md      # Verification results
+├── impact-report.md      # Impact analysis (if any)
+├── test-coverage.md      # Test sync report (if any)
+├── summary.md            # Generated summary (see below)
+├── contracts/            # Contract snapshot at completion
+│   └── ...
+└── domains/              # Domain artifacts
+    └── ...
+```
+
+## Step 4: Generate Summary
+
+Create `summary.md`:
+
+```markdown
+# Milestone Complete: {name}
+
+**Completed**: {date}
+**Duration**: {start date} → {end date}
+**Status**: {VERIFIED | FORCED}
+
+## What Was Built
+{Extract from progress.md and domain scopes}
+
+## Domains
+| Domain | Tasks Completed | Key Deliverables |
+|--------|-----------------|------------------|
+| {name} | {N} | {summary} |
+
+## Contracts Defined/Updated
+- {contract}: {new | updated | unchanged}
+
+## Key Decisions
+{Extract from Decision Log in progress.md}
+
+## Issues Encountered
+{Extract any remediation tasks or blocked items}
+
+## Test Coverage
+- Tests added: {N}
+- Tests updated: {N}
+- Coverage: {if known}
+
+## Git Tag
+`{tag-name}`
+
+## Files Changed
+{Summary of files created/modified/deleted}
+```
+
+## Step 5: Clean Working State
+
+Reset `.gsd-t/` for next milestone:
+
+1. Archive current domains → `.gsd-t/milestones/{name}/domains/`
+2. Clear `.gsd-t/domains/` (empty, ready for next partition)
+3. Archive current reports → milestone folder
+4. Clear `.gsd-t/impact-report.md`, `.gsd-t/test-coverage.md`
+5. Update `.gsd-t/progress.md`:
+
+```markdown
+# GSD-T Progress
+
+## Current Milestone
+None — ready for next milestone
+
+## Completed Milestones
+| Milestone | Completed | Tag |
+|-----------|-----------|-----|
+| {name} | {date} | {tag} |
+| {previous} | {date} | {tag} |
+
+## Decision Log
+{Keep the decision log — it's valuable context}
+```
+
+## Step 6: Create Git Tag
+
+```bash
+# Stage any remaining .gsd-t changes
+git add .gsd-t/
+
+# Commit the archive
+git commit -m "milestone({milestone-name}): complete and archive"
+
+# Create annotated tag
+git tag -a "milestone/{milestone-name}" -m "Milestone: {name}
+
+{Brief description from summary}
+
+Domains: {list}
+Verified: {date}"
+```
+
+## Step 7: Report Completion
+
+```
+✅ Milestone "{name}" completed!
+
+📁 Archived to: .gsd-t/milestones/{name}-{date}/
+🏷️  Tagged as: milestone/{name}
+
+Summary:
+- Domains completed: {N}
+- Tasks completed: {N}
+- Contracts: {N} defined/updated
+- Tests: {N} added/updated
+
+Next steps:
+- Push tags: git push origin milestone/{name}
+- Start next milestone: /user:gsd-t-milestone "{next name}"
+- Or view roadmap: /user:gsd-t-status
+```
+
+## Step 8: Update Roadmap (if exists)
+
+If `.gsd-t/roadmap.md` exists:
+- Mark this milestone as complete
+- Update any dependent milestones
+- Highlight next recommended milestone
+
+## Error Handling
+
+### If verify failed:
+"Cannot complete — verification found issues. Address them first or use `--force`."
+
+### If no milestone active:
+"No active milestone to complete. Run `/user:gsd-t-status` to see state."
+
+### If git operations fail:
+- Still create archive
+- Report git error
+- Provide manual tag command
+
+$ARGUMENTS

package/commands/gsd-t-debug.md

@@ -0,0 +1,88 @@
+# GSD-T: Debug — Systematic Debugging with Contract Awareness
+
+You are debugging an issue in a contract-driven project. Your approach should identify whether the bug is within a domain or at a contract boundary.
+
+## Step 1: Load Context
+
+Read:
+1. `CLAUDE.md`
+2. `.gsd-t/progress.md`
+3. `.gsd-t/contracts/` — all contracts
+4. `.gsd-t/domains/*/scope.md` — domain boundaries
+
+## Step 2: Classify the Bug
+
+Based on the user's description ($ARGUMENTS), determine:
+
+### A) Within-Domain Bug
+The issue is entirely inside one domain's scope. Symptoms:
+- Error occurs in files owned by a single domain
+- No cross-domain data flow involved
+- Logic error, typo, missing validation within one area
+
+→ Debug within that domain's files. Fix and verify against domain's acceptance criteria.
+
+### B) Contract Boundary Bug
+The issue occurs where domains interact. Symptoms:
+- Data shape mismatch between producer and consumer
+- API returns unexpected format
+- UI sends wrong payload to backend
+- Auth middleware doesn't integrate correctly with routes
+
+→ Check the relevant contract first. Is the contract correct? Does the implementation match?
+
+### C) Contract Gap
+The contract didn't specify something it should have. Symptoms:
+- Edge case not covered in contract
+- Error handling not specified
+- Race condition at boundary
+- Missing contract entirely
+
+→ Update the contract, then fix implementations on both sides.
+
+## Step 3: Debug (Solo or Team)
+
+### Solo Mode
+1. Reproduce the issue
+2. Trace through the relevant domain(s)
+3. Check contract compliance at each boundary
+4. Identify root cause
+5. Fix and test
+6. Update contracts if needed
+
+### Team Mode (for complex cross-domain bugs)
+```
+Create an agent team to debug:
+- Teammate 1: Investigate in {domain-1} — check implementation 
+  against contracts, trace data flow
+- Teammate 2: Investigate in {domain-2} — check implementation 
+  against contracts, trace data flow
+- Teammate 3: Check all contracts for gaps or ambiguities 
+  related to the failing scenario
+
+First to find root cause: message the lead with findings.
+```
+
+## Step 4: Document Ripple
+
+After fixing, assess what documentation was affected by the change and update ALL relevant files:
+
+### Always check:
+1. **`.gsd-t/progress.md`** — Add to Decision Log: what broke, why, and the fix
+2. **`.gsd-t/contracts/`** — Update any contract if the fix changed an interface, schema, or API shape
+3. **Domain `constraints.md`** — Add a "must not" rule if the bug was caused by a pattern that should be avoided
+
+### Check if affected:
+4. **`docs/requirements.md`** — Did the fix reveal a missing or incorrect requirement? Update it
+5. **`docs/architecture.md`** — Did the fix change architectural patterns, data flow, or component relationships? Update it
+6. **`docs/schema.md`** — Did the fix modify the database schema? Update it
+7. **`.gsd-t/techdebt.md`** — Did the fix reveal related debt? Add a new TD item. Did it resolve an existing one? Mark it complete
+8. **Domain `scope.md`** — Did the fix add new files or change ownership? Update it
+9. **Domain `tasks.md`** — If the bug was in an active milestone, update task status or add a remediation task
+10. **`CLAUDE.md`** — Did the fix establish a new convention or pattern that future work should follow? Add it
+
+### Skip what's not affected — don't update docs for the sake of updating them.
+
+Commit: `[debug] Fix {description} — root cause: {explanation}`
+
+$ARGUMENTS

package/commands/gsd-t-discuss.md

@@ -0,0 +1,100 @@
+# GSD-T: Discuss — Multi-Perspective Design Exploration
+
+You are the lead agent exploring design decisions before committing to a plan. The goal of this phase is to produce or refine **contracts** — not just recommendations.
+
+## Step 1: Load Context
+
+Read in order:
+1. `CLAUDE.md`
+2. `.gsd-t/progress.md`
+3. `.gsd-t/contracts/` — all existing contracts
+4. `.gsd-t/domains/` — all domain scopes
+5. `docs/` — requirements, architecture, schema, design docs
+
+## Step 2: Identify Open Questions
+
+Based on the milestone and current contracts, identify what's unresolved:
+- Architecture decisions not yet made
+- Contract details that are vague or missing
+- Technical approaches with multiple viable options
+- Risk areas that need exploration
+
+List these as numbered questions.
+
+## Step 3: Explore (Solo or Team)
+
+### Solo Mode (default, no teams):
+Work through each open question systematically:
+- For each question, consider at least 2 approaches
+- Evaluate each against: project requirements, existing patterns in CLAUDE.md, complexity, risk
+- Make a recommendation with rationale
+- Document the decision in `.gsd-t/progress.md` Decision Log
+
+### Team Mode (when agent teams are enabled):
+If the user requests team exploration or there are 3+ complex open questions:
+
+```
+Create an agent team:
+
+ALL TEAMMATES read first:
+- CLAUDE.md
+- .gsd-t/contracts/ (all files)
+- docs/ (relevant docs)
+
+Assign each teammate a distinct perspective:
+- Teammate 1: Advocate for approach A — build strongest case
+- Teammate 2: Advocate for approach B — build strongest case  
+- Teammate 3: Critic — find weaknesses in both, identify risks
+
+Lead: Synthesize into decisions and update contracts.
+```
+
+Assign teammates based on the nature of the questions:
+- **Technical choice** (e.g., which database): one advocate per option + critic
+- **Architecture pattern** (e.g., monolith vs microservice): one advocate per pattern + someone evaluating migration path
+- **Risk assessment**: one optimist, one pessimist, one pragmatist
+
+## Step 4: Update Contracts
+
+Every decision MUST result in a contract update. This is the output that matters.
+
+For each decision:
+1. Update or create the relevant contract file in `.gsd-t/contracts/`
+2. Update domain `scope.md` and `constraints.md` if the decision affects boundaries
+3. Add to `.gsd-t/progress.md` Decision Log with date and rationale
+
+## Step 5: Document Ripple
+
+Decisions don't just affect contracts — they can change the broader documentation:
+
+### Always update:
+1. **`.gsd-t/progress.md`** — Decision Log with date, decision, and rationale
+
+### Check if affected:
+2. **`docs/architecture.md`** — Did a decision change the architecture pattern, tech stack, data flow, or component relationships? Update it
+3. **`docs/requirements.md`** — Did a decision add, remove, or change a requirement? Update it
+4. **`docs/schema.md`** — Did a decision affect the data model? Update it
+5. **`CLAUDE.md`** — Did a decision establish a new convention or pattern? Add it so all future work follows it
+6. **Domain `constraints.md`** — Already updated in Step 4, but double-check all domains are consistent with the decisions
+
+### Skip what's not affected.
+
+## Step 6: Validate Contracts
+
+After all updates:
+- [ ] All contracts are internally consistent (no conflicting types/shapes)
+- [ ] Cross-references between contracts are valid
+- [ ] Every domain's constraints reflect the decisions made
+- [ ] Integration points are updated with any new dependencies
+
+## Step 7: Report
+
+Present to the user:
+1. Decisions made (with brief rationale)
+2. Contracts created or updated
+3. Any remaining open questions that need user input
+4. Recommended next step (usually: plan phase)
+
+Update `.gsd-t/progress.md` status to `DISCUSSED`.
+
+$ARGUMENTS

package/commands/gsd-t-execute.md

@@ -0,0 +1,121 @@
+# GSD-T: Execute — Run Domain Tasks (Solo or Parallel)
+
+You are the lead agent coordinating task execution across domains. Choose solo or team mode based on the plan.
+
+## Step 1: Load State
+
+Read:
+1. `CLAUDE.md`
+2. `.gsd-t/progress.md`
+3. `.gsd-t/contracts/` — all contracts
+4. `.gsd-t/contracts/integration-points.md` — dependency graph
+5. `.gsd-t/domains/*/tasks.md` — all task lists
+
+Identify:
+- Which tasks are already complete (check progress.md)
+- Which tasks are unblocked (no pending dependencies)
+- Which tasks are blocked (waiting on checkpoints)
+
+## Step 2: Choose Execution Mode
+
+### Solo Mode (default)
+Execute tasks yourself following the execution order in `integration-points.md`.
+
+For each task:
+1. Read the task description, files list, and contract refs
+2. Read the relevant contract(s) — implement EXACTLY what they specify
+3. Read the domain's constraints.md — follow all patterns
+4. Implement the task
+5. Verify acceptance criteria are met
+6. Run the Pre-Commit Gate checklist from CLAUDE.md — update ALL affected docs BEFORE committing
+7. Commit with a descriptive message: `[{domain}] Task {N}: {description}`
+8. Update `.gsd-t/progress.md` — mark task complete
+9. If you've reached a CHECKPOINT in integration-points.md, pause and verify the contract before continuing
+
+### Team Mode (when agent teams are enabled)
+Spawn teammates for independent domains:
+
+```
+Create an agent team for execution:
+
+ALL TEAMMATES must read before starting:
+1. CLAUDE.md — project conventions (CRITICAL)
+2. Your domain's scope.md — what you own
+3. Your domain's constraints.md — what you must/must not do
+4. ALL files in .gsd-t/contracts/ — your interfaces
+5. Your domain's tasks.md — your work
+
+RULES FOR ALL TEAMMATES:
+- Only modify files listed in your domain's scope.md
+- Implement interfaces EXACTLY as specified in contracts
+- If a task is marked BLOCKED, message the lead and wait
+- Run the Pre-Commit Gate checklist from CLAUDE.md BEFORE every commit — update all affected docs
+- After completing each task, message the lead with:
+  "DONE: {domain} Task {N} - {summary of what was created/modified}"
+- If you need to deviate from a contract, STOP and message the lead
+- Commit after each task: [{domain}] Task {N}: {description}
+
+Teammate assignments:
+- Teammate "{domain-1}": Execute .gsd-t/domains/{domain-1}/tasks.md
+- Teammate "{domain-2}": Execute .gsd-t/domains/{domain-2}/tasks.md
+- Teammate "{domain-3}": Execute .gsd-t/domains/{domain-3}/tasks.md
+
+Lead responsibilities:
+- Use delegate mode (Shift+Tab)
+- Track completions from teammate messages
+- When a CHECKPOINT is reached:
+  1. Pause blocked teammates
+  2. Verify the gate condition (check contract compliance)
+  3. Unblock waiting teammates
+- Update .gsd-t/progress.md after each completion
+- Resolve any contract conflicts immediately
+```
+
+## Step 3: Checkpoint Handling
+
+When a checkpoint is reached (solo or team):
+
+1. **Stop** execution of blocked tasks
+2. **Read** the relevant contract
+3. **Verify** the implemented code matches the contract:
+   - API response shapes match?
+   - Schema matches?
+   - Component interfaces match?
+   - Error handling matches?
+4. **If mismatch**: Fix the implementation to match the contract, OR update the contract and notify affected domains
+5. **Log** in progress.md: `CHECKPOINT {name}: PASSED/FAILED — {details}`
+6. **Unblock** downstream tasks
+
+## Step 4: Error Handling
+
+### Contract Violation
+A teammate implements something that doesn't match a contract:
+1. Stop the teammate
+2. Identify the deviation
+3. Decide: fix implementation or update contract?
+4. If updating contract, message ALL affected teammates with the change
+5. Log the decision
+
+### Merge Conflict / File Conflict
+Two teammates modified the same file (shouldn't happen with good partitioning):
+1. Stop both teammates
+2. Identify which domain owns the file (check scope.md)
+3. Non-owner reverts their changes
+4. Determine if the contract needs updating to prevent recurrence
+5. Log the incident
+
+### Blocked Teammate Idle
+A teammate finishes independent tasks and is waiting on a checkpoint:
+1. Check if checkpoint can be expedited
+2. If not, have the teammate work on documentation, tests, or code cleanup within their domain
+3. Or shut down the teammate and respawn when unblocked
+
+## Step 5: Completion
+
+When all tasks in all domains are complete:
+1. Update `.gsd-t/progress.md` — all tasks marked complete
+2. Set status to `EXECUTED`
+3. List any contract deviations or decisions made during execution
+4. Recommend: proceed to integrate phase
+
+$ARGUMENTS