wrapcli 0.1.1

CLI identity faking utility.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126

# Contributing to wrapcli

First off, thank you for considering contributing to wrapcli. It's people like you that make this project better.

Following these guidelines helps communicate that you respect the maintainers' time and makes the contribution process smooth for everyone.

## Table of Contents
1. [Code of Conduct](#code-of-conduct)
2. [How to Report a Problem](#how-to-report-a-problem)
3. [How to Suggest a Feature or Change](#how-to-suggest-a-feature-or-change)
4. [Your First Contribution](#your-first-contribution)
5. [Development Workflow](#development-workflow)
   - [Prerequisites](#prerequisites)
   - [Building the Project](#building-the-project)
   - [Running Tests](#running-tests)
6. [Coding Standards](#coding-standards)
7. [Commit Messages](#commit-messages)
8. [Pull Request Process](#pull-request-process)
9. [License](#license)

---

## Code of Conduct

This project adheres to the [Contributor Covenant Code of Conduct](https://www.contributor-covenant.org/version/2/1/code_of_conduct/). By participating, you are expected to uphold this code. Please report unacceptable behavior to vi.is.chapmann@gmail.com.

---

## How to Report a Problem

**If you find a security vulnerability, do NOT open an issue.** Email vi.is.chapmann@gmail.com instead. See more: [SECURITY](SECURITY)

For any other bug:
1. **Search existing issues / work items** – your problem may already be fixed or reported.
2. **Open a new issue** using the **Bug Report** template.

---

## How to Suggest a Feature or Change

Open an issue / work item with the label `enhancement`. Explain:
- What you want to achieve and why.
- Any potential implementation ideas.
- Whether you are willing to work on it yourself.

For major changes, please discuss them first – we might already have a different direction in mind.

---

## Your First Contribution

Unsure where to start? Look for issues labelled `good first issue` or `help wanted`.  
Feel free to ask questions on the issue – we're happy to guide you.

---

## Development Workflow

### Prerequisites
- Cargo

### Building the Project
```bash
# Clone your fork
git clone https://github.com/vi-is-ramen/wrapcli
cd wrapcli

cargo build
```

### Running Tests
```bash
cargo test
```
All tests must pass before submitting a pull request.

---

## Coding Standards

- **Formatting**: Use the project's existing style. If a formatter is available, run it before committing.
- **Naming**: Follow language conventions – `snake_case` for variables, `PascalCase` for types.
- **Comments**: Write comments in English. Explain *why*, not what (the code already shows what).
- **Portability**: Avoid platform‑specific code unless absolutely necessary. If unavoidable, document it.
- **Error handling**: Return meaningful errors; don't silently swallow `Err(...)`/`None`.

---

## Commit Messages

Follow the [Conventional Commits](https://www.conventionalcommits.org/) format loosely:

```
<type>(<scope>): <short summary>

[optional body]

[optional footer]
```

**Types**: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`  
**Example**: `feat(parser): add support for escaped quotes`  
**Scope** is optional – can be module name or `*`.

Keep the summary under 72 characters. Use imperative present tense ("add" not "added").

---

## Pull Request Process

1. **Fork the repository** and create your branch from `main`. 
2. **Update documentation** if you change behaviour (README, docstrings, comments).  
3. **Add or update tests** for any new functionality.  
4. **Run all tests locally** to ensure nothing breaks.  
5. **Push your branch** and open a Pull Request against the upstream `main` branch.  
6. **Fill out the PR template** include a summary, related issues (e.g., "Fixes #123"), and test evidence.  
7. **Wait for CI** – if CI fails, fix the issues.  
8. **Request a review** from one of the maintainers (or assign yourself if you have permissions).  

A maintainer will review your PR. They may ask for changes – please respond promptly. Once approved, a maintainer will merge it.

---

## License

By contributing, you agree that your contributions will be licensed under the same license as the project (see `LICENSE` file).