Merge pull request #89 from bufferings/work

Comprehensive documentation improvements

Author: bufferings

.cursor/rules/docs.mdc

@@ -1,89 +1,48 @@
 ---
 description: 'Guidelines for writing accurate, well-structured documentation'
-globs: ['**/docs/**/*.md', '**/README.md', '**/*.mdc']
+globs: ['**/docs/**/*.md', '**/README.md']
 alwaysApply: false
 ---
 
 # Documentation Writing Rules
 
-## Core Principle: Source Code First
+## Source Code First
 
-**NEVER use guesswork or assumptions when writing documentation.**
+**Never write documentation based on assumptions or guesswork.**
 
-### Mandatory Process
+Always read and understand the actual source code before writing documentation:
 
-1. **Read the Source Code**: Always read and understand the actual implementation before writing any documentation
-2. **Verify Examples**: All code examples must be based on real, working code from the codebase
-3. **Check API Usage**: Verify method signatures, parameter types, and return values from the actual source
-4. **Test Assumptions**: If unsure about any behavior, examine the code rather than guessing
-
-### What to Read
-
-- **Main API functions**: Understand how they work internally
-- **Type definitions**: Get accurate parameter and return types
-- **Example files**: Use patterns from existing examples in the codebase
-- **Plugin implementations**: Understand actual plugin architecture
-- **Test files**: See real usage patterns and edge cases
-
-### Prohibited Practices
-
-- ❌ Writing documentation based on common framework patterns
-- ❌ Assuming API behavior without checking source code
-- ❌ Copying examples from similar frameworks
-- ❌ Guessing method signatures or parameter types
-- ❌ Making up configuration options that don't exist
-
-### Required Practices
-
-- ✅ Read the actual source code before writing
-- ✅ Base all examples on real code from the repository
-- ✅ Verify all API calls against the implementation
-- ✅ Check type definitions for accuracy
-- ✅ Test examples against the actual codebase
-
-### When in Doubt
-
-- Read more source code
-- Look for existing examples in the codebase
+- Read main API functions, type definitions, and existing examples
+- Verify all code examples work with the actual implementation
+- Base method signatures and behaviors on real source code
 - Check test files for usage patterns
-- Never guess - always verify
-
-## Writing Style Guidelines
 
-### Clear Structure Over Bold Text
+Never guess API behavior, copy from other frameworks, or make up configuration options.
 
-**Write documents that convey importance through structure, not formatting.**
+## Writing Style
 
-### Mandatory Practices
+### Structure Over Formatting
 
-- ✅ Use heading hierarchy (h1, h2, h3) to show importance and organization
-- ✅ Write complete, flowing sentences instead of bullet-pointed fragments
-- ✅ Let content organization and natural language convey emphasis
-- ✅ Use section structure to guide readers through logical progression
+Use clear heading hierarchy and natural prose instead of bold text for emphasis:
 
-### Prohibited Practices
+- ✅ Descriptive subheadings and logical organization
+- ✅ Complete sentences that flow naturally
+- ❌ Bold text for emphasis (except critical warnings)
 
-- ❌ Using bold text (**text**) to emphasize importance
-- ❌ Relying on formatting instead of clear writing to convey meaning
-- ❌ Creating bullet lists where prose would be more natural
-- ❌ Bold text in navigation links and call-to-action elements
+### Simple and Direct
 
-### Writing Approach
+- Start with the simplest working example
+- Focus on essential value proposition
+- Let code examples do the explaining
+- Keep explanatory text concise
 
-- Use descriptive subheadings instead of bold keywords
-- Write cohesive paragraphs that flow naturally
-- Let the information hierarchy speak for itself
-- Make important points clear through placement and context, not bold formatting
+### Honest Tone
 
-### Exception
-
-Bold text may be used sparingly for:
-
-- ✅ True emphasis within technical explanations (very rare)
-- ✅ Highlighting critical warnings or errors
+- State capabilities factually without overselling
+- Avoid negative comparisons with other frameworks
+- Never fabricate testimonials or quotes
+- Be positive but realistic about limitations
 
 ## Remember
 
-Documentation that contains incorrect information is worse than no documentation at all. Accuracy is paramount.
-
-Quality documentation guides readers through natural flow and clear structure, not visual emphasis.
+Inaccurate documentation is worse than no documentation. Always verify against source code.

docs/.vitepress/config.js

@@ -33,7 +33,6 @@ export default defineConfig({
           items: [
             { text: 'What is Kori?', link: '/en/guide/what-is-kori' },
             { text: 'Getting Started', link: '/en/guide/getting-started' },
-            { text: 'Configuration', link: '/en/guide/configuration' },
           ],
         },
         {
@@ -98,7 +97,6 @@ export default defineConfig({
           items: [
             { text: 'Koriとは？', link: '/ja/guide/what-is-kori' },
             { text: 'はじめかた', link: '/ja/guide/getting-started' },
-            { text: '設定', link: '/ja/guide/configuration' },
           ],
         },
         {

docs/en/examples/rest-api.md

@@ -766,5 +766,4 @@ app.onError((ctx, error) => {
 
 - [File Upload Example](/en/examples/file-upload) - Handle file uploads in REST APIs
 - [Authentication with Plugins](/en/guide/plugins) - Implement JWT authentication plugins
-- [Database Configuration](/en/guide/configuration) - Configure database connections
 - [CORS Plugin](/en/extensions/cors-plugin) - Learn about CORS configuration